[Novalug] dynamic symbolic links

Peter Larsen peter@peterlarsen.org
Mon Apr 27 20:35:53 EDT 2015


On 04/27/2015 05:50 PM, John Holland wrote:
> Peter, thanks for this extensive response. I just now got to read it.  I guess I’m over the hill, I don’t have as much motivation to learn new things. Lately I’ve been trying to learn C and C++  but not putting in enough time on it.

You're never to old to learn. I'm no spring chicken either but that
doesn't mean I cannot learn new tricks. Or rather, see stuff I used 20
years ago be declared "a new way of IT" just named something else, and
given a shiny exterior so everyone can go "ohhh and ahhhh". Not much new
is happening - it's all just re-inventing the same old wheel again and
again.

> I  reacted to the systemd controversy by first saying it was nothing and finally saying it was everything. At some point I read a changelog for systemd (219 I believe) and I didn’t even understand what they were TRYING to do; 

Strange place to start learning. Did you try putting this into your
browser: https://www.google.com/search?q=what+is+systemd ??
Lots of great articles and explains the concepts, purpose and why this
is many times better than scripting ever was. No, changelog isn't where
I would start if I was learning a new technology.

Fedora has a now rather old wiki page that does a good job at giving you
a quick 10 minute overview on how to use it:
https://fedoraproject.org/wiki/Systemd


> I was not just baffled by the user’s manual, I didn’t even understand what the requirements were about. 

It would be helpful with an example. Systemd didn't re-invent what your
system does and what components it has. It changed the way you described
them and how you defined dependencies between system resources. Instead
of using scripting you use metadata - so instead of having to write
quite advanced scripts to manage services that had to store PIDs, set
security, escalate or remove privileges etc. you simply fill out a
property form.  Try writing a init script and tell me it was easy ;)
Here's an example of how ntpd is defined in systemd - everyone can
understand this:

$ cat /usr/lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=syslog.target ntpdate.service sntp.service
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS
PrivateTmp=true

[Install]
WantedBy=multi-user.target

===== eof =====

Voila! It's THAT simple. You specify the executable, simple options and
tell which other services this depends on. No more looking for strange
numbers to figure out where on this system this service belongs in the
chain. Notice, you can even say that this service conflicts with another
so you cannot have multiple "conflicting" things running at the same
time. That's pretty powerful AND SIMPLE. It's not that systemd is
complex - you just need to learn what it is, and how to use it.

And once you get into more advanced services, that depends on sockets,
special mount points etc. you definitely see why a simple declaritive
defintion is a lot easier to deal with as a developer and as a system
administrator. Systemd took something very complex and made it extremely
simple.  Are there a lot of components to systemd? Sure! But those
components exist regardless of systemd. So think about creating scripts
that needs to initiate sockets, verify system paths, check for a process
is alive so it can be restarted (and if it doesn't restart properly,
alert someone) and all that other stuff that we expect from a well
running system today. It's all built into systemd - and all you need to
do is set the right option.

Think about it - you can now easily declare that your database service
has to be running and accepting connections before starting your daemon
that uses that DB - or that web-server which has an app that uses that
DB. So if the DB fails, the web-server will not be started.

If you read between the lines here, you see several aspects where
sysvinit just could not keep up. And we haven't even gotten into the
more advanced stuff yet around security, process isolation and failure
handling.

> Linux has indeed taken off explosively, but I don’t feel as connected to it right now. 

I think that's because you have chosen not to keep up with it. Linux -
or IT in general - doesn't stand still because you think we've gotten to
nirvana and absolute equilibrium. It keeps evolving - because what we
are trying to do with it keeps evolving too. What I've been trying to
say is, that it's really not that hard to at least learn to understand
the components and what they do. That's the first step of being an
effective admin.

>  I put in a lot of effort getting this Macbook to run Debian well as packaging enlightenment for Debian (now they’ve made official packages so that’s over) .I took satisfaction in seeing in my server logs that people were downloading my packages from time to time.

