Re: [DNG] OpenRC and Devuan

[Didier Kryn]

Le 04/05/2016 15:44, Rob Owens a écrit :

- Original Message -

From: "Didier Kryn" 
Le 03/05/2016 19:10, Rob Owens a écrit :

Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc.  He'd have to do '/etc/openrc/myservice start'.  Not a
really big deal, but I think it's undesirable to make Devuan's openrc
procedures different (especially when it could be addressed with a
simple symlink).

 Normally the admin invokes the service command,

 sudo service ssh restart
 sudo service nginx status

 etc.

 service could probably be modified to talk to the init system in
charge.

Normally *this* admin never uses the service command because:
I always use it. With some experience you know the service names as 
well as the basic Unix command names.


1) it is not available on all distros or may not be installed


Talking of Debian/Devuan

2) tab completion doesn't always work with the service command (depending
on the distro, I suppose)
3) tab completion always works when you specify the path to the script
and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


Bash tab completion does work - I agree it's rather sophisticated.

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts

[Rainer Weikusat]

Hendrik Boom  writes:
> On Wed, May 04, 2016 at 09:45:24PM +0100, Rainer Weikusat wrote:
>> Stephanie Daugherty  writes:
>> > Process supervision is something I'm very opinionated about. In a number of
>> > high availability production environments, its a necessary evil.
>> >
>> > However, it should *never* be an out of the box default for any
>> > network-exposed service, Service failures should be extraordinary events,
>> > and we should strive to keep treating them as such,
>> 
>> That's based on a particular assumption about how 'automatic restarts'
>> will be used, namely, instead of fixing server errors and not as
>> complement to that: I treat 'server failures' as 'extraordinary events'
>> but users don't (and shouldn't): They should experience as litte down
>> time as technically possible.
>> 
>> [...]
>> 
>> > The second reason is that it will reduce the number of high-quality bug
>> > reports developers receive - if failure is part of the routine, it tends
>> > not to get investigate very thoroughly, if at all.
>> 
>> It greatly reduces the number of "low-quality" (or rather, "no quality")
>> bug reports I receive as I don't (usually) get frantic phone calls at
>> 3am UK time because a server in Texas terminated itself for some
>> reason. Instead, I can collect the core file as soon as I get around to
>> that and fix the bug.
>> 
>> NB: I deal with appliances (as developer) and not with servers (as
>> sysadmin).
>
> An excellent example of why respawning needs to be an option, and the 
> OS should neither force it on or off. 

It's technically an option for 'our' system because the service
supervisor/ monitor is just a command which is (or isn't) used as part
of a complete 'server invocation' (usually from a sysv-style init.d
script) and not a Master Control Program and that's what it should IMHO
be. But I'm surely using it for all 'new' servers.

There are other desirable effects of that, eg, the system becomes (to a
degree) self-healing: Say some server can't currently work because of a
file system permission issue (or other transient problem, eg, disk
full): It's sufficient to remedy the specific problem in order to
restore everything to working order as the affected servers will just
start to work the next time they're restarted after the situation
improved. There's no need to go hunting for "stuff that doesn't run
despite it should" and restart it manually (and consequently, no risk to
overlook something).

But leaving these two general remarks aside, I don't quite understand
what you wanted to express.

?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts

[Hendrik Boom]

On Wed, May 04, 2016 at 09:45:24PM +0100, Rainer Weikusat wrote:
> Stephanie Daugherty  writes:
> > Process supervision is something I'm very opinionated about. In a number of
> > high availability production environments, its a necessary evil.
> >
> > However, it should *never* be an out of the box default for any
> > network-exposed service, Service failures should be extraordinary events,
> > and we should strive to keep treating them as such,
> 
> That's based on a particular assumption about how 'automatic restarts'
> will be used, namely, instead of fixing server errors and not as
> complement to that: I treat 'server failures' as 'extraordinary events'
> but users don't (and shouldn't): They should experience as litte down
> time as technically possible.
> 
> [...]
> 
> > The second reason is that it will reduce the number of high-quality bug
> > reports developers receive - if failure is part of the routine, it tends
> > not to get investigate very thoroughly, if at all.
> 
> It greatly reduces the number of "low-quality" (or rather, "no quality")
> bug reports I receive as I don't (usually) get frantic phone calls at
> 3am UK time because a server in Texas terminated itself for some
> reason. Instead, I can collect the core file as soon as I get around to
> that and fix the bug.
> 
> NB: I deal with appliances (as developer) and not with servers (as
> sysadmin).

An excellent example of why respawning needs to be an option, and the 
OS should neither force it on or off. 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts

[Rainer Weikusat]

Stephanie Daugherty  writes:
> Process supervision is something I'm very opinionated about. In a number of
> high availability production environments, its a necessary evil.
>
> However, it should *never* be an out of the box default for any
> network-exposed service, Service failures should be extraordinary events,
> and we should strive to keep treating them as such,

That's based on a particular assumption about how 'automatic restarts'
will be used, namely, instead of fixing server errors and not as
complement to that: I treat 'server failures' as 'extraordinary events'
but users don't (and shouldn't): They should experience as litte down
time as technically possible.

[...]

> The second reason is that it will reduce the number of high-quality bug
> reports developers receive - if failure is part of the routine, it tends
> not to get investigate very thoroughly, if at all.

It greatly reduces the number of "low-quality" (or rather, "no quality")
bug reports I receive as I don't (usually) get frantic phone calls at
3am UK time because a server in Texas terminated itself for some
reason. Instead, I can collect the core file as soon as I get around to
that and fix the bug.

NB: I deal with appliances (as developer) and not with servers (as
sysadmin).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Arnt Gulbrandsen]

