Re: [DNG] Systemd Shims

[Didier Kryn]

Le 16/08/2015 06:27, Steve Litt a écrit :

On Sun, 16 Aug 2015 14:26:41 +1200
Daniel Reurich  wrote:


>On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"
>  wrote:

> >All that I ever try to say that I think there should be room for
> >both sorts to make Devuan a home.  Yes, I think Devuan should have
> >systemd as an option, but only as an option - never part of the base
> >system.
> >
> >

>No no no!
>
>If you Devuan with systemd install Debian.

I agree. Daniel, I don't know why it's so hard for some people to
understand. We're all for freedom of choice, but catering to this
mythical Devuan user who wants systemd reduces*our*  choices by making
it much harder to (I've been told not to use the neologism), ummm,
decontaminate Devuan.


This has been discussed so many times already! It sitll has to be 
proven that offering systemd is possible without abandoning freedom of 
choice for many other things.


Why should we bother when there's a simple way for Devuan to 
provide Systemd:

http-redirect -> www.debian.org

This is not about shims, though. I don't want to participate in the 
shims thread proper.


Nice day folks :-)
Didier

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

Re: [DNG] Systemd Shims

[Didier Kryn]

Le 16/08/2015 08:11, Laurent Bercot a écrit :

On 16/08/2015 06:53, Steve Litt wrote:

The toughest part is how to store the passwords in a way that isn't a
security problem.


 Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature
(which is strange, because hostapd supports a wpa_psk_file option).
 So you have to store the passwords (or the equivalent binary PSKs) in 
the
configuration file, and make this file readable only from root - which 
means

you need a small suid root binary to write the whole configuration file.

 Password security isn't a problem that you can fix at the interface 
level,
it's something that must be tightly integrated with the tool that uses 
the

password - and there's no doubt wpa_supplicant could do better here.



wpa_supplicant.conf contains very little apart from the authentication
information for the various wifi stations, therefore there is little need to
put the passwords in different files.

Wpa_gui discovers the properties of the stations (crypting and 
authentication
methods) and prompts you for the passwords. Then it passes all 
connection and

authentication information to wpa_supplicant, which stores them. I bet the
same is possible with wpa_cli and wpa_actions, which are packaged with
wpa_supplicant.

I have made my wpa_gui suid, but I just read the following in 'man 
wpa_cli':


# The  control  interface  of  wpa_supplicant  can  be configured  to  
allow  non-root  user access
#  (ctrl_interface GROUP= parameter in the configuration file). This 
makes it possible to run wpa_cli

#  with a normal user account.

Just 'adduser myself wifigroup'

Didier

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

Re: [DNG] Devuan and upstream

[Simon Hobson]

Go Linux  wrote:

> I once investigated helping a friend use some open source software on her 
> Mac. A program that was free (gratis) in the Linux community was available in 
> the Apple app store for $30!  That really pissed me off and soured me even 
> more on Apple than before (if that was possible).

If ti was GPL then it would have been available free of charge if you looked in 
the right place. Contrary to some opinions, Apple do behave themselves in this 
respect.

Did you try Fink or Macports ?
http://www.finkproject.org
https://www.macports.org

I've come across other cases where "free" software has been available in a 
store for real money. In my case I have a couple of packages on my Android 
phone where I paid for them through the Google store although I could have got 
them free elsewhere - just for the convenience factor, plus it's a source of a 
small amount of income for the projects concerned.

But this is off-topic for here.



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

[DNG] Issue 56 ??

[aitor_czr]

I haven't received any email belonging to Dng Digest,Vol11,Issue 56...
They jumped from 55 to 57.
Any incidence?

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

[DNG] About shims and systemd in devuan

[Nextime]

The devuan policy about systemd shims and systemd in devuan as been already 
exaustively discussed many times, and can i reassume it as follow:

Devuan will not work to support systemd and will not work against it. We will 
not do any effort to support it, if someone want to work to package it in a way 
where it works WITHOUT needs support for any other package depending on it, we 
will consider to add it as an option, but we will NOT accept it if it ask us to 
put it in dependency tree.
As for how it work, this policy put effectively it in the "we will not support 
it" list ad systemd without dependecy to it is like vaporware.

For shims, we will not introduce shims, as the work to trace abi from systemd 
components make it just a shit. We will optionally consider to reimplement some 
funcionalities we consider usefull from systemd, but in a unix/kiss way, so, 
probably without dbus, or not compatible with systemd: we want to have the few 
good funcionality that are present in systemd, but we want them better 
implemented.
-- 
nextime
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] About shims and systemd in devuan

