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

[Tom Rand]

On Mon, Sep 03, 2012 at 11:46:14AM +0100, Kevin Chadwick wrote:
> > 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.
> 

I recently worked for a large international compay who provided security appliances
to filter web requests,block spam, filter virus', archive email & more but
these appaliances use ssh clustering where by your company purchases 4 spam & virus filter
from my old employer all 4 of these appliances are linked via ssh so you only 
need to make changes to 1 of the 4 linked units & these changes are replicated
VIA SSH & for those wishing to can connect these appliances to my employers 
central server farm in US & one can login to a web based admin console & make changes there
which again is replicated via ssh. To add to that when a customer reqiures support 
this is provided via ssh.
my ex-employer are market leaders in these appliance and literally have thousands 
scaretterd accross the globe which i think should prove that ssh is very much in use
publicly & behind firewalls!


> 
> > 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)
> _______________________________________________________________________