I'm trying to connect to vpnc using a systemd service file. The service file runs a script, myscript.sh, which, among other things, runs:
sudo vpnc myhost
Upon booting the device, the other commands are correctly executed, but the vpn is not connected, and gives me the error message:
vpnc: unknown host `myhost.com'
However, if I run the service file manually using
systemctl start myservice.service
then the vpn is successfully started.
My service file looks like this:
[Unit]
Description=VPN Start
Wants=network-online.target
After=network.target network-online.target
[Service]
Environment=DISPLAY=:0.0
Environment=XAUTHORITY=/home/pi/.Xauthority
Type=forking
ExecStart=/bin/bash /home/pi/myscript.sh
Restart=on-abort
User=pi
Group=pi
[Install]
WantedBy=multi-user.target
systemctl status myservice.service
includes this message:
pi: TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/usr/sbin/vpnc myhost
I have already done:
systemctl enable systemd-networkd-wait-online
and that hasn't appeared to help.
It might be to late, but maybe anyone else stumbles upon this.
I had the same issue although I configured the VPN through the GUI.
I found out eventually that my /etc/resolv.conf was a symlink to a configuration file some third party VPN software I sometimes use installed. Although the entries in that file looked fine it only worked, when I deleted the /etc/resolv.conf symlink and created a new normal file.
TL;DR:
Backup /etc/resolv.conf
Remove symlink
Create new /etc/resolv.conf and populate it with your preferred configuration
After that my VPN worked like a charm.
Related
I have Alpine Linux, 3.15.0 version on the server.
The installed nginx version is 1.21.6. I have performed apk update
nginx -t command successfully responds with
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
When I type nginx -s reload server responds with
2023/02/03 10:58:00 [notice] 54#54: signal process started
but nothing actually happens. It's like the process started and that's all.
What am I missing?
According to Nginx documentation, command nginx -s reload actually sends signal to nginx master process and
once the master process receives the signal to reload configuration,
it checks the syntax validity of the new configuration file and tries
to apply the configuration provided in it. If this is a success, the
master process starts new worker processes and sends messages to old
worker processes, requesting them to shut down.
Thus, we can consider that nginx is restarted (If we disregard the fact that the master process itself continued to work).
At the same time, if you want to totally restart nginx, you can stop it with nginx -s quit command and then start again. Or that's much better use your system service manager. If I'm not mistaken, there is an open-rc in Alpine, thus command will be rc-service nginx restart.
I successfully implemented this, which blocks all internet connections on my Linux machine UNLESS it connects via a specific VPN :
https://www.comparitech.com/blog/vpn-privacy/how-to-make-a-vpn-kill-switch-in-linux-with-ufw/
If I manually execute openvpn3 session-start --config ~/Desktop/config.ovpn, it successfully connects via the VPN.
I used to have this command in a script (that has #!/bin/bash as header) which ran at device bootup without any issues, UNTIL I configured ufw for the killswitch above (now ufw runs on device bootup).
I use openvpn3 so using instructions in the above tutorial for openvpn commands didn't work at all.
I even tried using a sleep in my bash script to get it to wait a while until after bootup. Doesn't work. But if I issue the connection command manually in the command prompt, it works.
Please help! I need it to connect automatically. Much appreciated!
After spending a whole day on this, I figured out a solution. I found an article that guided me : https://www.howtogeek.com/687970/how-to-run-a-linux-program-at-startup-with-systemd/
I set up a service item using systemd (systemctl) just for that command to connect. Here is what my entry looks like :
#/etc/systemd/system/connectvpn.service
[Unit]
Description=Connect VPN
After=ufw.service network.target
Requires=ufw.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/connect
#/usr/local/bin/connect
#!/bin/bash
openvpn3 session-start --config /home/xyz/Desktop/config.ovpn
Working nicely now, connects to the VPN on bootup.
I need to run some services on boot up which I have successfully accomplished using systemd services. (Lots of answers already available).
Now, one of my service requires access to /dev/video0 while bootup when a certain user is logged in. (I am doing auto login which is working fine).
So how do I check that whether the /dev/video0 is available before starting my systemd service while bootup.
I came across something called udev for doing this, I followed this link
but I am not getting desired output as after editing /lib/udev/rules.d/99-systemd.rules files as mentioned in the link and starting my service manually it's not starting, any help is appreciated.
Finally after struggling for a day I found the answer -
I made a script in /etc/systemd/system which contains
[Unit]
Description='some description of my file write according to you'
[Service]
Type=forking
ExecStart='path to script'
[Install]
WantedBy=multi-user.target
and It executes a script which contains
#!/bin/bash
modprobe uvcvideo
Now after rebooting all the services are running properly
mod probe uvcvideo command check for running video driver and enable it at the time of bootup so that It is available for my systemd process
Thanks
NFS Mount is not working in my RHEL 7 AWS instance.
When I do a
mount -o nfsvers=3 10.10.11.10:/ndvp2 /root/mountme2/
I get the error:
mount.nfs: requested NFS version or transport protocol is not supported
Can anyone point me where I am wrong?
Thanks.
Check the nfs service is started or reboot the nfs service.
sudo systemctl status nfs-kernel-server
In my case this package was not running and the issue was in /etc/exports file where i was having same IP address for two machines.
So i commented one ip address for the machine and restarted nf-kernel-server using
sudo systemctl restart nfs-kernel-server and reload the machine.
It worked.
A precision which might be useful for the dump (like me): systemctl status nfs-server.service and systemctl start nfs-server.service must be executed on the server!
Some additional data
If, like me, you've deleted a VM without shutting it down right you might also need to manually edit the file /etc/exports because NFS is trying to connect to it and fails but doesn't continue with the next, it just dies.
After that you can manually restart as mentioned in other answers.
In my case, a simple reload didn't suffice. I had to perform a full restart:
sudo systemctl status nfs-kernel-server
In my case, it didn't work correctly with version NFS 4.1.
So in Vargantfile in each place where is type: 'nfs' I added coma and nfs_version: 4, nfs_udp: false
Here is more detailing explanation NFS
If you're giving a specific protocol to connect with, also check to make sure your NFS server has that protocol enabled.
I got this error when trying to start up a Vagrant box, and my nfs server was running. It turns out that the command Vagrant uses is:
mount -o vers=3,udp,rw,actimeo=1 192.168.56.1:/dir/on/host /vagrant
Which specifically asks for UDP. My server was running but it was not configured to enable connecting over UDP. After consulting /etc/nfs.conf, I created /etc/nfs.conf.d/10-enable-udp.conf with the following contents to enable udp:
[nfsd]
udp=y
The name of the file doesn't matter, as long as it's in the conf.d directory and ends in .conf. Depending on your distribution it may be configured differently. You can directly edit nfs.conf, but using a conf.d file is more likely to preserve the changes after upgrading your system.
Try to ping IP address of the server "ping " from client "ping , if you get reply then install nfs server on the host. Then edit /etc/exports file don't forget to add port along with IP address
I got the solution: make an entry in nfs server /etc/nfsmount.conf with Defaultvers=3 .
There will # Defaultvers=3 just unhash it and then mount on nfs client.
Issue will be resolved!
I have OSX El Capitan. I installed Nginx-Full via homebrew. I am supposed to be able to start and stop services with
brew services Nginx-Full Start
I run that command and it seems to start no problem. I check the running services with
brew services list
That indicates that the Nginx-Full services is running. When i run
htop
to look at everything that is running Nginx does not show up and the server is not handling requests.
nginx is failing to launch because of an error, but brew-services is not communicating that to you.
Running it with sudo, as other users have suggested, is just masking the problem. If you just run nginx directly, you may see that there is actually a configuration or permissions issue that is causing nginx to abort. In my case, it was because it couldn't write to the error log:
nginx: [alert] could not open error log file: open() "/usr/local/var/log/nginx/error.log" failed (13: Permission denied)
2020/04/02 13:11:53 [warn] 19989#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /usr/local/etc/nginx/nginx.conf:2
2020/04/02 13:11:53 [emerg] 19989#0: open() "/usr/local/var/log/nginx/error.log" failed (13: Permission denied)
The last error is causing nginx to fail to launch. You can make yourself the owner of the logs with:
sudo chown -R $(whoami) /usr/local/var/log/nginx/
This should cause subsequent config errors to be written to the error log, even if homebrew services is not reporting them in stderr/stdout for now.
I've opened an issue about this: https://github.com/Homebrew/homebrew-services/issues/215
The log path may not the same for everyone. You can check the path to log file by checking the config file /usr/local/etc/nginx/nginx.conf. You can find a line like:
error_log /Users/myusername/somepath/nginx.log;. Change the chown command above accordingly. If even this didn't solve the problem, you may have to do the same for any other log files specified in the server blocks in your nginx configuration
Try launching it with "sudo", even if the formula say
The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.
sudo brew services Nginx-Full start
this worked for me:
sudo brew services start nginx
Running sudo nginx worked for me, it initially gave some error stating certain file in certain directory is missing, creating that file, and then another file is asked for to be created and then it runs properly.
I had similar problem, running it brew services start nginx used to show nginx running.
but brew services list used to show error.
running with sudo nginx solved my issue