Stephanie Daugherty writes:
Service failures should be extraordinary events, and we should 
strive to keep treating them as such, so that we continue to 
pursue stability. Restarting a service automatically doesn't 
improve stability of that software, it works around an 
instability rather than addressing the root cause - it's a 
band-aid over a festering wound. 


Unix has a few design choices that tend to produce problems like these, 
such as malloc() and its c++ cousin "operator new".


Malloc() is very simple: You ask for memory and get it. The negative side 
of that simplicity is that if you're out of memory (and that happens 
occasionally if a server is run close to capacity) then processes die 
and/or become unresponsive. Such is the tyranny of the Poisson 
distribution.


The failure of a service is analogous in my eyes to the 
tripping of a circuit breaker - it happened for a reason, and 
that underlying reason is probably serious.


Pick your poison: Restart services or add failure handling around all 
malloc() calls. I quite like the former in many cases, even though it 
papers over various unintentional problem as well as provide the 
intentional simplification. But then I like TCP better than NCP, etc.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Steve Litt]

On Wed, 04 May 2016 18:18:02 +
Stephanie Daugherty  wrote:

> Process supervision is something I'm very opinionated about. In a
> number of high availability production environments, its a necessary
> evil.
> 
> However, it should *never* be an out of the box default for any
> network-exposed service, Service failures should be extraordinary
> events, and we should strive to keep treating them as such, so that
> we continue to pursue stability. Restarting a service automatically
> doesn't improve stability of that software, it works around an
> instability rather than addressing the root cause - it's a band-aid
> over a festering wound.

Good point.

> The failure of a service is analogous in my eyes to the tripping of a
> circuit breaker - it happened for a reason, and that underlying
> reason is probably serious. Circuit breakers in houses generally
> don't reset themselves, and either should network-facing services.

Good analogy, good point.

> The biggest concern in any service failure is that a failure was
> caused by an exploit attempt - attacks which exploit bad
> memory-management tend to crash whatever they are exploiting, even on
> a failed attempt. In an environment where such an event has been
> reduced to routine, and automatic restarts are the norm, that
> attacker gets as many attempts as they need, reducing one of the
> first signs of an intrusion to barely a blip on the radar if the
> systems are even being monitored at all.

Makes sense. 

> The second reason is that it will reduce the number of high-quality
> bug reports developers receive - if failure is part of the routine,
> it tends not to get investigate very thoroughly, if at all.
> 
> A third reason is convention and expectation. We've lived without
> process supervision in the *nix world for almost 4 decades now, those
> decades of experienced admins generally expect to be able to kill off
> a process and have it stay down.

Using a supervision suite that automatically respawns, the admin can
still down the process and have it stay down. For instance, in a runit
system, if you want to down ntpd and have it stay down, do the following
as root.

touch /etc/sv/ntpd/down
sv down ntpd

That puppy isn't coming back up again til someone removes the down file.

> 
> Please consider these factors in any implementation of process
> supervision
> - while it's certainly it's a needed improvement for many
> organizations,, it's not something that should just be on by default.

I see no reason to change our default init any time in the near future.
I think any reasonable init can, one way or another, do both respawning
(what Stephanie calls supervision) and oneshots, where if the process
dies, it's dead and gone.

Epoch has an easy way to do either. Sysvinit can do respawn via
its /etc/inittab, but normally does oneshots.

OpenRC only does oneshots, but by running runit or s6 or
daemontools-encore on top of OpenRC respawning can be had.

With runit and s6, oneshots are simply declared in the rc files that
run before any respawned processes. I think but am not sure that s6 has
provisions to run something as a oneshot. But even if they don't,
post-rcfile oneshots can be kludged with run files something like the
following:

==
#!/bin/sh
mydaemon --run-in-foreground
while ! test -f /etc/sv/mydaemon/down; do
  sleep 1000
done
==

I haven't actually tested the preceding, and I'd probably make my own
version of sleep if I actually wanted to do this, but you get the
picture.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] nfs mounts in fstab

[Fernando M. Maresca]

On Wed, May 04, 2016 at 01:55:15PM -0400, Steven W. Scott wrote:
> It sort of reminded me of Ubuntu, where networking issn't activated until
> desktop login time. Once I added the adapters to interfaces and set up the
> wpa_supplicant definitions the fstab mount was successful. Most bothersome
> thing was I couldn't find any messages/logs which indicated the nature of the
> failed mount, maybe because it wasn't attempted at all since no network was
> available?


take a look at /etc/network/nfsmounts.

Best,
Fer

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Stephanie Daugherty]

Process supervision is something I'm very opinionated about. In a number of
high availability production environments, its a necessary evil.

However, it should *never* be an out of the box default for any
network-exposed service, Service failures should be extraordinary events,
and we should strive to keep treating them as such, so that we continue to
pursue stability. Restarting a service automatically doesn't improve
stability of that software, it works around an instability rather than
addressing the root cause - it's a band-aid over a festering wound.

The failure of a service is analogous in my eyes to the tripping of a
circuit breaker - it happened for a reason, and that underlying reason is
probably serious. Circuit breakers in houses generally don't reset
themselves, and either should network-facing services.

The biggest concern in any service failure is that a failure was caused by
an exploit attempt - attacks which exploit bad memory-management tend to
crash whatever they are exploiting, even on a failed attempt. In an
environment where such an event has been reduced to routine, and automatic
restarts are the norm, that attacker gets as many attempts as they need,
reducing one of the first signs of an intrusion to barely a blip on the
radar if the systems are even being monitored at all.


The second reason is that it will reduce the number of high-quality bug
reports developers receive - if failure is part of the routine, it tends
not to get investigate very thoroughly, if at all.

