OS - Fedora Linux to cent os Linux
installed samba on Cent os
connecting via fedora os
smb-status ONLINE
nmb-staus ONline
===============================
while writing
---smb://192.168.1.76
================GETS ERROR ============
No route to host
the reason in my case was the firewall in CentOs 7(IN WHICH SAMBA WAS RUNNING)
SOLUTION(CENTOS 7)
get default firewall zone
1)firewall-cmd --get-default-zone
OUTPUT=(Public)
now allow the samba service in firewall
2)sudo firewall-cmd --permanent --zone=public --add-service=samba
now RELOAD the firewall
3)sudo firewaall-cmd --reload
Related
I tried to setup the Varnish on the Instance Debian 10 but then something goes wrong and I tried installing some apache2 modules like
sudo a2enmod SSL
sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
But after enabling these modules when I restarted Apache2 I was unable to start the apache because there was something that was blocking port 443 and causing conflict with Apache2. When I removed the port Listen 443 from ports.conf file I was able to start the apache server but only on the 8080 port and on port 80 varnish is running but on the port 443, there is a service called httpd running which I am unable to find out from which config file it is configured.
The content of the ports.conf file is
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 8080
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Screenshot of the ports process running. I am unable to use port 443 and unable to stop that service httpd also. it is not linked with apache2 I tried stopping the apache but this service keeps on running.
httpd
The httpd service usually refers to the Apache webserver. However, if you install Apache on Debian via apt-get install apache2, the actual service is called apache2. This is also reflected in your netstat output.
On Red Hat based system the service is called httpd. Is it possible that you compiled an Apache server from source on that same machine? Or did you accidentally install a package that is httpd-relate?
You can perform a dpkg -l to list the installed packages, maybe you'll find it there.
Anyway, please kill the httpd process and check if there's a systemd service that contains that service name. You can go into /lib/systemd/system and perform a grep httpd *.
What about TLS in Varnish?
You shouldn't enable HTTPS on your system by using mod_ssl. You should install a TLS proxy that terminates the TLS session and then passes the plain HTTP connection to Varnish which in its turn will talk plain HTTP with Apache.
I advise you to use Hitch, it's a TLS proxy that is developed by Varnish Software engineers. It's flexible, powerful and lightweight.
To install Hitch, you can find the official packages here: https://packagecloud.io/varnishcache/hitch.
Here's the documentation you might need: https://github.com/varnish/hitch/tree/master/docs
A Varnish Developer Portal tutorial about Hitch will be available some time next week.
I'm running Windows 11. I have my dev environment in Debian running via WSL2.
I have this VSCode extension installed (although I have tried multiple SQL VSCode extensions and they all act the same)
If I have a VSCode window open in a WSL2 instance I am unable to connect to my DB but if I have a normal VSCode window open I am able to use any extension to access my DB.
In both instances the DB connection details are identical.
I need to use a program called ScaleFT to create a secure tunnel to the DB, I'm assuming this is the cause of the issue in part.
I am able to connect to my local dev MYSQL DB running in docker from both a WSL and normal VSCode window.
I've found that WSL's network sharing with the host system seems to run into trouble a lot with VPN and Ad-Hoc tunnel sharing with the Windows host.
What worked best for me was just to install an independent client for the WSL host. I use Ubuntu personally but I bet this will be a drop-in for your Debian setup, too.
Add the ScaleFT Repo to apt:
echo "deb http://pkg.scaleft.com/deb linux main" | sudo tee -a /etc/apt/sources.list
Add the ScaleFT signing keys to your local keyring:
curl -fsSL https://dist.scaleft.com/pki/scaleft_deb_key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/scaleft-deb-key.gpg
Pull package list and install the Linux tools:
sudo apt update && sudo apt install -y scaleft-client-tools scaleft-url-handler
That should leave you with a ready copy of the sft client tool. You can test with:
sft --version
From there, you can enroll your new WSL client and those connections should start working for you but, of course, your mileage may vary!
I have installed openshift through minishift on mac. I am able to run the command docker login -u developer -p <pass> 172.30.1.1:5000 from the shell where openshift is running. However I need to run the same login command from host mac machine and don't know the ip to use.
The openshift console can be accessed from https://192.168.64.3:8443.
The command minishift openshift registry returns an error.
I can run the oc commands from mac host machine.
I think you better login to docker daemon: https://docs.okd.io/latest/minishift/using/docker-daemon.html instead that login to the internal registry directly. Once you've done you can use docker client as it is bound to your minishift environment.
We have a Jenkins CI server that runs our suite of tests on every commit, triggered by a GitHub hook.
We recently moved the suite of tests from running locally on the Jenkins server to running inside a VirtualBox/Vagrant VM. This is to ensure that the test configuration matches the dev environment. This is an Ubuntu 14.04 guest running on Ubuntu 14.04 host.
After moving to the VM model, PHPUnit occasionally fails with no connection to MySQL. The error is Can't connect to MySQL server on '127.0.0.1'.
This error is intermittent, not easily reproducible. That is, if I trigger a new build on Jenkins, it usually succeeds. However, when the new build is triggered by the GitHub hook, it fails more often than manually triggered builds, and sometimes succeeds.
Here's what I tried:
sudo service mysql restart before running phpunit
sleep 5 between the mysql restart and phpunit
Connecting to localhost and 127.0.0.1 -- When I tried connecting to localhost, I received intermittent errors Can't connect to MySQL server on '/var/run/mysqld/mysqld.sock'.
Here's the full output of the failed build:
sudo service mysql restart
* Stopping MySQL (Percona Server) mysqld
...done.
* Starting MySQL (Percona Server) database server mysqld
...done.
* Checking for corrupt, not cleanly closed and upgrade needing tables.
sleep 5
sudo service mysql status
* /usr/bin/mysqladmin Ver 8.42 Distrib 5.6.23-72.1, for debian-linux-gnu on x86_64
Server version 5.6.23-72.1-log
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/run/mysqld/mysqld.sock
Uptime: 6 sec
Threads: 1 Questions: 111 Slow queries: 0 Opens: 761 Flush tables: 1 Open tables: 754 Queries per second avg: 18.500
phpunit
PHPUnit 4.6.2 by Sebastian Bergmann and contributors.
Configuration read from /vagrant/phpunit.xml
...........EEE.E.............E............................EEEEE.
Time: 8.51 seconds, Memory: 135.25Mb
1) ProcessDatasetsTest::test_process_on_census_fraction
PDOException: SQLSTATE[HY000] [2003] Can't connect to MySQL server on '127.0.0.1' (111)
I've had intermittent connectivity issues with Mysql on Vagrant, but not precisely related to PHPUnit. Connections were dropping just out of the blue, until I found out there were many boxes running at the same time in virtualbox for the same app. I killed them all, then ran vagrant global-status --purge and I had perfect connections again.
We saw a similar issue on a different Vagrant VM -- Can't connect to MySQL server -- and it turned out to be a memory issue. The VM was out of RAM. This was fixed by adding or increasing a swapfile on the VM:
sudo fallocate -l 1G /swapfile.img
sudo chmod 0600 /swapfile.img
sudo mkswap /swapfile.img
sudo swapon /swapfile.img
Amazon linux AMI and Percona server 5.6 don't appear to be compatible right out of the box. MySQL won't start after successful install.
In Perconas docs it does say that it is supported.
Steps to get to the below:
yum install http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm
yum install Percona-Server-server-56
Which installs the client + shared 56 libraries as well.
Some more accurate logs.
[root#* ec2-user]# mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
[root#* ec2-user]# service mysql restart
ERROR! MySQL (Percona Server) PID file could not be found!
Starting MySQL (Percona Server).......... ERROR! The server quit without updating PID file (/var/lib/mysql/ip-172-30-0-92.pid).
On the most recent Amazon Linux AMI, I was able to start the server after running these commands:
yum install 'perl(Data::Dumper)'
yum reinstall Percona-Server-server-56
If the perl-Data-Dumper package is not installed, mysql_install_db fails to run and perform the initial setup.
The Percona-Server-server-56 package should declare a dependency on perl-Data-Dumper, but you can work around that error (and avoid the reinstall) by installing it first.