See - and one of my early "lessons learned" with Linux was to start with
open HARDWARE so my Linux and OS experience would work. I'm not so sure
I understand what the reward is by trying to make proprietary and closed
hardware run an open source OS with all the difficulties that comes from
that. That said, well done in contributing your fixes back to the
community!

> I think it would be a lot of work if I tried to upgrade to the new Debian. That would start me on the road to learning systemd etc. I don’t feel like doing that for some reason. Maybe down the road.

Since you didn't say what Debian version you used it's a hard statement
to make any comments on.

> As far as increasing complexity, the BSD folks like to strive for simplifying things. A shorter process list is better.  etc, JIM Cottrell posted once the security model he liked was “I’m root and and you’re not.” 

And that's the crock of it. That's a very bad security policy. It means
one error and your whole system is compromised. One bad init script, and
PRESTO you have to crash your whole box because root just messed with
your production system or planted a backdoor. It's a pratice that was
well understood to be bad even in the 1980ies when NSA took the first
steps to implement the separation of powers in Linux (LOCK). Since
around 2000 we've had it available on Linux, and 2002/2003 it went main
line. All to fix the problem of having a single all powerful non
auditable user that can crash everything at will. It's a bad policy and
we've moved way beyond it - starting around RHEL4 for enterprise support.

It ensures that nobody can start a process on a port dedicated to a
specific purpose; that just because you can see a file that you cannot
load it as executable, that you cannot just expose files to the world
without "giving permission" to do so first etc. You can restrict root
completely. You can setup kiosk mode, so user logging in only has a
temporary space that is completely erased when they log out - perfect
for something available in public to search for information in etc.

There are a ton of reasons why that "simple" rule just doesn't apply in
real world scenarios. And that's not really news to anyone in the
security field who's required MLS ever since I started using enterprise
systems in the 80'ies.

> Maybe hyperbole but I like the spirit of it. Linux started out based somewhat on Minix, which is a nice system for learning how things work. 

We've moved way past the point of "learning" when it comes to Linux.
It's the defacto platform for doing things - not (just) learning how to
do them.

> There’s plenty of complexity for me in just understanding coding, what goes on in the kernel (even when it’s simple), figuring out how to make things work the way I want (usually with shell scripts).  Some of the new complexities, I just don’t see what the problem is they’re solving.

Kernels are way too complex and central to really be a target here. The
whole idea is to avoid having "users" or admins if you will having to
deal with customizing kernels at all. I haven't done a kernel compile in
about 10 years now. I haven't needed to since we have dynamic modules,
and I can add modules that fits the hardware I have without having to
build complete new kernels. And I dare say looking at the kernel is an
easy way to learn "what's going on". That requires very high level of
skills in CS to grasp. Not the level I would see the average admin at.

Shell-scripts are fine but they suck at being maintained. And they're
very much prune to bugs. If you can use declarative methods instead,
errors are automatically identified and you get your job done much faster.

>
> If I have an email client that’s OK, terminal windows and a browser (and maybe a music or  video player ) that’s all I really want. And a windowing system that I find reasonable.  

So no USBs? What about secondary terminals? Or battery vs. powered mode?
Changing resolutions on the fly without having to restart X? No picture
management directly from the camera? No social media links integration?
I could go on - the modern OS has to support a much wider range of
hardware than ever before, and integrate with all kinds of external
services. Most people don't even think about it - they just add weather
report and news feeds to their desktops. It's that common.

> I’m glad people like you are out there learning all the new stuff coming down the pike. Maybe you’ll explain it more to us sometime at a LUG meeting or something.

There wouldn't be much point in going to our meetings and discussing
here on the mailing list if I wasn't here to learn. I've picked up a ton
of stuff from the LUGs - both meetings and otherwise. What would the
point be to spend half of my Saturday going there, if I was just there
to complain about all the stuff I hadn't bothered learning about since I
first started out in IT? Ok, that's a bit harsh maybe - but really,
learning and teaching is the purpose of the LUGs - so I'm definitely
puzzled if you're only focused on a distribution that you've frozen as
of 10 years ago?

-- 
Regards
  Peter Larsen






More information about the Novalug mailing list