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@xxxxxxxxxxx> wrote: > > >> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@xxxxxxxxxxx> 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) > _______________________________________________________________________
