[arch-general] [Bulk] Re: libsystemd to systemd

[Kevin Chadwick]

> On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:
> >> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists at yahoo.co.uk> wrote:
> >> >
> >> > > > I will give one example. Lennart says come on who connects to sshd
> >> more
> >> > > > than once a month. I can't believe he's never seen a sshd log with
> >> > > > constant pass attempts even though passwords are disabled.
> >> > >
> >> > > You are misunderstanding the sshd example.
> >> >
> >> > How? Systemds method would seem more problematic and wasteful to me if
> >> > you get connections to it a lot.
> >>
> >> The example explicitly only deals with the case where you do not get a lot
> >> of connections. E.g. in a private network.
> >
> > "And even SSH: as long as nobody wants to contact your machine there is
> > no need to run it, as long as it is then started on the first
> > connection. (And admit it, on most machines where sshd might be
> > listening somebody connects to it only every other month or so.)"
> >
> > Your just making stuff up now to cover his back, which questions many
> > of your many baseless responses simply stating I have shown I don't
> > understand systemd, end of discussion.
> >
> > It is far less likely that ssh is used behind a firewall and there is
> > no mention of this, it is a fact that ssh is primarily used to cross
> > the internet where it will be connected to frequently on any connection
> > as long as it is set to the recommended default port.
> 
> i highly doubt you, Lennart, or anyone else for that matter has any
> real numbers to support anything being said, so please, spare me.
> 

That would be obvious to anyone with any experience. Show me data that
says sshd is used more often behind firewalls. Of course it isn't. What
data that there are far more remote hosting than local hosting, of
course there is, you shouldn't need data to accept this point. Just
check your logs. I'd hope that if you run a daemon, you expect someone
to connect to it.


> now, IME, both privately and in the numerous IT-based companies i've
> both worked and/or consulted with ... there are indeed usually MANY
> servers that happily run sshd all day long, and do not receive
> connections unless there is a problem.
> 

Are these public facing on the default port as is most cases because in
that case you must be looking at auth successes and not failures. Just
look up why it is best to use public key and disable passwords.
IT-based companies, please do they still suggest ftp for web upload by
default.



> regardless, Lennart's only point was "sshd should only start when
> someone tries to connect" ... let's not beat around the bush here,
> mmk?
> 
> ... and a connection attempt is very different from a connection.  if
> you really want to block the former, then you use something like
> fwknopd to make the sshd port invisible to everyone except the
> authorized.  i use this on all my servers -- it's fantastic.
>

Funny how systemd advocates never seem to get the points. I don't want
to block anything, that's what sshd does anyway without adding extra
less audited crypto. You realise a server running openssl is more
vulnerable to exploits than one without, right?

Are you going to miss the point and bring up web code now.


> >> > Home connections even get many ssh
> >> > connection attempts
> >>
> >> If you have a pubic IP you'd be better off using the regular service and
> >> not the xinet-style one.
> >
> > The point is that much of his spec like bringing linux together and
> > assumptions are wrong and significant sacrifices for speed bring tiny
> > speed increases.
> 
> ... tell me, have you actually ran systemd yet? hmm ...
> 

Only on Fedora which takes longer to boot than my arch but that's
irrelevant. I think the potential of speed increase has quite clearly
been determined to be in the < 3 seconds range ignoring the stupid
argument of what if something pauses.


> > Here's another assumption.
> >
> > "A central part of a system that starts up and maintains services should
> > be process babysitting: it should watch services. Restart them if they
> > shut down."
> >
> > Wrong, few want this feature and respawn and especially baby sitting is
> > not a central feature of 'services' for an init system.
> 
> ehm, of the whopping 3 or so things sysvinit actually DID for you,
> wasn't respawn one of them?
> 

That's why I said services. I wouldn't call getty, a service myself
and you ignore baby sitting not being a central feature. You could
argue a supervise service perhaps, but it's not a central feature.

> you seem to want an init that does nothing at all -- and since shell
> is "like teh coolest thing eva .. eva", i suggest writing one in bash!
> it's not hard, and like i said in the past, i wrote one for LXC based
> systems that was ~20-30 lines, FULLY replacing sysvinit (well, i used
> that until systemd started to work nicely ;-)
> 

It was originally DESIGNED to do as little as necessary and that is
good design as it must run on every system and maximises UNIX
usefullness to all.


> > On single web server this may be desired and a user installs a
> > small package to do so that has features systemd hasn't and shouldn't
> > have.
> 
> *yawn*
> 
> > In most cases it isn't true and if you have redundant services as most
> > do or a secure service, you don't want the service restarted as it may
> > have been exploited, the restart may even enable the exploit, so another
> > server will take over instead.
> 
> # systemctl stop <exploited>.service
> [and optionally]
> # systemctl disable <exploited>.service
> 
> ... problem solved?

Too late, point is unnecessary feature bloat that results in bugs on
more systems than need be.

> 
> > Right, you've got me to waste more time than I wished, so no more.
> 
> nah friend, you did this to yourself -- no one made you do anything.
> 

Trueish

More true as arguing with these simple points shows there is no
hope for rational discussion here but many will understand.


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________