[arch-general] Arch Linux on servers?
eduardo.machado at gmail.com
Wed Jul 10 10:27:03 EDT 2013
2013/7/10 Sébastien Luttringer <seblu at seblu.net>
> On Tue, Jul 9, 2013 at 12:13 PM, M Saunders <okachi at gmail.com> wrote:
> > which has some useful tips. But it'd be interesting to hear from
> > people running Arch on production servers, how well it works for them
> > and what (if any) problems they've faced.
> I've 9 personal servers running Archlinux (previously under debian)
> and I plan to move about ~250 professional hypervisor under Arch this
> Let me share the following experiences with you.
> 1) Use the minimum set of packages
> This will save you from updating useless packages and give you a
> better view of what your server use.
> As there is only few packages, don't rush to update them when there is
> major change on it.
> 2) Do your sysadmin homework
> Before updating, check archlinux.org for announcements.
> During update read pacman output.
> After updating, look for pacsave/pacorig/pacnew files.
> Supervise your packages. I use munin with the following plugins
> 3) Use a versioned kernel
> One of the most wanted expectation on a server is to avoid reboot.
> Arch official kernel is too often updated for a server _and_ cannot be
> installed without breaking the running kernel (modules mismatch).
> To workaround this I build custom kernels, with the version in the
> name and I use a meta package which push new version
> automatically and clean the old one. So I can update my server, and at
> the next reboot the last kernel will be selected.
> 4) Detect daemon upgrade
> When you update your system, some libraries or binaries can be updated
> and your running programs still use the old version.
> This give the bad feeling that your software are up-to-date. But it's
> Of course you can reboot your server to be sure after each update.
> It's too long and give the feeling to hunt fly with a tank.
> I use the following script which list services (systemd speaking)
> which need to be restarted.
> # checkservcies -l # list services to restart
> # checkservices -r # restart it
> 5) Detect server reboot
> I track my server reboot with the following software. Btw, this is
> not a solution for 250 servers.
> 6) Use your repository to spread your custom packages
> For personal packages or taken from AUR, using a custom repository[8}
> will simplify your job.
> You compile your soft in one place, no need to have gcc or base-devel
> on your servers.
> Update is automatically propagate as official repository.
> You can easily override official package (not recommended).
> You could use a base meta package to have all the basics software
> on all your servers.
> This will prepare you to become an archlinux TU or Dev.
> 7) Security
> Debian is not more secure because their softwares are old. It's a lie.
> Check the number of open flaw in the security bug tracker.
> If you want to be in a secure environment stay up-to-date, don't use
> debian stable, use debian sid. So Archlinux is a good alternative.
>  Please note, that is not a pleasure for a package maintainer to
> add a message in his package. So read it.
>  https://github.com/seblu/archutils/blob/master/archlinux-pacfiles
>  https://github.com/seblu/archutils/blob/master/archlinux-packages
>  https://github.com/seblu/archpkg/blob/master/linux-seblu/PKGBUILD
>  https://github.com/seblu/archpkg/blob/master/linux-seblu-meta/PKGBUILD
>  https://github.com/seblu/archutils/blob/master/checkservices
>  https://github.com/seblu/mailboot
>  https://seblu.net/a/seblu/x86_64/
>  https://github.com/seblu/archpkg/blob/master/base-seblu/PKGBUILD
>  https://security-tracker.debian.org/tracker/status/release/stable
> Sébastien "Seblu" Luttringer
> GPG: 0x2072D77A
This all were valuable lessons, thanks to share.
At this point i am thinking that the initial question was a great start to
discuss and share stability an security techniques for an Arch install.
More information about the arch-general