Added ArchLinux support.

[TheKinrar]

No description provided.

[angristan]

With APT, when a package requires dependencies, and those dependencies are installed and have updates availble, they're updated when the package is installed. In the same way, when an update for the installed package example is available, doing apt install example will just update the package.

I assume it works the same way for pacman ? Correct me if I'm wrong.

Thus, I don't think that adding -u to the pacman command is needed. Not that this is not a good idea, but I don't want the script to be too intrusive for the user. The -y is a good idea, though.

[angristan]

You confirm that lines 51 to 62 this add a functionnal rc.local, and therefore resolving #1 ?

[TheKinrar]

I assume it works the same way for pacman ? Correct me if I'm wrong.

When just using -S, pacman will only install specified packages, and won't update dependencies, unless a more recent version is needed by one of the specified packages.
To sum up, pacman will just do what's needed to have the dependencies fulfilled.

The problem is, we can't just do -S because if another version is out, the old one won't be available in the repositories and the install will fail.

The -y is a good idea, though.

Yes this is the solution to this problem, but it is highly discouraged to do -Sy, as of what I just explained. Archlinux is meant to kept up to date, packages have to be updated all the same time. Things may break even if the dependencies are still fulfilled.

Thus, I don't think that adding -u to the pacman command is needed.

So, even if I agree with you, it's a little bit intrusive, but Arch is meant that way.

You confirm that lines 51 to 62 this add a functionnal rc.local, and therefore resolving #1 ?

Absolutely.

[angristan]

You're right : https://wiki.archlinux.org/index.php/Pacman#Installing_packages

Warning: When installing packages in Arch, avoid refreshing the package list without upgrading the system (for example, when a package is no longer found in the official repositories). In practice, do not run pacman -Sy package_name instead of pacman -Syu package_name, as this could lead to dependency issues.

I can't argue with the Arch Documentation 🙄

[angristan]

So as for me, the installation works fine, and I can ping 10.8.0.2.

However, it seems to be an issue with the firewall, the server does not forward the traffic, so I can't access anyting outside the server.

[TheKinrar]

It worked fine for me. Can you check the actual iptables rules ?

Openvpn log may be interesting too.

[angristan]

There is no iptables rules, that's the problem.

The OpenVPN logs don't say anything about this as it's not related to OpenVPN

[TheKinrar]

Oh, I see.

I suppose iptables was installed by the script, and as it does not start nor enable it, it's not working. I'm writing a fix now.
Can you confirm this is the problem by running systemctl status iptables?

[angristan]

iptables is already present on my installation, but it is indeed not started. I'm not sure it's the problem though, because I just reinstalled the server and the installer shows me this at the end :

sed: can't read /etc/sysctl.conf: No such file or directory
grep: /etc/sysctl.conf: No such file or directory
iptables v1.6.0: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

However OpenVPN is sucsessfully installed

[angristan]

Okay so

iptables v1.6.0: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

is on me, I had to reinstall Linux from the Arch repo, which was not the case (thanks Online...)

[TheKinrar]

So this is working now?

However the fix I just done was necessary as if iptables was not started, the changes done would have had no effect

[angristan]

It works, but the traffic is not forwarded after a reboot. The iptables rule is not set

[TheKinrar]

Can you show the contents of the file /etc/rc.local and the output of systemctl status rc-local please?

[angristan]

[root@server ~]# cat /etc/rc.local
[root@server ~]# systemctl status rc-local
* rc-local.service - /etc/rc.local compatibility
   Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-11-23 20:18:51 CET; 1h 55min ago
  Process: 318 ExecStart=/etc/rc.local (code=exited, status=203/EXEC)
 Main PID: 318 (code=exited, status=203/EXEC)

Nov 23 20:18:51 sd-80765 systemd[1]: Starting /etc/rc.local compatibility...
Nov 23 20:18:51 sd-80765 systemd[1]: rc-local.service: Main process exited, code=exited, status=203/EXEC
Nov 23 20:18:51 sd-80765 systemd[1]: Failed to start /etc/rc.local compatibility.
Nov 23 20:18:51 sd-80765 systemd[1]: rc-local.service: Unit entered failed state.
Nov 23 20:18:51 sd-80765 systemd[1]: rc-local.service: Failed with result 'exit-code'.
[root@sd-80765 stan]#

[TheKinrar]

New fix, working on my server even after a reboot now.

[angristan]

Does not work for me, but to be sure I'm gonna reinstall the server from scratch.

I checked the use of sysctl for Arch and it seems that the file is not located in the right folder : https://wiki.archlinux.org/index.php/Sysctl (does not affect the current issue tough)

Also, I think the script should add the rc.local file after it ask them if they want to continue. If the user cancel the installation, the script should not have touched anything on the system

[TheKinrar]

My bad, it was working on my server because of an old weird thing I've done to support this path..

Fixing this now, with the suggestion you have juste done.

[TheKinrar]

Still working for me, starting from scratch, with these new changes.

[angristan]

Ok I'll test asap

[angristan]

Same problem after a reboot.

[root@server ~]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

[angristan]

rc-local is not working :

[root@server ~]# systemctl status rc-local.service -l
* rc-local.service - /etc/rc.local compatibility
   Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2016-11-25 16:37:06 CET; 10s ago
  Process: 484 ExecStart=/etc/rc.local (code=exited, status=203/EXEC)
 Main PID: 484 (code=exited, status=203/EXEC)

Nov 25 16:37:06 sd-80765 systemd[1]: Starting /etc/rc.local compatibility...
Nov 25 16:37:06 sd-80765 systemd[1]: rc-local.service: Main process exited, code=exited, status=203/EXEC
Nov 25 16:37:06 sd-80765 systemd[1]: Failed to start /etc/rc.local compatibility.
Nov 25 16:37:06 sd-80765 systemd[1]: rc-local.service: Unit entered failed state.
Nov 25 16:37:06 sd-80765 systemd[1]: rc-local.service: Failed with result 'exit-code'.

[TheKinrar]

What's inside rc.local file and systemd unit file?

[angristan]

[root@server ~]# cat /etc/rc.local
#!/bin/bash
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to 123.123.123.123

[root@server ~]# cat /etc/systemd/system/rc-local.service
[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[TheKinrar]

This is an old version of the script, not fixed.

Either remove it and start from scratch the install, or just replace ExecStart=/etc/rc.local by ExecStart=/bin/bash /etc/rc.local

[angristan]

It's the actual version : https://github.com/Angristan/OpenVPN-install/pull/2/files#diff-cda9722285f1718b319bb88e134e9efeR302

[TheKinrar]

Fixed...

Avoid starting from stratch by executing chmod +x /etc/rc.local if you want.

[angristan]

Works too thanks.

I'll make some more tests, and then I'll fix the conflicts for the merge

[angristan]

Thanks 🤗