FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 09-01-2012, 03:00 PM
mike cloaked
 
Default libsystemd to systemd

On Sat, Sep 1, 2012 at 2:46 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@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.)"

That is close to BS I am afraid - I run several machines where there
is a connection in several times a day sometimes even more often.

>
> 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.

My use case includes using sshd behind a firewall - and it far from uncommon!

>
>>
>> > 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.
>>

Can't comment on that statement!!!

> 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.

And the evidence for this is where?

--
mike c
 
Old 09-02-2012, 06:52 PM
C Anthony Risinger
 
Default libsystemd to systemd

On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@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.

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.

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.

>> > 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 ...

> 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?

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

> 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?

> 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.

--

C Anthony
 
Old 09-03-2012, 10:46 AM
Kevin Chadwick
 
Default libsystemd to systemd

> On Sat, Sep 1, 2012 at 8:46 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> >> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@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)
__________________________________________________ _____________________
 
Old 09-04-2012, 12:02 PM
Tom Rand
 
Default libsystemd to systemd

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@yahoo.co.uk> wrote:
> > >> On Aug 31, 2012 7:47 PM, "Kevin Chadwick" <ma1l1ists@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)
> __________________________________________________ _____________________
 
Old 09-04-2012, 01:06 PM
Kevin Chadwick
 
Default libsystemd to systemd

> > >
> > > 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!

It's also used for temporary remote desktop access to fix windows
boxes enabled when a client loads up similar to log me in. Aside from
ssh is brill, is your point that there may be many connections behind
firewalls too with tunneling and such?

I use ssh behind firewalls too, but in that case it is connected to
many times a day by all users but it is definately a fact that ssh is
mainly used for its primary purpose of crossing the internet safely,
mainly to public facing remote servers.

--
__________________________________________________ _____________________

'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)
__________________________________________________ _____________________
 

Thread Tools




All times are GMT. The time now is 06:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org