[James Powell]

Thank you.

If people want Devuan with systemd or anything close to it, use Debian aka 
CoreOS w/ dpkg.

People came to Devuan to have choice, mainly a choice to avoid systemd at all 
costs.

-Jim

From: Nextime
Sent: ‎8/‎16/‎2015 5:59 AM
To: dng@lists.dyne.org
Subject: [DNG] About shims and systemd in devuan

The devuan policy about systemd shims and systemd in devuan as been already 
exaustively discussed many times, and can i reassume it as follow:

Devuan will not work to support systemd and will not work against it. We will 
not do any effort to support it, if someone want to work to package it in a way 
where it works WITHOUT needs support for any other package depending on it, we 
will consider to add it as an option, but we will NOT accept it if it ask us to 
put it in dependency tree.
As for how it work, this policy put effectively it in the "we will not support 
it" list ad systemd without dependecy to it is like vaporware.

For shims, we will not introduce shims, as the work to trace abi from systemd 
components make it just a shit. We will optionally consider to reimplement some 
funcionalities we consider usefull from systemd, but in a unix/kiss way, so, 
probably without dbus, or not compatible with systemd: we want to have the few 
good funcionality that are present in systemd, but we want them better 
implemented.
--
nextime
___
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] About shims and systemd in devuan

[Hendrik Boom]

On Sun, Aug 16, 2015 at 06:05:15AM -0700, James Powell wrote:
> Thank you.
> 
> If people want Devuan with systemd or anything close to it, use Debian aka 
> CoreOS w/ dpkg.
> 
> People came to Devuan to have choice, mainly a choice to avoid systemd at all 
> costs.

That's certainly the choice that gave rise to devuan in the first place.  
If the trend to dictatorship in the mainline Linux distros continues, 
people may well be coming here for other choices.  Maybe  will 
be escaping oppresssion from other components that is even more intense 
than what systemd imposes, but still need systemd ... 

I can see situations in the far future when we might want to reconsider.
But for now, "just use Debian" is a fine answer.

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

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Haines Brown]

On Sat, Aug 15, 2015 at 12:04:32PM -0400, Steve Litt wrote:
> On Sat, 15 Aug 2015 07:43:04 -0400
> Haines Brown  wrote:
> 
> 
> > I purged and reinstalled xorg without luck. Installed were
> > libglu1-mesa, x11-apps, x11-session-utils, x11-server-utils, xinit,
> > xorg, xorg-docs-core.
> > 
> > The xorg log tells me that it is using as system configuration
> > directory, /usr/share/X11/xorg.c.
> 
> What happens when you try it after manually creating the directory?

Let me start by noting that I'm unclear about the device configuration
file. On another disk on the same machine that I'm running devuan, there
is a Wheezy installation that has no no /etc/X11/xorg.conf.d/ directory,
and off hand the configuration files in /usr/share/X11/xorg.conf.d/
don't have a Device section. I also run Wheezy on another machine, and
it has a 20-nvidia.conf file with a Device section. I don't recall that
I did anything different for the installations, but nevertheless one
uses the nouveau module and the other must somehow use a default Section
definition.

I did as you suggest, creating a /etc/X11/xorg.conf.d directory and
putting into it a 20-nouveau.conf file with:

Section "Device"
  Identifier "MSI NX 8500GT"
  Driver "nouveau"
EndSection

For the Identifier I just put my card name as a guess. The Xorg log
shows that the nouveau driver loads and so I guess the Identifier works,
but not sure.

When I startx, I'm still in vesa (?) mode. The Xorg log file says it
is using configuration directory /etc/X11/xorg.conf.d/ directory. The
only error is: 

(EE) NOUVEAU(0): [COPY] failed to allocate class

don't know what this means, and the Xorg wiki site no help.

I did a # Xorg -configure to create a /root/xorg.conf.new. It has

  Section "Device"
Identifier "Card(0)"
Driver "nouveau"
  EndSection

When I do # X -config /root/xconf.new, I'm taken to a blank screen and
I'm hung there and so have to delete the xorg.conf.new file and do a hot
reboot.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[T.J. Duchene]

Well, I suppose the topic has been beat up enough, but I just wanted to clear 
up something before moving on. I want you to understand why I came to the 
Devuan list in the first place. I came here under the assumption that Devuan 
was going to be a "better Debian" without the shove the Technical Committee 
and the failure of the GR  gave to one single point of view.  