A third reason is convention and expectation. We've lived without process
supervision in the *nix world for almost 4 decades now, those decades of
experienced admins generally expect to be able to kill off a process and
have it stay down.

Please consider these factors in any implementation of process supervision
- while it's certainly it's a needed improvement for many organizations,,
it's not something that should just be on by default.





On Wed, May 4, 2016 at 12:35 PM Steve Litt 
wrote:

> On Tue, 3 May 2016 22:41:48 -1000
> Joel Roth  wrote:
>
> > We're not the first people to think about supporting
> > alternative init systems. There are collections of the
> > init scripts already available.
> >
> > https://bitbucket.org/avery_payne/supervision-scripts
> > https://github.com/tokiclover/supervision
>
> Those can serve as references and starting points, but I don't think
> either one is complete, and in Avery's case, that can mean you don't
> know whether a given daemon's run script and environment was complete
> or not. In tokiclover's case, that github page implies that the only run
> scripts he had were for the gettys, and that's pretty straightforward
> (and well known) anyway.
>
> As I remember, before he had to put it aside for awhile, Avery was
> working on new ways of testing whether needed daemons (like the
> network) were really functional. That would have been huge.
>
> Another source of daemon startup scripts his here:
>
> https://universe2.us/collector/epoch.conf
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.

sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
also cannot coexist.

so openrc is not an init subsystem on its own.

deamontools  are IMHO helpers for broken software like java application
which cannot daemonize itself under unix becaouse of java desing. trying to
convince people that writing unix daemons the old way is badthing(tm).

maybe i should go back to sls.
--
regards
piotr
04-05-2016 18:49, "Steve Litt"  napisał(a):

> On Wed, 4 May 2016 09:54:37 -0400 (EDT)
> Rob Owens  wrote:
>
> > - Original Message -
> > > From: "Steve Litt" 
> >
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > Rob Owens  wrote:
> > >
> > >> I agree with putting each init in its own directory, but sysvinit
> > >> should not own /etc/init.d.  sysvinit stuff should go
> > >> in /etc/sysvinit and by default /etc/init.d should be a link
> > >> to /etc/sysvinit/init.d. The reason is that other init systems may
> > >> expect to own /etc/init.d. For instance, openrc puts all its
> > >> scripts in /etc/init.d (at least on Funtoo it does).
> > >
> > > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > > and the only one I know that wants to do that is systemd.
> > >
> > > I wouldn't change sysvinit's expected files one little bit. Everyone
> > > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > > change to sysvinit would require lots of testing, and who needs
> > > that headache?
>
> > Then you would be designing under the assumption that sysvinit is the
> > "one true way"
>
> Not "one true way", but "it's what we have right now, let's not mess
> with it.
>
> > and that all others must be modified to work around
> > sysvinit -- an init system that you/we are actively attempting to make
> > obsolete (eventually) by way of providing all these alternatives.
>
> The other inits should have had the good sense not to entangle
> themselves with sysvinit, and in fact most of them did have that good
> sense, so for them this is a moot point.
>
> At this point I'm not sure that *any* init system other than sysvinit
> puts its daemon starting code/config under /etc/init.d. But if there is
> such an init system putting its stuff under/etc/init.d, that's some
> serious hubris. They could have taken their own namespace, but no,
> they polluted the namespace used by sysvinit for 30 years. If there is
> such an init system, moving their script/config storage is actually
> correcting a problem caused by the init system.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Wed, 4 May 2016 09:54:37 -0400 (EDT)
Rob Owens  wrote:

> - Original Message -
> > From: "Steve Litt"   
> 
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > Rob Owens  wrote:
> >   
> >> I agree with putting each init in its own directory, but sysvinit
> >> should not own /etc/init.d.  sysvinit stuff should go
> >> in /etc/sysvinit and by default /etc/init.d should be a link
> >> to /etc/sysvinit/init.d. The reason is that other init systems may
> >> expect to own /etc/init.d. For instance, openrc puts all its
> >> scripts in /etc/init.d (at least on Funtoo it does).  
> > 
> > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > and the only one I know that wants to do that is systemd.
> > 
> > I wouldn't change sysvinit's expected files one little bit. Everyone
> > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > change to sysvinit would require lots of testing, and who needs
> > that headache? 

> Then you would be designing under the assumption that sysvinit is the
> "one true way" 

Not "one true way", but "it's what we have right now, let's not mess
with it.

> and that all others must be modified to work around
> sysvinit -- an init system that you/we are actively attempting to make
> obsolete (eventually) by way of providing all these alternatives.

The other inits should have had the good sense not to entangle
themselves with sysvinit, and in fact most of them did have that good
sense, so for them this is a moot point.

At this point I'm not sure that *any* init system other than sysvinit
puts its daemon starting code/config under /etc/init.d. But if there is
such an init system putting its stuff under/etc/init.d, that's some
serious hubris. They could have taken their own namespace, but no,
they polluted the namespace used by sysvinit for 30 years. If there is
such an init system, moving their script/config storage is actually
correcting a problem caused by the init system.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Steve Litt]

On Tue, 3 May 2016 22:41:48 -1000
Joel Roth  wrote:

> We're not the first people to think about supporting
> alternative init systems. There are collections of the
> init scripts already available.
> 
> https://bitbucket.org/avery_payne/supervision-scripts
> https://github.com/tokiclover/supervision

Those can serve as references and starting points, but I don't think
either one is complete, and in Avery's case, that can mean you don't
know whether a given daemon's run script and environment was complete
or not. In tokiclover's case, that github page implies that the only run
scripts he had were for the gettys, and that's pretty straightforward
(and well known) anyway.

As I remember, before he had to put it aside for awhile, Avery was
working on new ways of testing whether needed daemons (like the
network) were really functional. That would have been huge.

Another source of daemon startup scripts his here:

