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 03-18-2012, 06:25 PM
Canek Peláez Valdés
 
Default

On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Mar 18, 2012 3:52 PM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>
>> If the config file doesn't exists, the service will not start, and you
>> can check the reason why with
>>
>> systemctl status sshd.service
>>
>> And of course you can set another mini sevice unit file to create the
>> hostkeys. But I repeat: I think those tasks belong into the package
>> manager, no the init script.
>>
>
> Between installation by package manager and actual execution by the init
> system, things might happen on the required file(s). Gentoo's initscript
> guards against this possibility *plus* providing helpful error messages in
> /var/rc.log
>
> Or, said configuration files might be corrupted; the OpenRC initscript -- if
> written defensively -- will be able to detect that and (perhaps) fallback to
> something sane. systemd can't do that, short of putting all required
> intelligence into a script which it executes on boot.

That is a completely valid point, but I don't think that task belongs
into the init system. The init system starts and stops services, and
monitors them; checking for configuration files and creating hostkeys
is part of the installation process. If something got corrupted
between installation time and now, I would prefer my init system not
to start a service; just please tell me that something is wrong.

However, it's of course debatible. I agree with systemd's behavior;
it's cleaner, more elegant, and it follows the Unix tradition: do one
thing, and doing it right.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-18-2012, 06:48 PM
Michael Mol
 
Default

On Sun, Mar 18, 2012 at 3:25 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan <pandu@poluan.info> wrote:
>>
>> On Mar 18, 2012 3:52 PM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>>
>>> If the config file doesn't exists, the service will not start, and you
>>> can check the reason why with
>>>
>>> systemctl status sshd.service
>>>
>>> And of course you can set another mini sevice unit file to create the
>>> hostkeys. But I repeat: I think those tasks belong into the package
>>> manager, no the init script.
>>>
>>
>> Between installation by package manager and actual execution by the init
>> system, things might happen on the required file(s). Gentoo's initscript
>> guards against this possibility *plus* providing helpful error messages in
>> /var/rc.log
>>
>> Or, said configuration files might be corrupted; the OpenRC initscript -- if
>> written defensively -- will be able to detect that and (perhaps) fallback to
>> something sane. systemd can't do that, short of putting all required
>> intelligence into a script which it executes on boot.
>
> That is a completely valid point, but I don't think that task belongs
> into the init system. The init system starts and stops services, and
> monitors them; checking for configuration files and creating hostkeys
> is part of the installation process. If something got corrupted
> between installation time and now, I would prefer my init system not
> to start a service; just please tell me that something is wrong.
>
> However, it's of course debatible. I agree with systemd's behavior;
> it's cleaner, more elegant, and it follows the Unix tradition: do one
> thing, and doing it right.

I like and see benefit to the systemd approach, honestly, but I don't
think it necessarily follows to say that "that belongs in the
installation process, since it shouldn't be the responsibility of the
init process."

The way things sit currently, Gentoo doesn't default to adding new
services to any runlevel, and in the process of setting up or
reconfiguring a system, services may be added, removed, then possibly
added again. Having a service's launch script perform one-time checks
makes perfect sense in this regard. It's lazy evaluation; you don't do
non-trivial work until you know it needs to be done. (And generating a
2048-bit or 4096-bit SSH key certainly qualifies as non-trivial work!)

Also, I think the "code golf" argument is a poor one; how many lines
something does to meet some particular goal ignores any other intended
goals the compared object also meets. When you're comparing apples to
apples, the argument is fine. When you're comparing apples to oranges,
the argument is weakened; they're both fruits, but they still have
different purposes in the larger context.

In this case, I think the happy medium would be for systemd to start a
service-provided launch script, which performs whatever additional
checks are wanted or desired. Either way, it's the responsibility of
whoever maintains the package for that service.


--
:wq
 
Old 03-18-2012, 06:54 PM
Alan McKinnon
 
Default

On Sun, 18 Mar 2012 13:25:32 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> > Or, said configuration files might be corrupted; the OpenRC
> > initscript -- if written defensively -- will be able to detect that
> > and (perhaps) fallback to something sane. systemd can't do that,
> > short of putting all required intelligence into a script which it
> > executes on boot.
>
> That is a completely valid point, but I don't think that task belongs
> into the init system. The init system starts and stops services, and
> monitors them; checking for configuration files and creating hostkeys
> is part of the installation process. If something got corrupted
> between installation time and now, I would prefer my init system not
> to start a service; just please tell me that something is wrong.

I tend to agree. All most no daemons and services out there check that
their config files are not corrupt. At most they do syntax
checking, throw errors and leave it up to the caller to deal with it in
some appropriate manner. Most often, the caller is a human with a shell.

Same with sshd and all that checking that happens in the init script.
That stuff correctly belongs in the ebuild config phase, or as an
ad-hoc action done by the sysadmin whenever {,s}he feel like it. The
major point being, if the software itself does not perform a certain
check, then the launching script should also not concern itself with
those checks.

[There are exceptions of course, some stuff is brain-dead, like
tac_plus. Nice software, but if it can't write to it's own log files,
it silently stops working and doesn't tell you. To all intents it looks
like it works fine, but doesn't. Presumably, openssh does not fall in
that category of brain-dead software]

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-18-2012, 06:59 PM
Frank Steinmetzger
 
Default

On Sun, Mar 18, 2012 at 01:25:32PM -0600, Canek Peláez Valdés wrote:
> On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan <pandu@poluan.info> wrote:
> >
> > On Mar 18, 2012 3:52 PM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
> >>
> >> If the config file doesn't exists, the service will not start, and you
> >> can check the reason why with
> >>
> >> systemctl status sshd.service
> >>
> >> And of course you can set another mini sevice unit file to create the
> >> hostkeys. But I repeat: I think those tasks belong into the package
> >> manager, no the init script.
> >>
> >
> > Between installation by package manager and actual execution by the init
> > system, things might happen on the required file(s). Gentoo's initscript
> > guards against this possibility *plus* providing helpful error messages in
> > /var/rc.log
> >
> > Or, said configuration files might be corrupted; the OpenRC initscript -- if
> > written defensively -- will be able to detect that and (perhaps) fallback to
> > something sane. systemd can't do that, short of putting all required
> > intelligence into a script which it executes on boot.
>
> That is a completely valid point, but I don't think that task belongs
> into the init system. The init system starts and stops services, and
> monitors them;

That I can agree upon.

> checking for configuration files and creating hostkeys
> is part of the installation process.

But not this. Installation is a one-time event whose lifetime is over once
installation is done.

> If something got corrupted between installation time and now, I would prefer
> my init system not to start a service; just please tell me that something is
> wrong.

Obviously, a service itself knows best about its own config files. So *it*
should check for the files and if they are invalid/non-existent, it should
abort starting and notify the init system.
--
Gruß | Greetings | Qapla'
I forbid any use of my email addresses with Facebook services.

Today’s stress is the good old times of the day after tomorrow.
 
Old 03-18-2012, 09:23 PM
"Walter Dnes"
 
Default

On Sun, Mar 18, 2012 at 03:15:02PM +0200, Alan McKinnon wrote

> Here's what I want:
>
> When the machine starts, I want services X, Y and Z to run. The
> software figures out what order they must start in and how the deps
> work. Clean, neat, easy.

systemd is like Captain Picard of STTNG (Start Trek The Next
Generation) always saying "make it so". *HOW DO YOU "MAKE IT SO"? That
intelligence has to be somewhere. So what alternative do you propose?
A bash or ash script is more guaranteed to run than a binary. Shoving
all that "intelligence" into the service itself, means that the service
has to start up in order to determine whether it's safe for the service
to start up. What's wrong with this picture?

And if systemd is so great, here's my supersystemd

#!/bin/bash
...
...
/etc/init.d/net.lo start
/etc/init.d/net.eth0 start
/etc/init.d/net.sshd start
etc, etc, etc

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 03-18-2012, 09:33 PM
Jon Ciesla
 
Default

Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 18:00UTC (1:00pm EST, 2:00pm EDT) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #699 Proposal to remove the package "tzdata" from Critical Path
.fesco 699

#topic #808 Unretiring policy (or Fedora policies in general) needs a
"common sense" clause
.fesco 808

= New business =

#topic #821 F18 Feature: PCRE 8.30 --
https://fedoraproject.org/wiki/Features/pcre8.30
.fesco 821

#topic #822 F18 Feature: AE1000 USB wifi driver -
https://fedoraproject.org/wiki/Features/AE1000usb
.fesco 822

#topic #823 F18 Feature: Network Manager hotspots -
https://fedoraproject.org/wiki/Features/RealHotspot
.fesco 823

#topic #824 F18 Feature: Rework Package Groups --
https://fedoraproject.org/wiki/Features/ReworkPackageGroups
.fesco 824

#topic #826 F18 Feature: KRB5 Credential Cache Move -
https://fedoraproject.org/wiki/Features/KRB5CacheMove
.fesco 826

#topic #827 F18 Feature: RPM 4.10 -
https://fedoraproject.org/wiki/Features/RPM4.10
.fesco 827

#topic #828 F18 Feature: systemd-journal --
https://fedoraproject.org/wiki/Features/systemd-journal
.fesco 828

= Open Floor =

For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.


--
in your fear, seek only peace
in your fear, seek only love

-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-18-2012, 09:35 PM
Alan McKinnon
 
Default

On Sun, 18 Mar 2012 18:23:37 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Sun, Mar 18, 2012 at 03:15:02PM +0200, Alan McKinnon wrote
>
> > Here's what I want:
> >
> > When the machine starts, I want services X, Y and Z to run. The
> > software figures out what order they must start in and how the deps
> > work. Clean, neat, easy.
>
> systemd is like Captain Picard of STTNG (Start Trek The Next
> Generation) always saying "make it so". *HOW DO YOU "MAKE IT SO"?
> That intelligence has to be somewhere. So what alternative do you
> propose? A bash or ash script is more guaranteed to run than a
> binary. Shoving all that "intelligence" into the service itself,
> means that the service has to start up in order to determine whether
> it's safe for the service to start up. What's wrong with this
> picture?