As far as I can tell, Devuan is about the same, with one difference.  Devuan is 
willing to package systemd if it can be done cleanly - but nobody wants to.  
Debian will support System 5, again until nobody wants to.  

I suppose I should be used to that.  The fault is mine.  I expect too much, 
when everyone feels that they have been burned one too many times.

Nexttime: "Devuan will not work to support systemd and will not work against 
it. We will not do any effort to support it, if someone want to work to package 
it in a way where it works WITHOUT needs support for any other package 
depending on it, we will consider to add it as an option, but we will NOT 
accept it if it ask us to put it in dependency tree. "

That is all I EVER suggested, with one slight difference.  That if it is 
somehow possible in the future to maintain two versions of the same package 
that the default version would be without systemd, but the other would be 
available at the users' option as a matter of choice.

Steve Litt:

"Considering the source you're replying to, it's not worth even worrying 
about. 

The other side sure doesn't respect freedom of choice. That's why 
we're here in the first place. Inclusion of systemd tends to reduce 
freedom of choice, not enhance it. "

I am not on the "other side" of the argument.  To me, there is no argument to 
begin with.  I am neither an advocate for systemd nor am I an advocate for 
System 5.  Both have issues and are basically different approaches to the same 
problem.

That Steve objects to me personally  - "the source"  - is of course his own 
affair and I can care less.  In saying this it is not a condemnation of him. I 
just do not want other people to think he knows what's on my mind. For the 
record, he doesn't even know me.

Whatever his opinion of me, I respect his position just the same.



Didier Kryn:

"This has been discussed so many times already! It sitll has to be 
proven that offering systemd is possible without abandoning freedom of 
choice for many other things."

Honestly, Didier, I think it already has.  Gentoo handles the situation very 
well. It is possible, but it might require some tweaking to get the packages 
right.

"Why should we bother when there's a simple way for Devuan to provide Systemd:
 http-redirect -> www.debian.org"

I'm not accusing anyone of anything but I genuinely I do not understand that.  
Since the tone of Nexttime's post suggests that he/she would prefer that this 
discussion end, please message me privately if you have something to add.  I 
don't understand how Devuan can grow if the general attitude on the mailing 
list is "go away."
  


Have a great day everyone!  (Yes both Steve and Didlier too!)

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

Re: [DNG] Systemd Shims

[Edward Bartolo]

I would like to humbly add my little contribution to this thread.

I am posting using Devuan 64 bit connected to a home WIFI without any
network managers. I connect by using separate /etc/network/interfaces
files. The one for my home wifi is in /etc/network/interfaces while
the rest are saved under my home directory.

To connect, I use the command as root:
ifup wlan0 -i an-interfaces-file

My experience is this is a reliable connection. When I used wicd it
used to disconnect very frequently. I also used desktop network
managers, but these now many need systemd as a dependency.

My point is, what I do manually, can be done through code resulting in
a simple application. The advantage I see is, it would be standalone.

I am tempted to create this application to automate my connection, but
most probably, as I am more prolific in Delphi Pascal, the language of
choice  will be Lazarus Pascal. I can write C++ GUI applications but
that requires more effort on my part. As long as logic programming in
C/C++ that is on the same level if not easier.

The hardest part seem to be allowing the ifup command to run with root
privileges.