https://universe2.us/collector/epoch.conf

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Default purpy desktop theme

[Go Linux]

On Wed, 5/4/16, fsmithred  wrote:

 Subject: Re: [DNG] Default purpy desktop theme
 To: dng@lists.dyne.org
 Date: Wednesday, May 4, 2016, 11:13 AM
 
On 05/04/2016 11:20 AM, Go Linux wrote:

> Evidently the default purpy desktop graphics didn't make it into the beta.  
> :(  You can find the purpy wallpaper here (among all the others):
>
> https://git.devuan.org/devuan-packages/desktop-base/tree/master/backgrounds
>
> And it looks like the purpy window manager theme is here:
>
> https://git.devuan.org/devuan-packages/clearlooks-phenix-purpy-theme/tree/master
>
> Put the following elements into a directory named Clearlooks-Phenix-purpy:
>
> index.theme
> gtk-3.0
> gtk-2.0
> openbox-3
> metacity-1
> xfwm4
>
> Then put that directory in /usr/share/themes/ .
>
> You will also need to change two settings in Xfce:
>
> 1. Menu > Settings > Appearance > Clearlooks-Phenix-purpy
>
> 2. Menu > Settings > Window Manager > Clearlooks-Phenix-purpy
>
> Hopefully all this will be integrated by beta2.
>
> Enjoy the purpiness!
>
> golinux

> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

@golinux: It looks nice!

@everyone else: the following goes in the gtk-2.0 files to get rid of the
giant icons in the popups on the desktop items (The ones that jump up and
practically bite you when you hover a desktop icon.)

--- cut

style "xfdesktop-icon-view" {
XfdesktopIconView::label-alpha = 0
XfdesktopIconView::selected-label-alpha = 0
XfdesktopIconView::tooltip-size = 0
base[NORMAL] = "#00"
base[SELECTED] = "#94928d"
base[ACTIVE] = "#b5b3ac"
fg[NORMAL] = "#ff"
fg[SELECTED] = "#ff"
fg[ACTIVE] = "#ff" }

# xfce4 stuff
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view"

--- cut



For those unfamiliar with theming, these lines go at the very end of the purpy 
gtk-2.0/gtkrc file.

Or if you'd like to get rid of the gigantic pops globally put that into a 
.gtkrc-2.0 file in you home directory.  Depending on the theme and wallpaper, 
you may need to tweak some of the alpha and color settings.

golinux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Default purpy desktop theme

[fsmithred]

On 05/04/2016 11:20 AM, Go Linux wrote:
> Evidently the default purpy desktop graphics didn't make it into the beta.  
> :(  You can find the purpy wallpaper here (among all the others):
> 
> https://git.devuan.org/devuan-packages/desktop-base/tree/master/backgrounds
> 
> And it looks like the purpy window manager theme is here:
> 
> https://git.devuan.org/devuan-packages/clearlooks-phenix-purpy-theme/tree/master
> 
> Put the following elements into a directory named Clearlooks-Phenix-purpy:
> 
> index.theme
> gtk-3.0
> gtk-2.0
> openbox-3
> metacity-1
> xfwm4
> 
> Then put that directory in /usr/share/themes/ .
> 
> You will also need to change two settings in Xfce:
> 
> 1. Menu > Settings > Appearance > Clearlooks-Phenix-purpy
> 
> 2. Menu > Settings > Window Manager > Clearlooks-Phenix-purpy
> 
> Hopefully all this will be integrated by beta2.
> 
> Enjoy the purpiness!
> 
> golinux
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

@golinux: It looks nice!

@everyone else: the following goes in the gtk-2.0 files to get rid of the
giant icons in the popups on the desktop items (The ones that jump up and
practically bite you when you hover a desktop icon.)

--- cut

style "xfdesktop-icon-view" {
XfdesktopIconView::label-alpha = 0
XfdesktopIconView::selected-label-alpha = 0
XfdesktopIconView::tooltip-size = 0
base[NORMAL] = "#00"
base[SELECTED] = "#94928d"
base[ACTIVE] = "#b5b3ac"
fg[NORMAL] = "#ff"
fg[SELECTED] = "#ff"
fg[ACTIVE] = "#ff" }

# xfce4 stuff
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view"

--- cut
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Default purpy desktop theme

[Go Linux]

Evidently the default purpy desktop graphics didn't make it into the beta.  :(  
You can find the purpy wallpaper here (among all the others):

https://git.devuan.org/devuan-packages/desktop-base/tree/master/backgrounds

And it looks like the purpy window manager theme is here:

https://git.devuan.org/devuan-packages/clearlooks-phenix-purpy-theme/tree/master

Put the following elements into a directory named Clearlooks-Phenix-purpy:

index.theme
gtk-3.0
gtk-2.0
openbox-3
metacity-1
xfwm4

Then put that directory in /usr/share/themes/ .

You will also need to change two settings in Xfce:

1. Menu > Settings > Appearance > Clearlooks-Phenix-purpy

2. Menu > Settings > Window Manager > Clearlooks-Phenix-purpy

Hopefully all this will be integrated by beta2.

Enjoy the purpiness!

golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.

But in such a case I probably would not care what kind of init
subsystem is running on my box. I would not wait for Devuan to get
something with sysvinit.

So if I'm stick to sysvinit why I am to use 'service'? Why learn
another wrapper name which does one thing more if I can always do

env /etc/init.d/blabla start

If I want to have clean environment when starting this script.

But I cannot imagine why should I even use 'env' command (in ideal
world). The init script should use it if it is important that the
environment is cleaned up before starting the application daemon ( or
service if you want to call it this way). This is responsibility of
application maintainer to provide 'idiot proof' starting script.  The
assumption that 'service' command will prepare environment is IMHO  a
mistake, cause the init script _can_ be executed directly as it was
done for a long time, before 'service' command was introduced.

Yes, I think it was bad design decision to make 'service' command to
cleanup environment, not leaving this task to  init script, because of
legacy of /etc/init.d , and because the init.d scripts  can be
executed directly anyway.

If 'service' command  was running scripts from other
folder/schema/subsystem, but not from well known /etc/init.d, than I
would say I should obey the rules of the new command, once decided i
want to use it.

So, please make the system suit your needs, but do not assume what are mine. :)

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[fsmithred]

Someone said they wanted a non-gui way to mount removable devices by
label. Here it is. Let me know if it works for you or not. (It's working
well here.)

I'll add support for labels in the gui pmounter, too.

https://gist.github.com/fsmithred/81a4e1585175c377c32ed2f670ab9ef3

-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Stephan Seitz]

