PDA

View Full Version : SLED & systemd



susecmail
02-Feb-2018, 21:25
Is it possible to replace systemd and run SLED with an alternative such as runit? If not, is systemd viable without other component parts (journald, etc.)? I prefer to have my log files in plain text and not binary. Same with DNS resolution.

I'm looking to start my IT security business again and previously, I had suggested SLED and SLES, due to the fact that I had been using a form of SUSE since it was a small German company with a Linux called S.u.S.E. and trusted both their product and their service commitment.

Kind of related, but not on topic, why was systemd embraced so quickly by SUSE? Was it because SUSE is committed to GNOME?

ab
02-Feb-2018, 22:47
On 02/02/2018 01:34 PM, susecmail wrote:
>
> Is it possible to replace systemd and run SLED with an alternative such
> as runit? If not, is systemd viable without other component parts

I doubt it, particularly if you want support. Could you make it work?
Probably, but you can do a lot of things when you roll your own distribution.

> (journald, etc.)? I prefer to have my log files in plain text and not
> binary. Same with DNS resolution.

A lot of the logs still end up in plain text files, so I do not know that
you lose much. At the end of the day, there are no "text" or "binary"
differences on the platter (assuming you still use spinning rust disks);
everything is made up of zeroes (0) and ones (1), so I am not sure I agree
with you. Still, you're entitled to your opinions, and if they make you a
billionaire, remember us little people.

> I'm looking to start my IT security business again and previously, I had
> suggested SLED and SLES, due to the fact that I had been using a form of
> SUSE since it was a small German company with a Linux called S.u.S.E.
> and trusted both their product and their service commitment.

I agree; product quality is pretty awesome, and I've had fewer problems in
the quality department with SUSE's stuff than with other vendors. They
focus on Enterprise, which helps with that, and they focus on tested
things, which obviously helps. There are some great presentations from
SUSECon and other places where the testing and automation stuff is
presented. It takes a lot of investment to get it where it is.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

susecmail
02-Feb-2018, 23:25
Thank you for taking the time to answer. I'm pretty sure I could wrestle a system together with just systemd, although why I would want to do it, or anybody for that matter, is beyond me. Everything on the computer is ones and zeroes; I was programming machine language on AWACS back in the earlly ninties, so I'm familiar with the concept. I'm also familiar with the heartache that systemd gave me the first few years and I found out what I didn't like about it (pretty much everything).

I'm posting this from Void Linux, which I've been using for awhile and haven't had a problem with it, personally. The problem I do have with it is that there is no enterprise-level support. I just don't like nor trust systemd, at all, so it's hard to ask people to adopt that if I won't. Which will leave me with suggesting a Windows-based solution *sigh*. I should probably give SUSE a call or talk to one of their reps to get an official answer; I was hoping somebody had a similar concern/issue/experience here, which has been my first place to stop. Actually, my only place, as most of my questions have been answered either here or on another forum.

As a side note:

Runit is so easy compared to systemd, especially as implemented.

PostgreSQL autostart script under systemd:


[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking

User=postgres
Group=postgres

# Where to send early-startup messages from the server (before the logging
# options of postgresql.conf take effect)
# This is normally controlled by the global default set by systemd
# StandardOutput=syslog

# Disable OOM kill on the postmaster
OOMScoreAdjust=-1000
# ... but allow it still to be effective for child processes
# (note that these settings are ignored by Postgres releases before 9.5)
Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
Environment=PG_OOM_ADJUST_VALUE=0

# Maximum number of seconds pg_ctl will wait for postgres to start. Note that
# PGSTARTTIMEOUT should be less than TimeoutSec value.
Environment=PGSTARTTIMEOUT=270

Environment=PGDATA=/usr/local/pgsql/data


ExecStart=/usr/local/pgsql/bin/pg_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT}
ExecStop=/usr/local/pgsql/bin/pg_ctl stop -D ${PGDATA} -s -m fast
ExecReload=/usr/local/pgsql/bin/pg_ctl reload -D ${PGDATA} -s

# Give a reasonable amount of time for the server to start up/shut down.
# Ideally, the timeout for starting PostgreSQL server should be handled more
# nicely by pg_ctl in ExecStart, so keep its timeout smaller than this value.
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Note: this must be created if a person installs postgresql from scratch rather than through their distro.