On 16/08/2015, T.J. Duchene  wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to
> clear
> up something before moving on. I want you to understand why I came to the
> Devuan list in the first place. I came here under the assumption that Devuan
> was going to be a "better Debian" without the shove the Technical Committee
> and the failure of the GR  gave to one single point of view.
>
> As far as I can tell, Devuan is about the same, with one difference.  Devuan
> is
> willing to package systemd if it can be done cleanly - but nobody wants to.
> Debian will support System 5, again until nobody wants to.
>
> I suppose I should be used to that.  The fault is mine.  I expect too much,
> when everyone feels that they have been burned one too many times.
>
> Nexttime: "Devuan will not work to support systemd and will not work against
> it. We will not do any effort to support it, if someone want to work to
> package
> it in a way where it works WITHOUT needs support for any other package
> depending on it, we will consider to add it as an option, but we will NOT
> accept it if it ask us to put it in dependency tree. "
>
> That is all I EVER suggested, with one slight difference.  That if it is
> somehow possible in the future to maintain two versions of the same package
> that the default version would be without systemd, but the other would be
> available at the users' option as a matter of choice.
>
> Steve Litt:
>
> "Considering the source you're replying to, it's not worth even worrying
> about.
>
> The other side sure doesn't respect freedom of choice. That's why
> we're here in the first place. Inclusion of systemd tends to reduce
> freedom of choice, not enhance it. "
>
> I am not on the "other side" of the argument.  To me, there is no argument
> to
> begin with.  I am neither an advocate for systemd nor am I an advocate for
> System 5.  Both have issues and are basically different approaches to the
> same
> problem.
>
> That Steve objects to me personally  - "the source"  - is of course his own
> affair and I can care less.  In saying this it is not a condemnation of him.
> I
> just do not want other people to think he knows what's on my mind. For the
> record, he doesn't even know me.
>
> Whatever his opinion of me, I respect his position just the same.
>
>
>
> Didier Kryn:
>
> "This has been discussed so many times already! It sitll has to be
> proven that offering systemd is possible without abandoning freedom of
> choice for many other things."
>
> Honestly, Didier, I think it already has.  Gentoo handles the situation very
> well. It is possible, but it might require some tweaking to get the packages
> right.
>
> "Why should we bother when there's a simple way for Devuan to provide
> Systemd:
>  http-redirect -> www.debian.org"
>
> I'm not accusing anyone of anything but I genuinely I do not understand
> that.
> Since the tone of Nexttime's post suggests that he/she would prefer that
> this
> discussion end, please message me privately if you have something to add.  I
> don't understand how Devuan can grow if the general attitude on the mailing
> list is "go away."
>
>
>
> Have a great day everyone!  (Yes both Steve and Didlier too!)
>
> T. J.
> ___
> 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] Systemd Shims

[tilt!]

Hi,

wondering what you all have been arguing about :)

The systemd complex is vast and offers many attack vectors.

Just do your thing. :)

Kind regards,
T.

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

Re: [DNG] Issue 56 ??

[Steve Litt]

On Sun, 16 Aug 2015 14:24:35 +0200
aitor_czr  wrote:

> I haven't received any email belonging to Dng Digest,Vol11,Issue 56...
> They jumped from 55 to 57.
> Any incidence?
> 
> Aitor.

I personally don't reply to any email where the subject contains
"Digest", because the more posts with such a subject, the more
confusing the archives (and my folders) get. I doubt I'm alone.

There's a special place in hell for those who, to pander to their own
convenience by making things harder for the hundreds of others on the
list.

Why don't you either get off of digest, or properly subject and trim
your posts?

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] About shims and systemd in devuan

[Steve Litt]

On Sun, 16 Aug 2015 14:58:49 +0200
Nextime  wrote:

> The devuan policy about systemd shims and systemd in devuan as been
> already exaustively discussed many times, and can i reassume it as
> follow:
> 
> Devuan will not work to support systemd and will not work against it.
> We will not do any effort to support it, if someone want to work to
> package it in a way where it works WITHOUT needs support for any
> other package depending on it, we will consider to add it as an
> option, but we will NOT accept it if it ask us to put it in
> dependency tree. 

I hope T.J. has heard this loud and clear. It's settled law now, no
need for him to revisit it.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Simon Hobson]

T.J. Duchene  wrote:

> I am neither an advocate for systemd nor am I an advocate for 
> System 5.  Both have issues and are basically different approaches to the 
> same 
> problem.

If that were the case then there would be no arguments, and probably no Devuan.
If *all* SystemD was was an init system then no problem. But it is not "just 
another init system" - as already done to death, it's like Japanese Knotweed 
spreading it's roots through everything. I don't know the people heading it, 
only the things that have been said. However, I've seen enough from the 
codebase to convince me it's not a project that should be let anywhere near a 
production server.

Perhaps if people stopped saying it's a choice between Sys5 and SystemD as an 
init system then there's be more clarity about the argument.

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

Re: [DNG] Systemd Shims

[Steve Litt]

On Sun, 16 Aug 2015 18:48:44 +0100
Edward Bartolo  wrote:

> I would like to humbly add my little contribution to this thread.
> 
> I am posting using Devuan 64 bit connected to a home WIFI without any
> network managers. I connect by using separate /etc/network/interfaces
> files. The one for my home wifi is in /etc/network/interfaces while
> the rest are saved under my home directory.
> 
> To connect, I use the command as root:
> ifup wlan0 -i an-interfaces-file

I, too, am a big fan of command based network connections rather than
data based. My only question is this: What is life like when you walk
from Macdonalds to Burger King and change hotspots?

I think for the travelling guy, there must be a quick facility to see
available hotspots with their strengths and security status, choose
one, input a password if that ESSID hasn't been encountered already,
and log in.

What was in your "an-interfaces-file"? (obviously change the
passwords). Did you use wpa-supplicant at all?