On Wed, May 04, 2016 at 09:44:30AM -0400, Rob Owens wrote:

Normally *this* admin never uses the service command because:


You should because the service command cleans the environment. If you do 
„/etc/init.d/ start” you can have strange results.



1) it is not available on all distros or may not be installed


It is available in SLES11 and Debian (since 6?). Which distro doesn’t 
have service?
Besides, as far as I know the service command is independant from the 
init system, so it works with systemd or sysvinit.



2) tab completion doesn't always work with the service command (depending
  on the distro, I suppose)
3) tab completion always works when you specify the path to the script
  and you are running a bash shell


These are valid points. SLES doesn’t have bash completion in 11. IIRC tab 
completion with service works in SLES 12 which uses systemd.
In Debian or debian based distros you have to install bash-completion and 
activate it in /etc/bash.bashrc.



That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


No, but with bash-completion this works with service in Debian as well.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- Original Message -
> From: "Steve Litt" 

> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens  wrote:
> 
>> I agree with putting each init in its own directory, but sysvinit
>> should not own /etc/init.d.  sysvinit stuff should go in /etc/sysvinit
>> and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
>> The reason is that other init systems may expect to own /etc/init.d.
>> For instance, openrc puts all its scripts in /etc/init.d (at least on
>> Funtoo it does).
> 
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd.
> 
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
> 
Then you would be designing under the assumption that sysvinit is the
"one true way" and that all others must be modified to work around
sysvinit -- an init system that you/we are actively attempting to make
obsolete (eventually) by way of providing all these alternatives.  This 
doesn't make a lick of sense.

>> Even though sysvinit is our default init system these days, we should
>> not design Devuan such that it is difficult to change that in the
>> future.  So put sysvinit stuff in its own directory just like all the
>> other inits.
> 
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
> 
It is also trivial to do with a symlink.

> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.
> 
I have only used openrc on Funtoo, but there is no intermixing with 
sysvinit there.  It is exclusively openrc in /etc/init.d.  Are you using
a distro where /etc/init.d contains both openrc scripts and sysvinit 
scripts?

-Rob
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rainer Weikusat]

Robert Storey  writes:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
> for anyone else, of course, but I tend to think the sort of people who are
> attracted to Devuan see the virtue of simplicity.

The main attraction of the sysvinit-based system is its simpliciy: While
init has a few features it could do without (eg, process management), it
mostly just invokes (configurable) external programs with certain
arguments in response to system state change requests. By itself, that's
flexible enough to implement anything on top of it (including the
'historically grown' init.d script thicket).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- Original Message -
> From: "Didier Kryn" 

> Le 03/05/2016 19:10, Rob Owens a écrit :
>> Yes, but then when an openrc user wants to start/stop a service, he
>> cannot do '/etc/init.d/myservice start' like he could do on any other
>> OS using openrc.  He'd have to do '/etc/openrc/myservice start'.  Not a
>> really big deal, but I think it's undesirable to make Devuan's openrc
>> procedures different (especially when it could be addressed with a
>> simple symlink).
> Normally the admin invokes the service command,
> 
> sudo service ssh restart
> sudo service nginx status
> 
> etc.
> 
> service could probably be modified to talk to the init system in
> charge.

Normally *this* admin never uses the service command because:

1) it is not available on all distros or may not be installed
2) tab completion doesn't always work with the service command (depending
   on the distro, I suppose)
3) tab completion always works when you specify the path to the script
   and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] network-manager depends on libpam-systemd (Daniel Reurich)

[Didier Kryn]

Le 04/05/2016 10:30, Joel Roth a écrit :

How do you like ceni? There isn't much detail in the man
page. How does it deal with suspend? (With wicd-gtk I have
to reconnect after wake-up.)

I see there is a debian package available here:


I have ceni installed on my Debian-wheezy. I just gave it a try and 
now remember I did it and reported to the list already.


I just removed the SSID I was connected on from my wpa config, 
brought down then up wlan0 and launched ceni. It offers me two 
possibilities: Either scan and manage a connection to some available 
SSID, or configure wpa_supplicant for roaming, which means mess up with 
my already made config. If I select the last case, I am warned that, 
after that, I can use wpa_gui to enter new wifi stations. Therefore Ceni 
doesn't bring any value at all - at least to me, since I'm able to read 
a howto and edit a text file.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT Re: cloud

[Noel Torres]

Hendrik Boom  escribió:


On Wed, May 04, 2016 at 11:23:05AM +, hellekin wrote:

On 05/03/2016 06:05 PM, Steve Litt wrote:
> On Tue, 3 May 2016 10:44:29 +
> hellekin  wrote:
>
>
>> I want to call it "rabbit" or "Shub-Niggurath"
>
> I fear the latter name would not be well received in the United States.
>

Would replacing "Shub-Niggurath" with "Henry Ford" make it any better?


