Hi,
I just sanded down the remaining edges of my CentOS 7 post-install configuration script and published it on a Github repository, along with some detailed instructions.
* https://github.com/kikinovak/centos-setup
Feel free to use it (and/or adapt it to your needs).
Cheers from the sunny South of France,
Niki
On Nov 17, 2019, at 05:11, Nicolas Kovacs info@microlinux.fr wrote:
I just sanded down the remaining edges of my CentOS 7 post-install configuration script and published it on a Github repository, along with some detailed instructions.
Feel free to use it (and/or adapt it to your needs).
I’m curious why you list these as “cruft” packages?
chrony firewalld iperf NetworkManager-libnm
They are all removed as per of the “setup” command you provided. You remove the default NTP service, you disable the default firewall (although you do install iptables-service in base.txt) and you hobble NetworkManager.
Also, I’m sure it’s helpful for you, but setting all the default CentOS repos to ones in France as a baseurl means that anyone using it would get that too, so anyone thinking of forking the repo, don’t replace the CentOS repo files. The mirrorlist url should give you geographically close mirrors.
-- Jonathan Billings
Le 17/11/2019 à 14:15, Jonathan Billings a écrit :
I’m curious why you list these as “cruft” packages?
chrony firewalld iperf NetworkManager-libnm
* chrony: I'm using ntpd and ntpdate
* firewalld: https://github.com/kikinovak/firewall
* iperf: replaced by iperf3
* NetworkManager: great on laptops, useless on servers
Also, I’m sure it’s helpful for you, but setting all the default CentOS repos to ones in France as a baseurl means that anyone using it would get that too, so anyone thinking of forking the repo, don’t replace the CentOS repo files. The mirrorlist url should give you geographically close mirrors.
You're right. The main reason I did this is because some of my servers are behind filtering proxies, and more often than not, CentOS mirrors are blocked.
I have to think about a practical solution for this.
Thanks for the feedback !
Niki
On Nov 17, 2019, at 11:58 AM, Nicolas Kovacs info@microlinux.fr wrote
- chrony: I'm using ntpd and ntpdate
You should never be using ntpdate anymore (which is why the ntp project is deprecating it, http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate ). I really only ever suggest ntpd unless you’re running an NTP server that provides NTP service to your network, and needs to supported time source hardware. NTPd actually worse for laptops and other devices with intermittent/congested connections, and VMs that experience time jumps during migrations. Chrony also tends to use less RAM and power than NTPd due to how it does time management and generally smaller footprint.
Kinda looks like you’ve reinvented the wheel here, breaking down firewall rules into separate files and managed by a single service. Plus, firewalld supports ipsets along side iptables rules in C7, and uses nftables by default in C8, keeping you with the fastest way of setting up rules. But I get it, not everyone cares for firewalld. On c6, I managed the iptables file with a template in configuration management, breaking up the individual config files into separate, role-based chunks.
Also, the ‘fail2ban’ service has firewalld support, which uses ipsets for its blocks, improving overall performance.
- NetworkManager: great on laptops, useless on servers
Untrue. NM is great for servers. I think I’ve told this story a dozen times on this list, but nearly all our servers use NM. We experienced a power outage in our datacenter due to some clumsy UPS maintenance people, and when power was restored to the floor, the servers booted faster than the networking equipment. Everything using the old ’network’ service booted up, detected no network, and gave up and completed the boot, with no network at all. Had to visit the datacenter to reboot them. All the NM systems had the network start fail, and continued with the boot, and as soon as the interface comes online, NM brings up the network and triggers all network-dependent services to come online.
NM supports event-based dispatching (in /etc/NetworkManager/dispatcher.d/) so you can run custom scripts when the network state changes. NM in CentOS7 is a lot better than you had in C6, the default settings don’t restart the interface if you change the ifcfg-* files (a stupid problem in C6) and supports a lot more features like bridges and bonds that were missing in earlier versions. You can interact with it via dbus (if that’s your thing) and the nmcli tool is really handy for CLI-based settings.
The only time I’ve seen a need to use the old network service was when I discovered that you can’t set custom routes on the loopback interface with NM, since it doesn’t manage the loopback interface.
-- Jonathan Billings
Le 17/11/2019 à 18:56, Jonathan Billings a écrit :
You should never be using ntpdate anymore (which is why the ntp project is deprecating it, http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate ). I really only ever suggest ntpd unless you’re running an NTP server that provides NTP service to your network, and needs to supported time source hardware. NTPd actually worse for laptops and other devices with intermittent/congested connections, and VMs that experience time jumps during migrations. Chrony also tends to use less RAM and power than NTPd due to how it does time management and generally smaller footprint.
I know ntpdate has officially been deprecated for ages. This being said, it works reliable when you have some serious lagging on the server.
Kinda looks like you’ve reinvented the wheel here, breaking down firewall rules into separate files and managed by a single service. Plus, firewalld supports ipsets along side iptables rules in C7, and uses nftables by default in C8, keeping you with the fastest way of setting up rules. But I get it, not everyone cares for firewalld. On c6, I managed the iptables file with a template in configuration management, breaking up the individual config files into separate, role-based chunks.
This is probably my Slackware background, but for many years, firewalling was essentially a shell script with iptables rules. From this point of view, firewalld has reinvented the wheel, so I simply stick with what works and what I'm familiar with. And since Linux obeys the Great Rule of Herding Cats, along comes nftables. BTW, the file snippets are just templates meant to be copy/pasted with Vim using split mode. :o)
- NetworkManager: great on laptops, useless on servers
Untrue. NM is great for servers. I think I’ve told this story a dozen times on this list, but nearly all our servers use NM. We experienced a power outage in our datacenter due to some clumsy UPS maintenance people, and when power was restored to the floor, the servers booted faster than the networking equipment. Everything using the old ’network’ service booted up, detected no network, and gave up and completed the boot, with no network at all. Had to visit the datacenter to reboot them. All the NM systems had the network start fail, and continued with the boot, and as soon as the interface comes online, NM brings up the network and triggers all network-dependent services to come online.
Again, this is probably the ex-Slacker in me throwing all the junk out and just keeping what's really needed.
Cheers & thanks for your detailed explanations. You've tickled my curiosity, so as soon as I finish writing my current Linux book (around X-mas I guess) I'll have a deeper look at all that stuff.
Niki
Am 17.11.19 um 23:52 schrieb Nicolas Kovacs:
Le 17/11/2019 à 18:56, Jonathan Billings a écrit :
You should never be using ntpdate anymore (which is why the ntp project is deprecating it, http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate ). I really only ever suggest ntpd unless you’re running an NTP server that provides NTP service to your network, and needs to supported time source hardware. NTPd actually worse for laptops and other devices with intermittent/congested connections, and VMs that experience time jumps during migrations. Chrony also tends to use less RAM and power than NTPd due to how it does time management and generally smaller footprint.
I know ntpdate has officially been deprecated for ages. This being said, it works reliable when you have some serious lagging on the server.
Kinda looks like you’ve reinvented the wheel here, breaking down firewall rules into separate files and managed by a single service. Plus, firewalld supports ipsets along side iptables rules in C7, and uses nftables by default in C8, keeping you with the fastest way of setting up rules. But I get it, not everyone cares for firewalld. On c6, I managed the iptables file with a template in configuration management, breaking up the individual config files into separate, role-based chunks.
This is probably my Slackware background, but for many years, firewalling was essentially a shell script with iptables rules. From this point of view, firewalld has reinvented the wheel, so I simply stick with what works and what I'm familiar with. And since Linux obeys the Great Rule of Herding Cats, along comes nftables. BTW, the file snippets are just templates meant to be copy/pasted with Vim using split mode. :o)
- NetworkManager: great on laptops, useless on servers
Untrue. NM is great for servers. I think I’ve told this story a dozen times on this list, but nearly all our servers use NM. We experienced a power outage in our datacenter due to some clumsy UPS maintenance people, and when power was restored to the floor, the servers booted faster than the networking equipment. Everything using the old ’network’ service booted up, detected no network, and gave up and completed the boot, with no network at all. Had to visit the datacenter to reboot them. All the NM systems had the network start fail, and continued with the boot, and as soon as the interface comes online, NM brings up the network and triggers all network-dependent services to come online.
Again, this is probably the ex-Slacker in me throwing all the junk out and just keeping what's really needed.
Cheers & thanks for your detailed explanations. You've tickled my curiosity, so as soon as I finish writing my current Linux book (around X-mas I guess) I'll have a deeper look at all that stuff.
I dont see if it was mentioned; but "network scripts" are deprecated in C8. So better start the mental migration today before the packages get removed totally :-)
-- Leon
Le 18/11/2019 à 18:06, Leon Fauster via CentOS a écrit :
I dont see if it was mentioned; but "network scripts" are deprecated in C8. So better start the mental migration today before the packages get removed totally :-)
I'll tackle that when I make the move to CentOS 8. For the moment I'm still with CentOS 7.x.
Cheers,
Niki
--On Monday, November 18, 2019 6:06 PM +0100 Leon Fauster via CentOS centos@centos.org wrote:
I dont see if it was mentioned; but "network scripts" are deprecated in C8. So better start the mental migration today before the packages get removed totally :-)
What file holds all those settings, now? As a rule, I prefer to edit text files to finding the right GUI/TUI utility to muck with them. I'd also like to know how the new and old files interact.
Once upon a time, Kenneth Porter shiva@sewingwitch.com said:
What file holds all those settings, now? As a rule, I prefer to edit text files to finding the right GUI/TUI utility to muck with them. I'd also like to know how the new and old files interact.
The same config files are in /etc/sysconfig/network-scripts (the supported options may vary some).
--On Monday, November 18, 2019 1:18 PM -0600 Chris Adams linux@cmadams.net wrote:
Once upon a time, Kenneth Porter shiva@sewingwitch.com said:
What file holds all those settings, now? As a rule, I prefer to edit text files to finding the right GUI/TUI utility to muck with them. I'd also like to know how the new and old files interact.
The same config files are in /etc/sysconfig/network-scripts (the supported options may vary some).
Thanks. With that clue, I found this more complete answer:
https://unix.stackexchange.com/questions/483354/rhel-8-deprecated-network-scripts
So the settings are in the same place but the scripts that parse them are gone or not executed by the new system, including *-local. Anything in the network-scripts RPM is gone. nmcli and friends replace that.
The "network" systemd unit is replaced with the NetworkManager unit when starting/stopping the whole network system. More about that here:
https://www.golinuxcloud.com/unit-network-service-not-found-rhel-8-linux/
On Sun, Nov 17, 2019, 2:52 PM Nicolas Kovacs info@microlinux.fr wrote:
Cheers & thanks for your detailed explanations. You've tickled my curiosity, so as soon as I finish writing my current Linux book (around X-mas I guess) I'll have a deeper look at all that stuff.
So you're writing a book on how Linux used to be?
Le 18/11/2019 à 19:59, John Pierce a écrit :
So you're writing a book on how Linux used to be?
Here you go:
https://www.microlinux.fr/wp-content/uploads/2019/07/administration-linux-pa...
Currently putting the finishing touches to vol. 2 (SELinux, CentOS on routerboards & on public root servers in France, Dnsmasq, BIND, MariaDB, Apache, Postfix, Dovecot, Roundcube, OwnCloud, Rsnapshot, Squid, 389 Directory Server, NFS, Samba, ...)
Cheers,
Niki
-
Chris Adams -
John Pierce -
Jonathan Billings -
Kenneth Porter -
Leon Fauster -
Nicolas Kovacs