PostgreSQL autostart under runit:


#!/bin/sh
exec setuidgid postgres /usr/lib/postgresql/bin/postmaster \
-D /var/lib/postgres/data 2>&1

These are just quick examples I've had to research in the past. I am not an expert in creating systemd startup scripts, so I rely on searches. However, in runit, I can create a small script based off man page info, place it in /etc/sv/<program> and then link it to /var/service/<program> and it's done.

ab
05-Feb-2018, 07:09
On 02/02/2018 03:34 PM, susecmail wrote:
>
> Thank you for taking the time to answer. I'm pretty sure I could wrestle
> a system together with just systemd, although why I would want to do it,
> or anybody for that matter, is beyond me. Everything on the computer is
> ones and zeroes; I was programming machine language on AWACS back in the
> earlly ninties, so I'm familiar with the concept. I'm also familiar with
> the heartache that systemd gave me the first few years and I found out
> what I didn't like about it (pretty much everything).

At the end of the day most distributions have made their bed with systemd
in it, so finding an alternative, with support, in an enterprise distro,
will basically mean you are starting a new company and offering support to
yourself. If you can rule out the enterprise support portion, you can get
things like Slackware running, or you could go the BSD route with FreeBSD
or OpenBSD, which considering your background may be something easier than
a lot of things.

It may be worth noting a lot of things are provided by systemd that are
nice to have, though depending on your familiarity with alternatives, your
ability with shell scripting, and your desire to not have a monolothic
daemon, could also be seen as negatives. Pick your poison.

A few quick benefit that init just didn't have (runit may have them; I
have no idea as I need Enterprise support for clients, and that means
systemd today):

Immediate and automatic restart of services that die.

Centralized logging; sure, in theory applications could all write to
/var/log, but developers often did their own thing instead. This is
particularly nice as it shows STDOUT from the init scripts, which was
usually lost leaving you with application logging only, which is useless
if the application isn't starting.

Simple analysis of startup delay causes (find that pesky process slowing
down bootup performance).

Along those lines, faster boot times by nicely parallelizing service
initialization. Traditional init starts things serially.

No need for scripting to make most things work. I've built a couple
systemd service unit files, and most of the time I used this template and
modified the two lines that mattered (Description and ExecStart) and let
systemd do everything else:




[Unit]
Description=Neato service here

[Service]
ExecStart=/path/to/startup/command

[Install]
WantedBy=multi-user.target



Also, customization of these is trivial with systemd drop-in
files/directories, which is a huge improvement over relying on application
developers to provide extensions to their init scripts, or more likely,
rolling your own init scripts. In Enterprise distros you seldom do
customization of init scripts or systemd services, but when it is
necessary it is great to have this option (I've used it a couple times) to
do so without worrying about vendor-path-X overwriting your changes and
re-breaking things, which is what happens when the vendor provides the
init script, as is the case with all software in an enterprise distro

> I'm posting this from Void Linux, which I've been using for awhile and
> haven't had a problem with it, personally. The problem I do have with it
> is that there is no enterprise-level support. I just don't like nor
> trust systemd, at all, so it's hard to ask people to adopt that if I
> won't. Which will leave me with suggesting a Windows-based solution

If you trust windows more than Linux, that's the best solution. Your
writing and background makes me wonder how that could be possible, since
at least systemd is open source and at this point is running most current
Linux installs, but I trust windows about as much as you reportedly trust
systemd and separated myself from it the better part of twenty (20) years
ago as a result.

> *sigh*. I should probably give SUSE a call or talk to one of their reps
> to get an official answer; I was hoping somebody had a similar
> concern/issue/experience here, which has been my first place to stop.
> Actually, my only place, as most of my questions have been answered
> either here or on another forum.

The forums are great, another benefit of SUSE stuff.

You may find the openSUSE side of things useful; while there is not
enterprise support like SLES, the Open Build Service (OBS) MAY have
somebody contributing 'init' (or similar) to replace systemd. I doubt it,
as it would be a monumental task to maintain, but it's possible.

> PostgreSQL autostart script under systemd:
>
>
> Code:
> --------------------
> [Unit]
> Description=PostgreSQL database server
> After=network.target
>
> [Service]
> Type=forking
>
> User=postgres
> Group=postgres
>
> # Where to send early-startup messages from the server (before the logging
> # options of postgresql.conf take effect)
> # This is normally controlled by the global default set by systemd
> # StandardOutput=syslog
>
> # Disable OOM kill on the postmaster
> OOMScoreAdjust=-1000
> # ... but allow it still to be effective for child processes
> # (note that these settings are ignored by Postgres releases before 9.5)
> Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
> Environment=PG_OOM_ADJUST_VALUE=0
>
> # Maximum number of seconds pg_ctl will wait for postgres to start. Note that
> # PGSTARTTIMEOUT should be less than TimeoutSec value.
> Environment=PGSTARTTIMEOUT=270
>
> Environment=PGDATA=/usr/local/pgsql/data
>
>
> ExecStart=/usr/local/pgsql/bin/pg_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT}
> ExecStop=/usr/local/pgsql/bin/pg_ctl stop -D ${PGDATA} -s -m fast
> ExecReload=/usr/local/pgsql/bin/pg_ctl reload -D ${PGDATA} -s
>
> # Give a reasonable amount of time for the server to start up/shut down.
> # Ideally, the timeout for starting PostgreSQL server should be handled more
> # nicely by pg_ctl in ExecStart, so keep its timeout smaller than this value.
> TimeoutSec=300
>
> [Install]
> WantedBy=multi-user.target
> --------------------