Not if it means there's a space in a name, that has to be escaped  
every time you mention it.


Agreed, spaces suck. Anyway, since The Black Goat of the Woods with a  
Thousand Young may be a bit misguided name for some fundamentalists of  
minor religions (don't get me wrong, any religion is minor except that  
of The Flying Spaghetti Monster), maybe we can all agree in calling it  
"HPLovecraft-init".


Regards

Noel
er Envite


binB23AnvLgnv.bin
Description: Clave PGP pública


pgplBMZXzgIKi.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] e: network-manager depends on libpam-systemd (Daniel Reurich)

[emninger]

Am Wed, 04 May 2016 10:07:01 +
schrieb dng-requ...@lists.dyne.org:

> How do you like ceni? There isn't much detail in the man
> page. How does it deal with suspend? (With wicd-gtk I have
> to reconnect after wake-up.)
> 
> I see there is a debian package available here:
> 
> http://aptosid.com/debian/pool/main/c/ceni/

I do not remember exactly, no debianlike system in this moment. I used
it with siduction on a samsung ultrabook. The wifi reconnected
correctly, but i had problems with tor (which had to be restarted after
any wake-up).

As for wicd-gtk, i do not have any problem with reconnection - on
different machines (some broadcom with b43 driver or some with atheros
and ath9k driver).

A problem with ceni could be, if there is going wrong something with
the connection the boot up will be dead slow, because ceni looks for at
least a minute to establish a connection  and it runs before any X.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Hendrik Boom]

On Wed, May 04, 2016 at 08:10:40AM +0100, Simon Hobson wrote:
> Steve Litt  wrote:
> 
> > There's a special place in hell for people using ambiguous
> > abbreviations, acronyms, and nicknames.
> 
> You mean, like the whole IT industry - and in fact pretty well any industry ? 
> Such terms are routinely used because they make speech and writing less 
> verbose. I did my apprenticeship in an engineering (plenty of acronyms there) 
> firm that was also a supplier to the UK's navy - the defence field is a sea 
> of acronyms* :-)
> 
> But back to our world, "pen testing" is a common term. A few seconds with 
> ${preferred_search_engine} would come up with a definition.

The trouble is with abbreviations that are common words in their own 
right, with the result that people not knowing it's an abbreviation 
will get a quite different meaning, and not know they've 
misunderstood.

-- hendrik
.
> 
> * I was involved in software, and one day for a bit of light amusement 
> decided to fully expand the acronym of something I was working on. Thing is, 
> some of the letters in the acronym were in fact initial of other acronyms, 
> and by the time I'd fully expended all the levels I think a 6 letter acronym 
> became a whole paragraph !
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OT Re: cloud

[Hendrik Boom]

On Wed, May 04, 2016 at 11:23:05AM +, hellekin wrote:
> On 05/03/2016 06:05 PM, Steve Litt wrote:
> > On Tue, 3 May 2016 10:44:29 +
> > hellekin  wrote:
> > 
> > 
> >> I want to call it "rabbit" or "Shub-Niggurath"
> > 
> > I fear the latter name would not be well received in the United States.
> > 
> 
> Would replacing "Shub-Niggurath" with "Henry Ford" make it any better?

Not if it means there's a space in a name, that has to be escaped every time 
you mention it.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OT Re: cloud

[hellekin]

On 05/03/2016 06:05 PM, Steve Litt wrote:
> On Tue, 3 May 2016 10:44:29 +
> hellekin  wrote:
> 
> 
>> I want to call it "rabbit" or "Shub-Niggurath"
> 
> I fear the latter name would not be well received in the United States.
> 

Would replacing "Shub-Niggurath" with "Henry Ford" make it any better?

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[fsmithred]

On 05/04/2016 05:58 AM, Boruch Baum wrote:
> On 2016-05-02 08:12, fsmithred wrote:
>> No support for file system labels at this time. If someone can tell me a
>> reliable way for unprivileged user to get the labels, I'll add it. Feel
>> free to use these scripts as they are or as motivation to create something
>> better.
> Are you looking for?:
> 
>   ls -l /dev/disk/by-label
> 

Yes, I am, thank you! I thought I looked in /dev/disk/by- and didn't find
that. OK, now I feel like I was looking for my glasses, and you let me
know they were in my hand.

This works:

ls -l /dev/disk/by-label |  awk -v pattern=${device##*/} '$0 ~ pattern {
print $9 }'

Back in business. Thanks.
-fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Steve Litt  escribió:
[...]

I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually be
incorporated into the packages after they've been proven correct.


Better expressed that way :)


What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).


Agreed


At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith).


Yes, but Devuan packagers can (almost blindly) copy scripts from wiki  
to packages, slowly, to allow that happen in a proper way.


[some things about how to package, with which I don't agree but that  
aren't priority]


Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.


Agreed

Noel
er Envite


bin1LIy6CVg5O.bin
Description: Clave PGP pública


pgp_bAm5Q0Yuz.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[Didier Kryn]

Le 04/05/2016 11:58, Boruch Baum a écrit :

On 2016-05-02 08:12, fsmithred wrote:

No support for file system labels at this time. If someone can tell me a
reliable way for unprivileged user to get the labels, I'll add it. Feel
free to use these scripts as they are or as motivation to create something
better.

Are you looking for?:

   ls -l /dev/disk/by-label




Good point! It is exactly to fill that directory and 
/dev/disk/by-uuid that udev/vdev invoke blkid.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[Boruch Baum]

On 2016-05-02 08:12, fsmithred wrote:
> No support for file system labels at this time. If someone can tell me a
> reliable way for unprivileged user to get the labels, I'll add it. Feel
> free to use these scripts as they are or as motivation to create something
> better.
Are you looking for?:

  ls -l /dev/disk/by-label

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Supervision scripts (was Re: OpenRC and Devuan)

[Joel Roth]

We're not the first people to think about supporting
alternative init systems. There are collections of the
init scripts already available.

https://bitbucket.org/avery_payne/supervision-scripts
https://github.com/tokiclover/supervision


-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] For all you automounter programmers