The intelligence goes in the init system's config file for that service
of course. I know I didn't clearly say so, but that's where it goes.

The information isn't complicated, you need some BEFORE and AFTER type
settings and various other bits and pieces (pid files etc). For services
that don't behave nicely when stopped and started in "regular ways",
supply start/stop/restart/reload functions in the same file that
override the defaults.

In principle it mirrors exactly how portage works with ebuilds.

> And if systemd is so great, here's my supersystemd
>
> #!/bin/bash
> ...
> ...
> /etc/init.d/net.lo start
> /etc/init.d/net.eth0 start
> /etc/init.d/net.sshd start
> etc, etc, etc

No no, you misunderstand me. I'm not saying necessarily that systemd is
great. I'm saying that sysvinit sucks big-time and we've needed
something better for 15 years. Systemd's design seems to fit that bill
nicely (whether it does it in practice remains to be seen)

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 03-19-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 3 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 10 fully signed off packages
* 26 packages missing signoffs
* 4 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (3 total) ==

* netcfg-2.7-1 (any)
* dhcpcd-5.5.4-2 (i686)
* dhcpcd-5.5.4-2 (x86_64)


== Incomplete signoffs for [core] (12 total) ==

* netcfg-2.7-1 (any)
0/2 signoffs
* bash-4.2.024-2 (i686)
1/2 signoffs
* dhcpcd-5.5.4-2 (i686)
0/2 signoffs
* dirmngr-1.1.0-4 (i686)
0/2 signoffs
* lvm2-2.02.95-1 (i686)
1/2 signoffs
* openldap-2.4.30-1 (i686)
0/2 signoffs
* openssl-1.0.1-1 (i686)
0/2 signoffs
* psmisc-22.16-1 (i686)
1/2 signoffs
* syslinux-4.05-4 (i686)
1/2 signoffs
* dhcpcd-5.5.4-2 (x86_64)
0/2 signoffs
* dirmngr-1.1.0-4 (x86_64)
1/2 signoffs
* openldap-2.4.30-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (11 total) ==

* bash-completion-1.99-1 (any)
1/2 signoffs
* libdrm-2.4.32-1 (i686)
0/2 signoffs
* neon-0.29.6-4 (i686)
0/2 signoffs
* nx-common-3.5.0-4 (i686)
0/2 signoffs
* proftpd-1:1.3.4a-4 (i686)
0/2 signoffs
* xf86-video-mga-1.4.13-6 (i686)
0/2 signoffs
* libdrm-2.4.32-1 (x86_64)
0/2 signoffs
* neon-0.29.6-4 (x86_64)
0/2 signoffs
* nx-common-3.5.0-4 (x86_64)
0/2 signoffs
* proftpd-1:1.3.4a-4 (x86_64)
0/2 signoffs
* xf86-video-mga-1.4.13-6 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (3 total) ==

* archlinux-keyring-20120303-1 (any)
0/2 signoffs
* cups-filters-1.0.1-1 (i686)
0/2 signoffs
* cups-filters-1.0.1-1 (x86_64)
1/2 signoffs


== Completed signoffs (10 total) ==

* iproute2-3.2.0-3 (i686)
* openssh-5.9p1-6 (i686)
* bash-4.2.024-2 (x86_64)
* iproute2-3.2.0-3 (x86_64)
* lvm2-2.02.95-1 (x86_64)
* openssh-5.9p1-6 (x86_64)
* openssl-1.0.1-1 (x86_64)
* psmisc-22.16-1 (x86_64)
* syslinux-4.05-4 (x86_64)
* namcap-3.2.3-1 (any)


== All packages in [testing] for more than 14 days (4 total) ==

* cups-filters-1.0.1-1 (i686), since 2012-02-17
* cups-filters-1.0.1-1 (x86_64), since 2012-02-17
* archlinux-keyring-20120303-1 (any), since 2012-03-03
* namcap-3.2.3-1 (any), since 2012-03-04


== Top five in signoffs in last 24 hours ==

1. pierre - 4 signoffs
2. lfleischer - 3 signoffs
 
Old 03-19-2012, 07:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 2 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (2 total) ==

* cdemu-daemon-1.5.0-2 (i686)
0/2 signoffs
* cdemu-daemon-1.5.0-2 (x86_64)
0/2 signoffs


== Top five in signoffs in last 24 hours ==

1. pierre - 4 signoffs
2. lfleischer - 3 signoffs
 
Old 03-19-2012, 12:13 PM
Neil Bothwick
 
Default

On Sat, 17 Mar 2012 22:48:54 -0400 (EDT), Bruce Hill, Jr. wrote:

> And for the Lennart fanboi, his coding is
> so questionable that "Lennartware" has become derogatory slang. (Of
> course, you already know that.)

And this is such a common term nowadays that when Googling for
Lennartware only one reference to it turn up on the first page, and that
is your post!

I suppose by quoting your post I have doubled the popularity of this
commonplace slang :-O

This whole systemd for and against thread has turned up some interesting
points - interspersed with vague handwaving from you.


--
Neil Bothwick

When there's a will, I want to be in it.
 

Thread Tools




All times are GMT. The time now is 08:50 AM.

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