Need help changing serverwide hostname (SSL)

I believe that fixes the original problem?
It probably does. However, when you request a certificate for the hostname, next time better use the request_single command. I'm not sure why but that's how the docs say.
./letsencrypt.sh request_single s1.newname.tld 4096
but if things work now, you're fine.

and i night-owl like me too i see. *cough* 01.00hrs *cough*
LoL, I'm just half way at that time, indeed also a night owl. :) The 01:00 is for me, what 19:00 is for "normal" people. I do tend to shutdown my pc somewhere between 01:30 and 02.30, but then the TV is next in row and going to bed between 05.00 and 05.30.
Do not ring me before 13.30 in the morning. :D
 
I think that only leaves these things

* Fixing that custombuild 2.0 plugin problem not detecting updates due to bad log file? (If that's better done in the custombuild section I'd be happy to post there)
* Public key authentication setup
* Do I need sudo installed? Any reason to keep or not keep that immutable flag on /etc/hostname?

Either way, if you're ever in my nick of the woods (West-Vlaanderen) hit me up, i would be happy to buy you a drink. Your knowledge and guidance was highly appreciated in fixing this odd problem.

Time wise, over the weekend same thing. 13-14.00hrs early afternoon is what 08-09.00hrs is to others. I'm barely waking up then. (I'm a bad sleeper, wake up a shit ton of times at night, and try to compensate that in the weekend by sleeping in extra long when I can't during the week)
 
ugh seems my ip somehow got blacklisted in the firewall (as i can access the server on my phone while on mobile data) i think, but now the domain is in accessible and the lfd service is down?

[email protected]:/usr/local/directadmin$ systemctl status directadmin.service
* directadmin.service - DirectAdmin Web Control Panel
Loaded: loaded (/etc/systemd/system/directadmin.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-11-21 15:25:45 CET; 15min ago
Docs: http://www.directadmin.com
Main PID: 392 (directadmin)
CGroup: /system.slice/directadmin.service
|-392 /usr/local/directadmin/directadmin
|-535 /usr/local/directadmin/directadmin
|-567 /usr/local/directadmin/directadmin
|-568 /usr/local/directadmin/directadmin
|-569 /usr/local/directadmin/directadmin
|-570 /usr/local/directadmin/directadmin
|-571 /usr/local/directadmin/directadmin
|-572 /usr/local/directadmin/directadmin
|-573 /usr/local/directadmin/directadmin
|-574 /usr/local/directadmin/directadmin
|-575 /usr/local/directadmin/directadmin
`-576 /usr/local/directadmin/directadmin

[email protected]:/usr/local/directadmin$ systemctl restart directadmin.service
Failed to restart directadmin.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
See system logs and 'systemctl status directadmin.service' for details.

[root@s1 ~]# service httpd restart
Redirecting to /bin/systemctl restart httpd.service
[root@s1 ~]#

rebuilt apache with no effect
/usr/local/directadmin/data/admin/ip_blacklist does not exist/is empty

[root@s1 custombuild]# systemctl status apache.service
Unit apache.service could not be found.
 
Last edited:
* Do I need sudo installed? Any reason to keep or not keep that immutable flag on /etc/hostname?
I try to answer some in the quick before dinner time.
You don't need sudo installed if you can su to root. But mostly sudo is installed by default.
As long as the hostname is correct in your VPS panel, it probably is not needed to keep that immutable fag on your /etc/hostname file however it won't hurt either.

- Custombuild plugin
I don't use that. And if you want to be an admin, sorry but even if I could, I wouldn't help you with that. Try updating via SSH, it's just as easy with a few commands, and you can see what is happening and you learn a lot more from working via console.

* Public key authentication setup
We'll come to that, I mostly do that via the program I use.

When restarting services, it's easier to use the service command, less to remember.
service restart directadmin
service restart httpd (or service restart apache)
and so on.

Rebuilding apache won't get you out of a blacklist because Apache does not keep blacklist, the firewall and/or DA do.
However, your DA's ip_blacklist does not exists.

In that case you are probably blacklisted by your firewall. If you are using CSF I wonder why your ip is not in the csf.allow and csf.ignore.
You don't have the CSF plugin in DA? This way you could remove your ip from the blacklist.

With SSH commands this would be:
csf -dr here.your.internet.ip csf -tr here.your.internet.ip

Also check your /etc/hosts.deny file if your ip is not in there.

If you get it free, be sure to whitelist it. Unless your ip's changes. I don't know how it's in Belgium.

As for West-Vlaanderen.... I'm on the east side, next the the Belgium Limburg. I'm living in Maastricht.
I'm also waking up more often, issues with apneu also. For hosting it's perfect. I can work on the servers while the customers (or most of them) are sleeping. :)
 
all the above is currently on hold. The domain won't resolve at all. ssh works but that's it. Tried soft and hard restart of the server to no effect. I sent you a pm, mind having a look?

hosts.deny is empty so at least my ip isn't blocked. this is something else seems like the domain cant "link" to the hosting space or something
 
Last edited:
Fixed it. An error which fastly can occur if people leave the iptables services in place after a new OS install (can also happen to more experienced users).

I firstly checked if iptables was in use. And unfortunately it was, and not with csf. But it was also configured to only allow limited access.
CSF did not wanted to start because another xtables owned the lock and created a csf.error file stating this and preventing csf from starting.

So I checked and iptables and ip6tables services were active. So I stopped and disabled both so they won't start anymore on startup.
Then I could remove the csf.error file and CSF was able to start.

So for everybody installing new OS, check this first via SSH as root:
iptables -L
you should only see 3 lines with ACCEPT so everything is open. If you see anything else before CSF is installed, stop and disable firewalld (in Centos 8) and stop and disable iptables and ip6tables (Centos 7 and maybe 8 too).
This way any iptables lock file can't interfere with CSF and prevent CSF from starting.
 
Back
Top