[Didier Kryn]

Le 03/05/2016 19:12, fsmithred a écrit :

@Didier - try pulling out the usb stick and replacing it with a different
one. When I do that, the cache does not get updated.

didn't try that. will do tonight :-)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Fwd: For all you automounter programmers

[Didier Kryn]

Le 03/05/2016 17:27, fsmithred a écrit :

On 05/03/2016 09:34 AM, Didier Kryn wrote:

Le 03/05/2016 14:48, hellekin a écrit :

On 05/03/2016 12:16 PM, Jim Murphy wrote:

Problem, blkid uses a cache that is only updated when root runs blkid.
Any changes are not automatically updated.  A user only sees the cache.

The issues is, fsr is trying to do everything as a "user" so tools like
lsblk and blkid don't work for this case. For blkid, the cache will not
be up to date when say a flash-drive is add/or removed.


You might be interested in using jaromil's version of sup to compile a
static binary that will elevate privilege for "that" user running *blk*
commands.  Not as sexy as running without root, but a good use-case for
the new hashing functionality of sup.

https://git.devuan.org/jaromil/sup


 Until I can see this myself (this evening at home on devuan-jessie) I
assume the hotplug manager will invoke blkid upon insertion of the device,
and therefore it will take care of updating blkid's cache. This is
consistent with the very idea of having a cache; it would make no sense
otherwise. blkid is explicitely designed to be invoked by udev (it has an
"udev" formatting switch) and we know vdev invokes it as well.

 I can see possible reasons why it wouldn't be invoked:

 1) the system doesn't use a hotplugger (either static, or devtmpfs)
 2) udev has been replaced by eudev and eudev does otherwise.
 3) udev now makes function calls to blkid's library instead of
invoking the program, and the cache is only maintained by the program.


  Jim, did you try '/sbin/blkid -c /dev/null' ? This bypasses the
cache. For me, it shows only the hot-plugged devices and not the main hard
disk.


Didier


Here's a fourth reason (I think) - gvfs is not installed. If it were, I
wouldn't need to create a way to mount removable drives, I'd just click
the icon when it pops up. But that's not going to change right now - I
want to see how far I can get without libsystemd0 and without adding
outside repos.

/sbin/blkid -c /dev/null does not work for unprivileged user.

Jim suggested two possible solutions to this problem - maybe a udev rule
could do it (I don't know) or add the user to the disk group.
One solution I thought of is to give sudo NOPASSWD privs to the user for
/sbin/blkid. I don't like any of those solutions.

I have a working script that will mount removable devices by label if one
exists, or by device if there's no label. It works for usb,sd/mmc and
cd/dvd. This is a command-line only script (no yad or zenity needed) and
the solution I wrote into the script is to add 'su -c blkid' which
completely defeats the reason for using pmount. So, it's more a proof of
concept than a useful tool. I'll post it (not here in mailing list) if
anyone is interested in playing with it.

Another idea I had is that maybe there is some perl module that can access
this information for the user, without invoking root. If that's the case,
maybe I'll dust off the perl books and see what I can do.

-fsr



I made experiments yesterday evening with a laptop running 
devuan-jessie:


1) '/sbin/blkid -c /dev/null' , invoked by non-root, produces no 
result.


2) '/sbin/blkid' , invoked as non-root, lists all connected block 
devices. I don't know why this does not work for you. Sure I have gvfs 
installed, but I doubt it has any relation with the operations of blkid.


For me, this shows that blkid is invoked by udev when the device is 
connected and the cache is updated. In the absence of a config file for 
blkid, which is the case on Devuan-Jessie, the cache of blkid is 
/run/blkid/blkid.tab and it is a readable text file. It could be read 
directly by any application.


BTW, I did this on tty1, with no running DE, and I noticed 
something abnormal: the startup hangs on after spawning slim until a 
first graphical session is started. As long as no graphical session has 
been started, there is no getty running on any of the virtual consoles.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Wed, 04 May 2016 06:47:06 +
Noel Torres  wrote:

> Steve Litt  escribió:
> 
> > On Mon, 2 May 2016 22:15:44 -1000
> > Joel Roth  wrote:
> >
> >  
> >> The problem with supporting multiple init systems is that
> >> there is an init script for each service that has to be
> >> ported or rewritten.  
> [...]
> > It's a documentation task. If we had a wiki upon which users could
> > write their successful init scripts/run scripts/EpochConfigs etc,
> > this task would be removed from upstream developers, who never
> > should have had this responsibility in the first place.  
> 
> We can use a wiki for collecting this, but the scripts should be in  
> packages, and should be installed, so maybe this wiki might help  
> creating bug reports for the maintainers to just add these files to  
> their packages.
> 
> It is not conceivable that a user that wants a
> different-than-default init system must copy scripts from the wiki
> while the machine can not yet access the wiki as it is still being
> installed!

Oh yeah, that issue :-)

I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually be
incorporated into the packages after they've been proven correct.

What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).

At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith). 

Let's talk about a person who is partial enough to a specific init
system to alt-init Devuan. Their system installation is sysvinit, and
then later they install OpenRC or runit or s6 or Epoch. Let's take
runit as an example, as it's the only one I know a lot about. They
install the runit package, which comes with run scripts for tty1-tty6,
sshd, wpa_supplicant, dhcpcd, ntpd, httpd. Then, as they need software
without included run scripts, they write the run scripts. Because
they're enthusiasts of that init system, they probably do it well. Then
they put the run scripts on the wiki, others test them, and over time
they become tested enough to go in the runit package. Nobody has an
undue amount of work, and nobody's working on something they don't give
a flying flamingo about. 