This is the one from SLES 12 with PostgreSQL 9.6:




[Unit]
Description=PostgreSQL database server
After=syslog.target
After=network.target

[Service]
Type=forking
User=postgres
EnvironmentFile=-/etc/sysconfig/postgresql
ExecStart=/usr/lib/postgresql-init start
ExecStop=/usr/lib/postgresql-init stop
ExecReload=/usr/lib/postgresql-init reload

# The server might be slow to stop, and that's fine. Don't kill it
SendSIGKILL=no

[Install]
WantedBy=multi-user.target



> Note: this must be created if a person installs postgresql from scratch
> rather than through their distro.

Irrelevant with an enterprise distribution, right? You could also steal
one from anybody else; creating from scratch is basically something
developers (of the original application) will do most of the time. The
only one I've created was for a client's home-grown application, and they
moved from SLES 11 to SLES 12 and wanted to do it right (not rely on the
init script backward compatibility.

> PostgreSQL autostart under runit:
>
> Code:
> --------------------
>
> #!/bin/sh
> exec setuidgid postgres /usr/lib/postgresql/bin/postmaster \
> -D /var/lib/postgres/data 2>&1
> --------------------

That worked for your system, I presume. Things I would ask bout, though,
are how the system stops the service, how you can define environment
variables, how it handles failure at runtime, how it handles slow stops
(because PostgreSQL is a bit relational database engine, so it may be slow
to stop), how it is configured to start at one runlevel vs. another (you
mentioned symlinking already, so that answers one of the questions), and
so on. For a simple startup of a simple service, the script works, but
this is far simpler than 'init' ever made things, and it is far less
functionality than the dozen lines of a systemd-controlled service.
Again, if that is what you want, then the more power to you (that phrase
seems ironic to me in this context).

Life's too short to use crappy software; run what you feel is best, but
I'm 99.9% sure that SUSE's distros, like most others, are exclusively
systemd-based as of SLES 12. That could change, as things often do, but
the whole enterprise distro industry have moved, so it seems unlikely as
most of the big arguments against systemd are essentially preference. We
all had to relearn when moving to systemd from init, so moving back and
learning again needs to have some concrete benefits; I just do not see
that happening (for whatever that's worth, likely nothing).

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

susecmail
08-Feb-2018, 21:37
Not sure if your familiar with runit as part of a system init manager, but it's extremely simple to manage services:


$> sv status <service>
$> sv restart <service>
$> sv stop/start <service>

Anything that resides in /var/service/ is a service and is automatically started and managed; conversely, if it does not exist in /var/service/ it will not be automatically started. More info on runit can be found both on github (https://github.com/vulk/runit)and the developer's site (http://smarden.org/runit/faq.html). What's even better is that PID1 is reserved solely for init purposes and everything else is processed afterwards; systemd doesn't necessarily follow that (https://lists.freedesktop.org/archives/systemd-devel/2015-February/028585.html), AFAIK, and that's why I was asking if SUSE could be re-configured, maintaining support, without systemd or if all the other creep could be stripped from systemd, and maintain support.

And, as far as being OSS and trusting it, that's not always the case: Shellshock (https://en.wikipedia.org/wiki/Shellshock_(software_bug)) which had existed since 1989. Then, of course, systemd has had a few hiccups (https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/).

As for systemd, I just don't like nor trust the developers. It's a morass of code (https://github.com/systemd/systemd) and, after having stared at it for hours, I decided that I don't have the time. If I have to dig through the code to decide to trust something, I can usually find something else to do the job. For example, until SUSE adopted systemd, I trusted the support team who put out the updates & patches. In the early days, I would look at every dependency and who coded it (around 1998-2000), and decide if I wanted that software on my server bad enough, usually I didn't.

With systemd's system creep (it now has DNS, web server, ip-forwarding, mount, logging, udev...), it becomes harder to keep the tasks separate, when one area of systemd fails, it affects all others.

You're right, though, I may have to provide that support; not sure that I wanted to get back into that as a business (that could take up a LOT of time, depending on the customer), but I really don't trust Windows, either! :P

ofvergara
10-Feb-2018, 00:03
Hi SuseCmail,
my suggestion for a systemd-free Suse Linux Enterprise, is to use either SLED11SP4 (unfortunately no more updates or patches since last year) or SLES11SP4 (still with active patches until 2019 or 2022, i don't remember exactly). They both are excellent and reliable pre-systemd versions using sysV init.

I am using SLED11SP4 and i love it although it is aging a bit these days and it's getting harder to find updated software for it. i am reluctant to go to SLED15 due to systemd as well. i don't trust it either. like the old saying goes "if it ain't broke, don't fix it). when SLED11SP4 becomes very old, then i might switch to devuan.org; at this point i don't know because i love SLED11SP4 very much, especially the gnome 2.28 interface (never liked gnome3 and i don't like MATE either)

I tried SLES11SP4 and installed it but it was cumbersome in the sense that it is more restrictive when doing common tasks (for instance, you have to provide the root password to shutdown or restart your computer, go figure; plus it has less software on the installation dvd than SLED11SP4, ie: openoffice is not on SLES11SP4 dvd yet it is included in SLED11SP4 dvd), plus the subscription price to keep active patches is too high for me and i am an individual, not a company (the last time i checked it is US$800 a year; unfortunately i cannot afford that :(

in the meantime, i am a happy camper with SLED11SP4 until my laptop breaks (it is a 6-year-old dell xps l502x laptop). still very fast with this linux version. i have win7 in the other partition, and this laptop becomes very slow, so slow it gets to your nerves. luckily i only use win7 to download security updates, so 99.5% of the time i'm on SLED11SP4.

hope this info helps...
cheers!

susecmail
14-Feb-2018, 05:27
Thank you, I had purchased SLED 11/12 awhile back and definitely liked 11 better; however, I'm too nervous about security holes and patches; for example, did SLED 11 get Meltdown/Spectre patches, or is the kernel stuck at a certain point after no further update releases?

I just remembered one of the reasons that I started disliking systemd, the r! fiasco where Poettering demonstrated a complete lack of understanding about how UNIX file processing works:

"I am not sure Id consider this much of a problem. Yeah, its a UNIX pitfall, but rm -rf /foo/.* will work the exact same way, no?" Lennart Poettering, systemd issue 5644 (https://github.com/systemd/systemd/issues/5644)

Wow.

ab
14-Feb-2018, 13:57
On 02/13/2018 09:34 PM, susecmail wrote:
>
> Thank you, I had purchased SLED 11/12 awhile back and definitely liked
> 11 better; however, I'm too nervous about security holes and patches;
> for example, did SLED 11 get Meltdown/Spectre patches, or is the kernel
> stuck at a certain point after no further update releases?

SLE 11 SP3 LTSS and SLE 11 SP4 should be patched per the main TID from SUSE:

https://www.suse.com/support/kb/doc/?id=7022512


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

AndreasMeyer
14-Feb-2018, 19:56
SLED 11 is End of Life.
https://www.suse.com/lifecycle/

susecmail
20-Feb-2018, 21:31
Update: I sent an email asking for clarification on this question to SUSE and have not received an official response. I'm leaning towards the "it's not supported" picture.

My quest continues.