[snip]
 
> My point is, what I do manually, can be done through code resulting in
> a simple application. The advantage I see is, it would be standalone.

Pre-cisely!

> I am tempted to create this application to automate my connection, but
> most probably, as I am more prolific in Delphi Pascal, the language of
> choice  will be Lazarus Pascal. I can write C++ GUI applications but
> that requires more effort on my part. As long as logic programming in
> C/C++ that is on the same level if not easier.

Show me the way you do it manually, and I'll make something into which
you can plug in your Lazarus front end. Somebody else can plug in their
Dialog front end.

> 
> The hardest part seem to be allowing the ifup command to run with root
> privileges.

Well, if the user doesn't mind having sudo with a sudoers file, easiest
way to do that is to allow sudo nopassword. Is there a non-root group
that would allow ifup to do its thing?

What does your ifup command look like, and what does the
"an-interfaces-file" look like? Does one interfaces file contain lots
of ESSIDs, or one ESSID per interface file? What do you do about making
the password secure from prying, non-root eyes? As far as you know, do
you use wpa_supplicant in any way?

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Wireless configuration tools (was: Re: Systemd Shims)

[shraptor]

Long story short: it's limited, somewhat odd in interface, and nearly
undocumented.
But if you've configured wpa_supplicant to start, or need to write an
initial config file, it should be adequate if you can follow the UI.
I tried to make the UI as obvious as possible, but I'm the only user
I'm aware of, so no promises ;-).



What do you mean by limited? limited by scarce documentation?
limited in user-friendliness?

Well I am thinking of trying it.

It depends on udhcpcd and ifup/ifdown
Are these provided by busybox?


Are there other dependencies except wpa-supplicant, wpa-cli


Does it require something like OpenRC or would it work with
busybox init?


/Scooby



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

Re: [DNG] Systemd Shims

[Franco Lanza]

On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to clear 
> up something before moving on. I want you to understand why I came to the 
> Devuan list in the first place. I came here under the assumption that Devuan 
> was going to be a "better Debian" without the shove the Technical Committee 
> and the failure of the GR  gave to one single point of view.  

Well, we are here also to try to build up a "better debian" without
single point of view, yes, and to avoid "single point of view" for the
future, we are trying to move from "TC imposed view" to "VUA imposed
policy".

What's the difference? 

With a TC imposed view like in debian, you can't assume any decision
before the decision is made. With a "VUA imposed policy", when the
policy will be complete and public, it isn't yet, you can know how
anything will be managed in future.

Basically, more power to our constitution and less to "people in
charge", where "people in charge" will just act as constitution
custodes.


> As far as I can tell, Devuan is about the same, with one difference.  Devuan 
> is 
> willing to package systemd if it can be done cleanly - but nobody wants to.  
> Debian will support System 5, again until nobody wants to.  

No, it isn't like this.
It's this way:

Debian will support sysv, until nobody wants to.
Devuan will support anything that is feasible to do without ruining all
other options and impose one single way to do that, assuming someone
will accept to do the work.

The Devuan way is a policy, not something against a specific software.
Sadly systemd apply for this limitation as it can't be done without
hijacking whole system and imposing one way, so, it can't be an option
in my opinion. If anyone will get the work done and make it usable
without hijacking whole base system, well, Devuan will embrace it as an
option like anything else. Pratically, to me, this seems to be
impossible.

> Nexttime: "Devuan will not work to support systemd and will not work against 
> it. We will not do any effort to support it, if someone want to work to 
> package 
> it in a way where it works WITHOUT needs support for any other package 
> depending on it, we will consider to add it as an option, but we will NOT 
> accept it if it ask us to put it in dependency tree. "
> 
> That is all I EVER suggested, with one slight difference.  That if it is 
> somehow possible in the future to maintain two versions of the same package 
> that the default version would be without systemd, but the other would be 
> available at the users' option as a matter of choice.

This is of course feasible, yes. BUT how many packages will need two
versions? For systemd, too many, this is a way we can use for few
packages, but using it for 1 packages is probably a too huge effort,
at least for the moment. In future, who knows.

NOTE: my nickname is "nextime", with 1 single t. Is isn't derived from 
"next-time", 
  it comes from the software called "nextime" that was in some wat
  the grandfather of the now called "quicktime" when it was born on
  NextOS.

-- 

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---



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

Re: [DNG] Systemd Shims

[Edward Bartolo]