Over time each init will end up with init scripts/run scripts,
EpochConfs for lots and lots of daemons. Maybe at some point the
scripts for a given init system will be complete enough that they can
be transferred to the daemon's package, but I don't see a need to rush
that.

Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

On Wed, May 04, 2016 at 01:03:08PM +0800, Robert Storey wrote:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. 

Many people agree that sysvinit with its symlinks and run
levels is overly complex for the common use case.

> The main issue with switching from sysvinit to something else is just
> finding someone willing to do the work.

As I wrote before, hundreds of scripts could be involved.
Daniel Reurich observed that bug reports could be filed
with each package, and then resolved as scripts are added.

The upstream software developer may not care about multiple
init systems, so the burden would be on the Devuan package
developer to support them. It would be great if some
automated tools could do this, but programmatically parsing
and transforming shell scripts is a task that will be
fraught with complexity. Perhaps some examples to follow for
each init system will be enough for packagers,
or init system advocate teams to write the necessary
scripts.

cheers,

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Simon Hobson]

Steve Litt  wrote:

> There's a special place in hell for people using ambiguous
> abbreviations, acronyms, and nicknames.

You mean, like the whole IT industry - and in fact pretty well any industry ? 
Such terms are routinely used because they make speech and writing less 
verbose. I did my apprenticeship in an engineering (plenty of acronyms there) 
firm that was also a supplier to the UK's navy - the defence field is a sea of 
acronyms* :-)

But back to our world, "pen testing" is a common term. A few seconds with 
${preferred_search_engine} would come up with a definition.

* I was involved in software, and one day for a bit of light amusement decided 
to fully expand the acronym of something I was working on. Thing is, some of 
the letters in the acronym were in fact initial of other acronyms, and by the 
time I'd fully expended all the levels I think a 6 letter acronym became a 
whole paragraph !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Steve Litt  escribió:


On Mon, 2 May 2016 22:15:44 -1000
Joel Roth  wrote:



The problem with supporting multiple init systems is that
there is an init script for each service that has to be
ported or rewritten.

[...]

It's a documentation task. If we had a wiki upon which users could
write their successful init scripts/run scripts/EpochConfigs etc, this
task would be removed from upstream developers, who never should have
had this responsibility in the first place.


We can use a wiki for collecting this, but the scripts should be in  
packages, and should be installed, so maybe this wiki might help  
creating bug reports for the maintainers to just add these files to  
their packages.


It is not conceivable that a user that wants a different-than-default  
init system must copy scripts from the wiki while the machine can not  
yet access the wiki as it is still being installed!


Regards

Noel
er Envite


binVWvKQgNw1c.bin
Description: Clave PGP pública


pgpWRVmrSNERQ.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

On Wed, May 04, 2016 at 12:55:09AM -0400, Peter Olson wrote:
> > On May 3, 2016 at 11:43 PM Joel Roth  wrote:
> 
>  [...]
> 
> > Interesting, I thought /sbin was historically for statically
> > linked executables needed at boot time, or for system
> > recovery.
> 
> The /sbin and /usr/sbin are analogous to /bin and /usr/sbin but they contain
> programs for administrative purposes such as adduser which require privileges
> and are not needed by user logins or might not be expected for ordinary user
> access.
> 
> On some distros ifconfig is in one of these and isn't visible to the user, 
> even
> though it might be useful.
> 

This is just a mishap. You might include /sbin in your PATH and
ifconfig automagically becomes available to you. Not all the
executables in /sbin and /usr/sbin require root privilege to run...

PDSCE

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Duplicate sources.list entry

[KatolaZ]

On Wed, May 04, 2016 at 01:34:20AM +, Go Linux wrote:

[cut]

> 
> 
> 
> Thanks Ozi Traveller.
> 
> I found this in /etc/apt/sources.list.d: 
> 
> # autogenerated by devuan-baseconf
> # decomment following lines to  enable the developers devuan repository
> deb http://auto.mirror.devuan.org/merged/ jessie main 
> # deb-src http://packages.devuan.org/devuan/ jessie main 
> 
> 
> I guess I should comment out that one line.
> 
> Since I didn't have this error before upgrading to the beta, I assume it is 
> something that occurred during that process.  You might want to look into it 
> Centurion_Dan.
> 

The file has been automatically generated by devuan-baseconf, as the
first line seems to say.

PDSCE

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Jim Murphy  escribió:
[...]

UNIX and lookalikes have been able to boot into single user mode
with a small root filesystem without the need for /usr, /var or ...
There are still admins that have split any number of these directories
into their own filesystems for various reasons. I guess you can call
these use-cases. By placing the init systems in /var we again remove
another choice for admins/users.  If we are about choice, then /var
may not be the best place to put inits.

[...]

For sure my installations have /var separated, to avoid  
/var/log/syslog growing enough to fill / and thus causing the system  
to fail.


The only things I consider to be on root filesystem are:
/ (obviously)
/etc
/lib
/bin
/sbin

Not even /boot, which I use to have in a separated partition  
independently in each hard disk, while all the others are in a  
replicated RAID among all disks.


From this, I derive that init system files should be in /etc  
(configuration) and /sbin (executables). For the sake of keeping  
things as they are, shell scripts could continue in /etc as in  
/etc/init.d so I strongly raise hand for /etc/orc or /etc/wtf-is .


Regards

Noel
er Envite


bin7zwZdCxPow.bin
Description: Clave PGP pública


pgpfq2MMHqQCU.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng