On Fri, Jan 23, 2015 at 08:18:33PM -0800, Russ Allbery wrote:
> Josh Triplett writes:
>
> > Please, no. Under normal circumstances, the only dynamic bit of the
> > motd comes from uname, and only changes on reboot; updating it via cron
> > just wastes cycles and adds noise to syslog.
>
> > I'm
On Sun, 25 Jan 2015 17:07:52 -0800, Russ Allbery
wrote:
>This desire to avoid running something at boot is mystifying to me.
It's a clear trend. Boot time is _all_ that matters noawadays. Once
the login prompt is displayed, noone cares any more about anything.
Greetings
Marc
--
Josh Triplett writes:
> One more (set of) shell scripts spawned at boot time adds incremental
> complexity, fragility, and yes, a small amount of delay. It might not
> matter much if you're spending 60 seconds booting a server; on the other
> hand, with client boot times currently at a few secon
* Josh Triplett [150126 11:24]:
> Russ Allbery wrote:
> > Josh Triplett writes:
> > > However, I don't think "run a pile of scripts to write out a dynamic
> > > MOTD at boot time" is a sensible default, either.
> >
> > Why not?
> >
> > > I'd suggest putting update-motd and update-motd.d into a
Russ Allbery wrote:
> Josh Triplett writes:
> > However, I don't think "run a pile of scripts to write out a dynamic
> > MOTD at boot time" is a sensible default, either.
>
> Why not?
>
> > I'd suggest putting update-motd and update-motd.d into a separate,
> > optional package that users can ins
On 26 January 2015 at 07:46, Russ Allbery wrote:
> I think we're overcomplicating this. If someone really wants to put data
> that updates regularly in their MOTD *and* use update-motd.d to do this
> (we're already into territory that I suspect is pretty rare), we can just
> tell them to add a c
Josh Triplett writes:
> However, I don't think "run a pile of scripts to write out a dynamic
> MOTD at boot time" is a sensible default, either.
Why not?
> I'd suggest putting update-motd and update-motd.d into a separate,
> optional package that users can install if they really want it, and
>
Russ Allbery wrote:
> Josh Triplett writes:
> > But not the Debian default. Debian defaults to "UsePAM yes" and
> > "PrintMotd no", and uses PAM to print the motd.
>
> Right, which I think is a bad idea, for the reasons stated earlier in this
> thread. :) I think the way to go here is to use t
Cameron Norman writes:
> Well we can do both. If these update-motd scripts actually differ in
> their result day by day, and the server is only rebooted maybe once a
> week (if not less often), then running them once at boot is not enough.
I think we're overcomplicating this. If someone really
On Sun, Jan 25, 2015 at 11:45 AM, Russ Allbery wrote:
> Michael Biebl writes:
>
>> Why run this on every boot?
>
> The main thing that you want to be up-to-date are things like the running
> kernel version, and you have no other good way of detecting that, I don't
> think.
>
> It's not like this
Michael Biebl writes:
> Why run this on every boot?
The main thing that you want to be up-to-date are things like the running
kernel version, and you have no other good way of detecting that, I don't
think.
It's not like this stuff takes very long to run, and it will happily
parallelize.
> If
Am 25.01.2015 um 20:19 schrieb Russ Allbery:
> Josh Triplett writes:
>
>> But not the Debian default. Debian defaults to "UsePAM yes" and
>> "PrintMotd no", and uses PAM to print the motd.
>
> Right, which I think is a bad idea, for the reasons stated earlier in this
> thread. :) I think the
Josh Triplett writes:
> But not the Debian default. Debian defaults to "UsePAM yes" and
> "PrintMotd no", and uses PAM to print the motd.
Right, which I think is a bad idea, for the reasons stated earlier in this
thread. :) I think the way to go here is to use the update-motd.d stuff
to gener
Russ Allbery wrote:
> Josh Triplett writes:
> > That looks really promising. What would it take to get the default
> > /etc/issue changed to include all the necessary information to make the
> > current dynamic motd obsolete?
>
> ssh support for /etc/issue escapes, which seems incredibly unlikel
Josh Triplett writes:
> That looks really promising. What would it take to get the default
> /etc/issue changed to include all the necessary information to make the
> current dynamic motd obsolete?
ssh support for /etc/issue escapes, which seems incredibly unlikely. I
certainly wouldn't want t
Zbigniew Jędrzejewski-Szmek wrote:
> Modern agetty allows escapes in /etc/issue (see section ISSUE ESCAPES
> in agetty(8)) to insert values directly from uname(2) and /usr/lib/os-release.
> It should be plenty enough for the common case of displaying
> the distribution name and kernel version. Some
On Fri, Jan 23, 2015 at 11:56:33AM -0800, Josh Triplett wrote:
> Michael Biebl wrote:
> > I'm also no longer convinced, that running a huge shell machinery (as
> > root) during login via PAM is a good idea.
>
> Agreed.
>
> > If we go the update-motd route, I'd like to see the update-motd calls be
Riley Baird writes:
> Sort of off topic, but as far as I can tell, the historical purpose of
> MOTD was to send a message to all users of a system. Is it still used
> for this?
Yes. Stanford used, and presumably still uses, this pretty regularly for
head nodes of compute environments to alert u
On 24/01/15 15:18, Russ Allbery wrote:
> Josh Triplett writes:
>
>> Please, no. Under normal circumstances, the only dynamic bit of the
>> motd comes from uname, and only changes on reboot; updating it via cron
>> just wastes cycles and adds noise to syslog.
>
>> I'm not particularly convinced
Josh Triplett writes:
> Please, no. Under normal circumstances, the only dynamic bit of the
> motd comes from uname, and only changes on reboot; updating it via cron
> just wastes cycles and adds noise to syslog.
> I'm not particularly convinced that even the existing uname line has
> much valu
>> If we go the update-motd route, I'd like to see the update-motd calls be
>> removed from login (and boot) and instead have the dynamic part of
>> /etc/motd be updated via a cron job.
>
> Please, no. Under normal circumstances, the only dynamic bit of the
> motd comes from uname, and only chang
Michael Biebl wrote:
> I'm also no longer convinced, that running a huge shell machinery (as
> root) during login via PAM is a good idea.
Agreed.
> If we go the update-motd route, I'd like to see the update-motd calls be
> removed from login (and boot) and instead have the dynamic part of
> /etc/
Hi,
Michael Biebl:
> I'm also no longer convinced, that running a huge shell machinery (as
> root) during login via PAM is a good idea.
>
In fact, I'm convinced that it is _not_ a good idea.
You want to be able to log in as root when the system has problems.
Like, being slow as molasses or almos
Am 22.01.2015 um 16:34 schrieb Michael Biebl:
> Am 22.01.2015 um 15:46 schrieb Steve McIntyre:
>> AFAICS there remain silly unfixed bugs in the Ubuntu setup too, which
>> I've reported and never seen any progress on - see
>>
>> https://bugs.launchpad.net/ubuntu/+source/pam/+bug/684244
>>
>> If y
Hi,
On 01/22/2015 04:34 PM, Michael Biebl wrote:
> I'm also no longer convinced, that running a huge shell machinery (as
> root) during login via PAM is a good idea.
>
> If we go the update-motd route, I'd like to see the update-motd calls be
> removed from login (and boot) and instead have the d
Am 22.01.2015 um 15:46 schrieb Steve McIntyre:
> parav...@debian.org wrote:
>>
>> - pam_motd provides a facility (via a custom patch, brought over by
>> Ubuntu) that run-parts /etc/update-motd.d. The directory exists in
>> Ubuntu (along with default scripts that set Ubuntu's motd) but not in
>>
parav...@debian.org wrote:
>
>- pam_motd provides a facility (via a custom patch, brought over by
> Ubuntu) that run-parts /etc/update-motd.d. The directory exists in
> Ubuntu (along with default scripts that set Ubuntu's motd) but not in
> Debian, although https://wiki.debian.org/motd documents
On Fri, Jan 02, 2015 at 04:16:44PM +0200, Faidon Liambotis wrote:
> What is your concern with shipping a simple executable shell script?
Actually, it's not the executable what does not belong to base-files,
it's the *functionality*.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.
On Fri, Jan 02, 2015 at 04:16:44PM +0200, Faidon Liambotis wrote:
> On Wed, Dec 31, 2014 at 07:08:22PM +0100, Santiago Vila wrote:
> > On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote:
> > > c) base-files shipping /etc/update-motd.d, plus a script:
> > >00-uname: #!/bin/sh\nunam
On Wed, Dec 31, 2014 at 07:08:22PM +0100, Santiago Vila wrote:
> On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote:
> > c) base-files shipping /etc/update-motd.d, plus a script:
> >00-uname: #!/bin/sh\nuname -snrvm\n
>
> Could you please choose another package? debianutils comes
On Fri, Jan 02, 2015 at 11:56:44AM +0100, Ansgar Burchardt wrote:
> as this seems to be only about including the output of `uname' in motd,
> how about just *not* including it? I never found it to be particular
> helpful anyway...
>
> If you want to include information about the machine you are co
On 01/02/2015 at 05:56 AM, Ansgar Burchardt wrote:
> Hi,
>
> as this seems to be only about including the output of `uname' in
> motd, how about just *not* including it? I never found it to be
> particular helpful anyway...
>
> If you want to include information about the machine you are
> conne
Hi,
as this seems to be only about including the output of `uname' in motd,
how about just *not* including it? I never found it to be particular
helpful anyway...
If you want to include information about the machine you are connecting
to, then the OS version, amount of RAM, number and speed of pr
On 12/31/2014 03:20 PM, Faidon Liambotis wrote:
> The changes are in total 2+1+3 lines, plus killing two files, so
> relatively simple. On the flip side, this touches five
> essential/required packages so it might be a bit too much for jessie's
> freeze, although I also wonder if the current state
Christoph Anton Mitterer writes:
> On Wed, 2014-12-31 at 12:04 -0800, Russ Allbery wrote:
>> I think UsePAM yes is the only sane default for Debian, though, and
>> people who choose to change that default are legitimately on their own.
> I've used UsePAM no for many years without any real issue
On Wed, 2014-12-31 at 12:04 -0800, Russ Allbery wrote:
> I think UsePAM yes is the only sane default for Debian, though, and people
> who choose to change that default are legitimately on their own.
I've used UsePAM no for many years without any real issues, as you said
it depends what you want (a
Quoting Faidon Liambotis (parav...@debian.org):
> For this to happen, we'll need:
Hoping that a consensus can be reached, I will, as the "not so active
but last active" shadow maintainer, follow whatever conclusion will be
reached in this discussion. I don't really have any other advice,
indeed..
Christoph Anton Mitterer writes:
> For the OpenSSH server this is dependent on wheter UseLogin and/or
> UsePAM directives are being used or not, the later which has a
> configuration file default of "yes" in Debian (but not in upstream's
> default config or default value).
I think UsePAM yes is
On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote:
> c) base-files shipping /etc/update-motd.d, plus a script:
>00-uname: #!/bin/sh\nuname -snrvm\n
Could you please choose another package? debianutils comes to mind.
Currently, base-files has no binaries at all, and I'd like to k
One should perhaps add:
On Wed, 2014-12-31 at 16:20 +0200, Faidon Liambotis wrote:
> - Behavior is different between login & sshd. login has (#741129):
> session optional pam_exec.so type=open_session stdout /bin/uname -snrvm
> session optional pam_motd.so
>
> but SSH has:
> session opti
motd handling spans multiple packages (libpam-modules, login, ssh,
base-files, initscripts, systemd) and multiple uncoordinated half-baked
attempts to take it to different directions have left the current state
of affairs a bit of a mess. Steve Langasek (rightfully) suggested on
#764841 to use debi
41 matches
Mail list logo