Alternatively, instead of running the ifup command with sudo, one can
start the application/daemon itself using sudo. This makes it possible
to use sudo while allowing only our application/daemon to run with
root privileges. I also think, this application can be made into a
daemon and started by a sysvinit script. However, let us not run,
first we learn to walk by providing a way to connect in a desktop or
window manager.

I think, there is no need of providing a graphical dialog for users as
a shell can be made to automatically open asking for the ESSID and
password interactively. I think, I can start working on this, as this
seems to be possible.


On 16/08/2015, Edward Bartolo  wrote:
> I think, there is no need of providing a graphical dialog for users as
> a shell can be made to automatically open asking for the ESSID and
> password interactively. I think, I can start working on this, as this
> seems to be possible.
>
> On 16/08/2015, Edward Bartolo  wrote:
>> Alternatively, instead of running the ifup command with sudo, one can
>> start the application/daemon itself using sudo. This makes it possible
>> to use sudo while allowing only our application/daemon to run with
>> root privileges. I also think, this application can be made into a
>> daemon and started by a sysvinit script. However, let us not run,
>> first we learn to walk by providing a way to connect in a desktop or
>> window manager.
>>
>> On 16/08/2015, Edward Bartolo  wrote:
>>> The ifup command is the one that comes ready with a default
>>> installation.
>>>
>>> The contents of an-interfaces-file is as follows. Be advised that eth0
>>> may not be needed in our case, but I included it to be on the safe
>>> side.
>>>
>>> -
>>> # The loopback network interface
>>> auto lo
>>> iface lo inet loopback
>>>
>>> # The primary network interface
>>> # allow-hotplug eth0
>>> iface eth0 inet dhcp
>>>
>>>
>>> # WIFI Configuration
>>> # auto wlan0
>>> iface wlan0 inet dhcp
>>> wpa-ssid  wifinamestring
>>> wpa-psk   "password"
>>> -
>>>
>>> I create one interfaces file per wifi point and keep them in a
>>> different location. Then, I use the command:
>>> ifup wlan0 -i specific-interface-file
>>>
>>> I have wpasupplicant installed and the wifi itself is configured only
>>> for encrypted connections.
>>>
>>> The variour interfaces files are made unreadable by non root users by
>>> changing ownership and permissions.
>>>
>>> In the past I used sudo to only allow a custom script be run by non
>>> root. To disallow non root from using ifup with its full flexibility I
>>> created a script which took no parameters to specifically run the ifup
>>> command complete with the parameter list I wanted. Other than ifup was
>>> not allowed to be run by non root.
>>>
>>>
>>> I think, the algorithm may work something on these lines:
>>>
>>> 1) query for a list of available ESSIDs
>>> 2) sort for the one with the strongest signal
>>> 3) check whether there is an interfaces file with that ESSID
>>> ... i) if found call ifup using the file, check return value
>>> from
>>> ifup
>>> a) if success exit and continue
>>> b) if failed try with the next signal strength
>>> ii) if an intefaces file does not exist present a dialog
>>> with the ESSID if available, ask for ESSID and
>>> password, goto i)
>>>
>>>
>>> The files I create are all like the one I quoted. To connect, I run
>>> ifup as root as follows:
>>> ifup -i interfaces-file-for-wifi-point wlan0
>>>
>>> That's all.
>>> Thanks
>>>
>>> On 16/08/2015, Steve Litt  wrote:
 On Sun, 16 Aug 2015 18:48:44 +0100
 Edward Bartolo  wrote:

> I would like to humbly add my little contribution to this thread.
>
> I am posting using Devuan 64 bit connected to a home WIFI without any
> network managers. I connect by using separate /etc/network/interfaces
> files. The one for my home wifi is in /etc/network/interfaces while
> the rest are saved under my home directory.
>
> To connect, I use the command as root:
> ifup wlan0 -i an-interfaces-file

 I, too, am a big fan of command based network connections rather than
 data based. My only question is this: What is life like when you walk
 from Macdonalds to Burger King and change hotspots?

 I think for the travelling guy, there must be a quick facility to see
 available hotspots with their strengths and security status, choose
 one, input a password if that ESSID hasn't been encountered already,
 and log in.

 What was in your "an-interfaces-file"? (obviously change the
 passwords). Did you use wpa-supplicant at all?


 [snip]

> My point is, what I do manually, can be done through code resulting in
> a simple application. The advantage I see is, it would be standalone.

Re: [DNG] Systemd Shims

[James Powell]

While there are packages that can be invisible and unintrusive into the system, 
there are some that cannot.

The problem is responsibility.

Who wants to remain responsible for boot scripts? Upstream or vendor?

Who wants responsibility for providing interoperability between projects? 
Upstream or downstream bazaar?

Who wants responsibility for the userland? Upstream or the downstream bazaar?

To me, this 'lack of' responsibility, and honestly this isn't just aimed at 
systemd, but as modern society as a whole, is the cause of this mess. This lack 
of personal and public responsibility has led to the rise of things like this, 
and it's high time we stand up and say either 'start being responsible' or 
'take responsibility' or else? Or else what? You'll find out when all the 
pushed off responsibility you didn't want comes crashing back down on you.

Didn't want to get political, philosophical, or religious, but sometimes enough 
is enough.

-Jim

From: Franco Lanza
Sent: ‎8/‎16/‎2015 1:46 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Systemd Shims

On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to clear
> up something before moving on. I want you to understand why I came to the
> Devuan list in the first place. I came here under the assumption that Devuan
> was going to be a "better Debian" without the shove the Technical Committee
> and the failure of the GR  gave to one single point of view.

Well, we are here also to try to build up a "better debian" without
single point of view, yes, and to avoid "single point of view" for the
future, we are trying to move from "TC imposed view" to "VUA imposed
policy".

What's the difference?

With a TC imposed view like in debian, you can't assume any decision
before the decision is made. With a "VUA imposed policy", when the
policy will be complete and public, it isn't yet, you can know how
anything will be managed in future.

Basically, more power to our constitution and less to "people in
charge", where "people in charge" will just act as constitution
custodes.


> As far as I can tell, Devuan is about the same, with one difference.  Devuan 
> is
> willing to package systemd if it can be done cleanly - but nobody wants to.
> Debian will support System 5, again until nobody wants to.

No, it isn't like this.
It's this way:

Debian will support sysv, until nobody wants to.
Devuan will support anything that is feasible to do without ruining all
other options and impose one single way to do that, assuming someone
will accept to do the work.

The Devuan way is a policy, not something against a specific software.
Sadly systemd apply for this limitation as it can't be done without
hijacking whole system and imposing one way, so, it can't be an option
in my opinion. If anyone will get the work done and make it usable
without hijacking whole base system, well, Devuan will embrace it as an
option like anything else. Pratically, to me, this seems to be
impossible.

> Nexttime: "Devuan will not work to support systemd and will not work against
> it. We will not do any effort to support it, if someone want to work to 
> package
> it in a way where it works WITHOUT needs support for any other package
> depending on it, we will consider to add it as an option, but we will NOT
> accept it if it ask us to put it in dependency tree. "
>
> That is all I EVER suggested, with one slight difference.  That if it is
> somehow possible in the future to maintain two versions of the same package
> that the default version would be without systemd, but the other would be
> available at the users' option as a matter of choice.

This is of course feasible, yes. BUT how many packages will need two
versions? For systemd, too many, this is a way we can use for few
packages, but using it for 1 packages is probably a too huge effort,
at least for the moment. In future, who knows.

NOTE: my nickname is "nextime", with 1 single t. Is isn't derived from 
"next-time",
  it comes from the software called "nextime" that was in some wat
  the grandfather of the now called "quicktime" when it was born on
  NextOS.

--

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---

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

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Isaac Dunham]

On Sun, Aug 16, 2015 at 12:07:45PM -0400, Haines Brown wrote:

> When I startx, I'm still in vesa (?) mode. The Xorg log file says it
> is using configuration directory /etc/X11/xorg.conf.d/ directory. The
> only error is: 
> 
> (EE) NOUVEAU(0): [COPY] failed to allocate class
> 
> don't know what this means, and the Xorg wiki site no help.
> 
> I did a # Xorg -configure to create a /root/xorg.conf.new. It has
> 
>   Section "Device"
> Identifier "Card(0)"
> Driver "nouveau"
>   EndSection
> 
> When I do # X -config /root/xconf.new, I'm taken to a blank screen and
> I'm hung there and so have to delete the xorg.conf.new file and do a hot
> reboot.


That "blank screen" is probably a sign of a successful X; try adding 
"-retro" to the options, and see if you see a root weave.

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

Re: [DNG] Systemd Shims

[tilt!]

Hello James,

On 08/17/2015 02:28 AM, James Powell wrote:

While there are packages that can be invisible and unintrusive

> into the  system, there are some that cannot.


The problem is responsibility.

Who wants to remain responsible for boot scripts? Upstream or vendor?


Who (developer, vendor, user) *could* remain responsible if no
distribution offered the possibility to run a service off a boot
script anymore, and all made systemd mandatory instead?

So, in order to provide freedom of choice to both developers and
users, the primary task is to provide environments were different
init systems are possible at all.

How to utilize a specific init system to support a specific
software providing a specific service is a specific task
(that not neccessarily involves boot scripts at all, I still
try to figure out what "service" actually means).

Kind regards,
T.

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

Re: [DNG] Wireless configuration tools (was: Re: Systemd Shims)

[Isaac Dunham]

On Sun, Aug 16, 2015 at 09:53:39PM +0200, shraptor wrote:
> 
> >Long story short: it's limited, somewhat odd in interface, and nearly
> >undocumented.
> >But if you've configured wpa_supplicant to start, or need to write an
> >initial config file, it should be adequate if you can follow the UI.
> >I tried to make the UI as obvious as possible, but I'm the only user
> >I'm aware of, so no promises ;-).
> 
> 
> What do you mean by limited? limited by scarce documentation?
> limited in user-friendliness?

Features (and user-friendliness, to a lesser degree).
It only supports adding open/WEP/WPA networks, viewing available 
networks ("4 scan" in the main menu), and disconnect/reassociate.
If you want to add and use a new network, you will need to manually
reassociate.
There is no way to configure how you get an IP address/how routing and
DNS is set up in wpa_config; wpa_dhcp provides these in theory, but
there are some major caveats (see my next comment).

> Well I am thinking of trying it.
> 
> It depends on udhcpc and ifup/ifdown
> Are these provided by busybox?

Yes.
Only wpa_dhcp requires these; on a Debian system, I'd suggest replacing
this script with wpa_action, since there's not any functional support for
different networks with different networking configs (you get either 
DHCP everywhere, or--if you configure it--the same static IP and routing
everywhere; I only use DHCP).
If you use wpa_action on a Busybox system, you'll need to port it
to use udhcpc.

> Are there other dependencies except wpa-supplicant, wpa-cli

For wpa_config, the part you're probably most interested in, you need
- a POSIX shell
- (POSIX) cat grep echo test true mktemp
- awk, for the scan feature (tested with busybox awk and mawk; gawk and
the "one true awk" should also work)
- wpa_supplicant and wpa_cli, of course
- dialog or an adequate clone (also tested with whiptail, xdialog may work).

On a minimal busybox system, you can build ncurses, dialog, and 
wpa_supplicant. Contrary to the whiptail documentation, it uses
significantly *more* disk space than dialog, unless you don't use 
ncurses at all and already use newt.

> Does it require something like OpenRC or would it work with
> busybox init?

OpenRC is a set of utilities and scripts that can be run atop sysvinit
or busybox init. I've only used it with Busybox init.

etc/init.d/wpanet requires OpenRC; however, there's a messier but
functionally roughly equivalent version in sbin/wpanet, autogenerated from
it by means of a partial OpenRC compatability library.
This version is lacking the LSB initscript headers, but should be usable
via the standard sysv-rc interface (/etc/init.d/wpanet start/stop/...).

For a "pocket Linux", I'd suggest ditching the init scripts and adding
the relevant stuff to your rc script.

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

Re: [DNG] Systemd Shims

[Edward Bartolo]

Forget about the CLI program or daemon. I can create a window with the
following features. Then, we can decide about the backends. We can
avoid having a full fledged sudo setup by ONLY allowing the few
backends to work with it. This should help securitywise.


Propose GUI:
Main window with:
a) listing the available wifi hotspots and the following buttons:
New, Delete and Edit
b) popup dialog asking for ESSID and password

What do you think? I am waiting your go ahaid. If you tell me to
begin, tomorrow it will be ready.

Waiting for your orders... :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Edward Bartolo]

The backends can be integrated into one single executable not to
clutter the sudoers file and to increase system efficiency.

I propose to place the other interface file in:
/etc/network/interfaces/wifi

I can start the implementation of the GUI (Lazarus Pascal) and the
backend (C++), but I need your opinion first.

Edward



On 17/08/2015, Edward Bartolo  wrote:
> Forget about the CLI program or daemon. I can create a window with the
> following features. Then, we can decide about the backends. We can
> avoid having a full fledged sudo setup by ONLY allowing the few
> backends to work with it. This should help securitywise.
>
>
> Propose GUI:
> Main window with:
> a) listing the available wifi hotspots and the following buttons:
> New, Delete and Edit
> b) popup dialog asking for ESSID and password
>
> What do you think? I am waiting your go ahaid. If you tell me to
> begin, tomorrow it will be ready.
>
> Waiting for your orders... :)
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng