Re: [DNG] OpenRC and Devuan
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
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
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
On Tue, May 03, 2016 at 03:24:47PM -1000, Joel Roth wrote: > Hendrik Boom wrote: > > There's a small number of directories that are supposed to be on the > > root filesystem, or otherwise available during boot. I believe /etc > > and /bin are two of these. > > > > /usr is not. I suspect /var isn't either. > > > > init is supposed to be able to read /etc/fstab to find the others. > > That's why /etc has to be on the root filesystem. > > > > So it is available for init-time configuration files. > > /etc is the right place for config files, and init scripts > have historically lived there. I hope we can agree on at > least this part! > I definitely agree on that, and I believe that having separate directories for separate sets of init scripts would be ideal. But they should definitely live in /etc. 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
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
Re: [DNG] OpenRC and Devuan
Am Tue, 03 May 2016 08:27:05 + schrieb dng-requ...@lists.dyne.org: > From: parazyd > To: Hendrik Boom > Cc: dng@lists.dyne.org > Subject: Re: [DNG] OpenRC and Devuan > Message-ID: <20160503071226.GA10101@hansolo> > Content-Type: text/plain; charset="utf-8" > > On Mon, 02 May 2016, Hendrik Boom wrote: > > > Is there a summary of some sort explaining the various init > > systems, how they're put together, how they work, and especially > > the salient points on which they differ? > > Perhaps this as a short intro: > https://wiki.gentoo.org/wiki/Comparison_of_init_systems http://www.troubleshooters.com/linux/init/manjaro_experiments.htm ___ 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)
It's a bit late, but in wicd you can use usb adapters (i did with a ralink based one) or share wifi via ethernet. It's tricky, yes, but with the use of scripts it can be done. At the time, i had a big help from someone in the (german) ubuntu user forums. Also: Ceni is an excellent ncurses based tool to administrate network connections (it's based on dhcpd and wpa_supplicant), more basic then networkmanager and wicd ((who both, it think, there are not just overlays but they use their own way to deal with the hardware; in fact iirc they are not compatible with wpa_supplicant running (??) ). At least, may be one should have a look at tinycore linux, how they deal with the network connections (i have it running on a small old netbook and it is really smart and easy, although it does not start automatically on boot the wifi connection). May be someone more expert knows. In any case, with some tweaking, it should be possible to offer good viable alternative to network-manager. Cheers! Am Mon, 02 May 2016 04:19:07 + schrieb dng-requ...@lists.dyne.org: > Message: 2 > Date: Mon, 2 May 2016 12:49:44 +1200 > From: Daniel Reurich > To: "dng@lists.dyne.org" > Subject: Re: [DNG] network-manager depends on libpam-systemd > Message-ID: <5726a428.50...@centurion.net.nz> > Content-Type: text/plain; charset="utf-8" > > On 02/05/16 12:01, Hendrik Boom wrote: > > On Sun, May 01, 2016 at 07:56:09PM -0400, Hendrik Boom wrote: > >> On Sun, May 01, 2016 at 12:40:34PM -0500, Nate Bargmann wrote: > >>> Hi All. > >>> > >>> I've completed the upgrade to Devuan Jessie Beta over Debian > >>> Jessie on both my laptop and desktop. Nice work! > >>> > >>> I use Network Manager on my laptop. It is configured for the > >>> networks I attach to most frequently and allows a seamless > >>> connection when tethering to my Android phone via USB. So shoot > >>> me! > >> > >> I use wicd instead of Network Manager, in devan jessie. I don't > >> know if it will talk to your phone over USB, but might it be worth > >> a try? > > > > As far as I know, all these network managers and the like are front > > ends to the same underlying low-level system components. You may > > find that they share the same connection data base. > > > wicd only deals specifically with the wifi/ethernet case. There is no > capability or plugins I've found for wicd to provide management for > vpn connectivity, bluetooth or usb-serial connectors. > > I could be wrong on that of course, but I didn't find a solution for > my vpn needs with wicd when I looked. > > Regards, > > Daniel ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
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 reason why we disdain systemd is because it's a mass of incomprehensible spaghetti code with dependencies up the ying-yang, and all that entails (ie a huge potential attack surface, dependency on Red Hat's "good will" for maintenance, etc). The main issue with switching from sysvinit to something else is just finding someone willing to do the work. I don't feel very qualified myself. I'm not sure if SteveL was volunteering or suggesting we organize something, but anyway, the idea of S6, Epoch, Runit or similar simple and comprehensible init systems appeals to me. cheers, Robert ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
> 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. Peter Olson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Steve Litt wrote: > Joel Roth wrote: > > > Hendrik Boom wrote: > > > There's a small number of directories that are supposed to be on > > > the root filesystem, or otherwise available during boot. I > > > believe /etc and /bin are two of these. > > > > > > /usr is not. I suspect /var isn't either. > > > > > > init is supposed to be able to read /etc/fstab to find the others. > > > That's why /etc has to be on the root filesystem. > > > > > > So it is available for init-time configuration files. > > > > /etc is the right place for config files, and init scripts > > have historically lived there. I hope we can agree on at > > least this part! > > No doubt about it. /etc is the tree where init scripts, run scripts, > EpochConfig files belong. > > I think the nonobvious thing comes from the daemontools-inspired inits, > which at a minimum have a /service directory somewhere that contains > symlinks to the actual service directories. No reason that can't be > somewhere under /etc. Daemontools, and maybe some other ones, also have > a /command directory, directly off the root, that houses executables > specific to themselves. It's possible this odd placement is to > guarantee they're available the minute the root partition is mounted. Interesting, I thought /sbin was historically for statically linked executables needed at boot time, or for system recovery. > Bizarrely, Runit on Void Linux has a directory at /run/runit that has > all sorts of oddball symlinks. I believe this is so, if /etc/ is > mounted read-only, parts of Runit that need to change file conttents > can still operate. I think this is usually placed at /var/run/runit, > but on Void it's just /run/runit. > > I did a little runit experimentation during my Manjaro Experiments, and > have found that Void's runit implementation is much more complex and > full of chained symlinks than was my Manjaro alt-initted runit. Well, all of these sources can be patched to suit the policies of Devuan, if it can be agreed what these policies are :-) > SteveT > > Steve Litt > April 2016 featured book: Rapid Learning for the 21st Century > http://www.troubleshooters.com/rl21 -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 3 May 2016 15:24:47 -1000 Joel Roth wrote: > Hendrik Boom wrote: > > There's a small number of directories that are supposed to be on > > the root filesystem, or otherwise available during boot. I > > believe /etc and /bin are two of these. > > > > /usr is not. I suspect /var isn't either. > > > > init is supposed to be able to read /etc/fstab to find the others. > > That's why /etc has to be on the root filesystem. > > > > So it is available for init-time configuration files. > > /etc is the right place for config files, and init scripts > have historically lived there. I hope we can agree on at > least this part! No doubt about it. /etc is the tree where init scripts, run scripts, EpochConfig files belong. I think the nonobvious thing comes from the daemontools-inspired inits, which at a minimum have a /service directory somewhere that contains symlinks to the actual service directories. No reason that can't be somewhere under /etc. Daemontools, and maybe some other ones, also have a /command directory, directly off the root, that houses executables specific to themselves. It's possible this odd placement is to guarantee they're available the minute the root partition is mounted. Bizarrely, Runit on Void Linux has a directory at /run/runit that has all sorts of oddball symlinks. I believe this is so, if /etc/ is mounted read-only, parts of Runit that need to change file conttents can still operate. I think this is usually placed at /var/run/runit, but on Void it's just /run/runit. I did a little runit experimentation during my Manjaro Experiments, and have found that Void's runit implementation is much more complex and full of chained symlinks than was my Manjaro alt-initted runit. 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 (and Windows)
* On 2016 03 May 16:38 -0500, Steve Litt wrote: > "Pen testing" My Aunt's Hat! I thought it was trying different Linux distributions from a USB pen. Shrug. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Duplicate sources.list entry
This usually happens to me when I install google-chrome-stable as I already have the repo entry in sources.list and the install creates a sub-folder, something like google-chrome.d, with another sources file. -- Forwarded message -- From: Go Linux Date: Wed, May 4, 2016 at 11:34 AM Subject: Re: [DNG] Duplicate sources.list entry To: dng On Tue, 5/3/16, Ozi Traveller wrote: Subject: Re: [DNG] Duplicate sources.list entry To: "Go Linux" , "dng" Date: Tuesday, May 3, 2016, 8:15 PM On Wed, May 4, 2016 at 10:28 AM, Go Linux wrote: >> I just upgraded some packages and got this error: >> >> W: Duplicate sources.list entry http://auto.mirror.devuan.org/merged/ jessie/main i386 Packages >>(/var/lib/apt/lists/auto.mirror.devuan.org_merged_dists_jessie_main_binary-i386_Packages) >> >> Hoping someone can translate. Don't know if it's something local or a duplication at the source. >> >> golinux > > > > There could be sources.list file in these folders that overlap. > /etc/apt > /etc/apt/sources.list.d > 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. golinux golinux ___ 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] Duplicate sources.list entry
On Tue, 5/3/16, Ozi Traveller wrote: Subject: Re: [DNG] Duplicate sources.list entry To: "Go Linux" , "dng" Date: Tuesday, May 3, 2016, 8:15 PM On Wed, May 4, 2016 at 10:28 AM, Go Linux wrote: >> I just upgraded some packages and got this error: >> >> W: Duplicate sources.list entry http://auto.mirror.devuan.org/merged/ >> jessie/main i386 Packages >> >>(/var/lib/apt/lists/auto.mirror.devuan.org_merged_dists_jessie_main_binary-i386_Packages) >> >> Hoping someone can translate. Don't know if it's something local or a >> duplication at the source. >> >> golinux > > > > There could be sources.list file in these folders that overlap. > /etc/apt > /etc/apt/sources.list.d > 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. golinux golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Hendrik Boom wrote: > There's a small number of directories that are supposed to be on the > root filesystem, or otherwise available during boot. I believe /etc > and /bin are two of these. > > /usr is not. I suspect /var isn't either. > > init is supposed to be able to read /etc/fstab to find the others. > That's why /etc has to be on the root filesystem. > > So it is available for init-time configuration files. /etc is the right place for config files, and init scripts have historically lived there. I hope we can agree on at least this part! > -- hendrik > > > > > Perhaps LSB should add a directory called /mustnotbemountpoint directly > > off the root, for stuff that must be available immediately upon > > mounting the root partition for the first time. > > There are already several suuch directories. > > -- hendrik > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Duplicate sources.list entry
There could be sources.list file in these folders that overlap. /etc/apt /etc/apt/sources.list.d On Wed, May 4, 2016 at 10:28 AM, Go Linux wrote: > I just upgraded some packages and got this error: > > W: Duplicate sources.list entry http://auto.mirror.devuan.org/merged/ > jessie/main i386 Packages > (/var/lib/apt/lists/auto.mirror.devuan.org_merged_dists_jessie_main_binary-i386_Packages) > > Hoping someone can translate. Don't know if it's something local or a > duplication at the source. > > golinux > ___ > 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
[DNG] Duplicate sources.list entry
I just upgraded some packages and got this error: W: Duplicate sources.list entry http://auto.mirror.devuan.org/merged/ jessie/main i386 Packages (/var/lib/apt/lists/auto.mirror.devuan.org_merged_dists_jessie_main_binary-i386_Packages) Hoping someone can translate. Don't know if it's something local or a duplication at the source. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] another instance of packages.devuan
On Tue, May 03, 2016 at 10:52:01PM +, Go Linux wrote: > On Tue, 5/3/16, Hendrik Boom wrote: > > Subject: [DNG] another instance of packages.devuan > To: dng@lists.dyne.org > Date: Tuesday, May 3, 2016, 3:36 PM > > > > I noticed in > > > > https://talk.devuan.org/t/migrating-from-debian-to-a-minimalist-devuan/181 > > > > that it recommends deb lines like > > > > deb http://packages.devuan.org/merged jessie main > > > > and > > > > deb http://packages.devuan.org/merged jessie-updates main > > > > Shall I change them to auto.mirror.devuan.org? > > > > Or does that require special privileges? I've only just signed on > > there and I'm rated a rank newbie. > > > > -- hendrik > > > > I just made the changes. Please double check that there are no errors. > > golinux Look better now. All the problems I saw have been fixed. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] another instance of packages.devuan
On Tue, 5/3/16, Hendrik Boom wrote: Subject: [DNG] another instance of packages.devuan To: dng@lists.dyne.org Date: Tuesday, May 3, 2016, 3:36 PM > > I noticed in > > https://talk.devuan.org/t/migrating-from-debian-to-a-minimalist-devuan/181 > > that it recommends deb lines like > > deb http://packages.devuan.org/merged jessie main > > and > > deb http://packages.devuan.org/merged jessie-updates main > > Shall I change them to auto.mirror.devuan.org? > > Or does that require special privileges? I've only just signed on > there and I'm rated a rank newbie. > > -- hendrik I just made the changes. Please double check that there are no errors. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016 23:07:05 +0200 Svante Signell wrote: > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > 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. > > > > Hi Steve, > > We had a patch where openrc in debian was openrc.postrm and > openrc.preinst was used to to divert update-rc.d + invoke-rc.d files > to not conflict with the init- system-helpers scripts: update-rc.d > and invoke-rc.d, see dpkg-divert. That is the solution used > by file-rc. Currently systemd, sysvinit-core and openrc use the > method of cooperating with the scripts update-rc.d and invoke-rc.d in > the init-system-helpers package. Which is your preferred solution, we > can go either way. :-) Hi Svante, I don't understand a single word of your preceding paragraph, which isn't surprising given my lack of knowledge of packaging systems. I also know very little about OpenRC. So I have no opinion on the choice you give in the preceding paragraph. An opinion I *do* have is that for s6, runit and Epoch, the Devuan package as much as possible mimic the idiomatic way that the program's developer says to install it. I don't think that will be particularly hard to do, and in another post I outlined how sysvinit, s6, runit and Epoch can coexist simply by naming their PID1's sysvinit.pid1, s6.pid1, runit.pid1 and epoch.pid1, and then switching inits is as simple as copying one of those .pid1 files to /sbin/init. 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] another instance of packages.devuan
On Tue, 5/3/16, Hendrik Boom wrote: Subject: [DNG] another instance of packages.devuan To: dng@lists.dyne.org Date: Tuesday, May 3, 2016, 3:36 PM > > I noticed in > > https://talk.devuan.org/t/migrating-from-debian-to-a-minimalist-devuan/181 > > that it recommends deb lines like > > deb http://packages.devuan.org/merged jessie main > > and > > deb http://packages.devuan.org/merged jessie-updates main > > Shall I change them to auto.mirror.devuan.org? > > Or does that require special privileges? I've only just signed on > there and I'm rated a rank newbie. > > -- hendrik I have admin privs on discourse and found a way to edit other people's posts. Can't do it atm but will later if no one else gets to it before me. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 2016-05-03 at 23:24 +0200, parazyd wrote: > On Tue, 03 May 2016, Svante Signell wrote: > > As I've stated at the beginning of this whole thread, debian-openrc is > irrelevant and a bad way to solve the whole issue of using OpenRC > properly, becase they keep using LSB initscripts... What about replacing the LSB initscripts, one by one in a suitable pace, starting from the current state (they can be mixed, right?) And of course we should replace the init-system-helpers package with a init-freedom package, as pointed out before ;-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan (and Windows)
Thanks Stephanie! There's a special place in hell for people using ambiguous abbreviations, acronyms, and nicknames. I mean really, do they think this makes them sound more "in the know?" That author is a WAD. Now I get to feel superior as the word WAD rolls glibly and effortlessly off my tongue. "Pen testing" My Aunt's Hat! Thanks Stephanie, SteveT On Tue, 03 May 2016 18:05:41 + Stephanie Daugherty wrote: > I assume "penetration testing", and seems like a shortsighted view. > > On Tue, May 3, 2016 at 1:57 PM Steve Litt > wrote: > > > On Tue, 3 May 2016 09:05:03 + (UTC) > > Go Linux wrote: > > > > > > > > > > > > > Linux = Pen testing > > > Windows = everything else > > > > What is pen testing? Am I out of touch, or is this guy making up > > words? > > > > 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] Files .udeb
On 05/03/2016 07:52 PM, Adam Borowski wrote: Contrary to its name, netinst is enough to install a standalone system That's true :) Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Svante Signell wrote: > On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote: > > On Tue, 03 May 2016, Svante Signell wrote: > > > > > > > > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > > > > > > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > > > > > 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. > > > > > > > Hi Steve, > > > > > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst > > > was > > > used to to divert update-rc.d + invoke-rc.d files to not conflict with the > > > init- > > > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That > > > is > > > the solution used by file-rc. Currently systemd, sysvinit-core and openrc > > > use > > > the method of cooperating with the scripts update-rc.d and invoke-rc.d in > > > the > > > init-system-helpers package. Which is your preferred solution, we can go > > > either > > > way. > > invoke-rc.d and update-rc.d will NOT be used with OpenRc. > > In Debian openrc they are. > As I've stated at the beginning of this whole thread, debian-openrc is irrelevant and a bad way to solve the whole issue of using OpenRC properly, becase they keep using LSB initscripts... -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpb3NgSXd0KV.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote: > On Tue, 03 May 2016, Svante Signell wrote: > > > > > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > > > > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > > > 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. > > > > > Hi Steve, > > > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst > > was > > used to to divert update-rc.d + invoke-rc.d files to not conflict with the > > init- > > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That > > is > > the solution used by file-rc. Currently systemd, sysvinit-core and openrc > > use > > the method of cooperating with the scripts update-rc.d and invoke-rc.d in > > the > > init-system-helpers package. Which is your preferred solution, we can go > > either > > way. > invoke-rc.d and update-rc.d will NOT be used with OpenRc. In Debian openrc they are. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Svante Signell wrote: > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > 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. > > > > Hi Steve, > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst was > used to to divert update-rc.d + invoke-rc.d files to not conflict with the > init- > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is > the solution used by file-rc. Currently systemd, sysvinit-core and openrc use > the method of cooperating with the scripts update-rc.d and invoke-rc.d in the > init-system-helpers package. Which is your preferred solution, we can go > either > way. invoke-rc.d and update-rc.d will NOT be used with OpenRc. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgppiqAXuDHjn.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > 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. > Hi Steve, We had a patch where openrc in debian was openrc.postrm and openrc.preinst was used to to divert update-rc.d + invoke-rc.d files to not conflict with the init- system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is the solution used by file-rc. Currently systemd, sysvinit-core and openrc use the method of cooperating with the scripts update-rc.d and invoke-rc.d in the init-system-helpers package. Which is your preferred solution, we can go either way. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Steve Litt wrote: > 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? > > > > > 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. > > 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. The problem with this is Debian itself. They insist on using LSB init scripts and in my opinion that they are somewhat different than what OpenRC wants. (For me at least) openrc initscripts are simpler, and also for respecting the openrc way(?) I wish to keep it in /etc/openrc. This way, with or without debhelper scripting OpenRC should work much more easily. The only thing then is that the package maintainers would have to include new initscripts in their packages, which might or might not be cumbersome for them. sysvinit should and will just stay where it already is. There is really no point in changing it's current configuration when other alternatives offer very easy ways to work around it. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpbfnv5FOub3.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] another instance of packages.devuan
I noticed in https://talk.devuan.org/t/migrating-from-debian-to-a-minimalist-devuan/181 that it recommends deb lines like deb http://packages.devuan.org/merged jessie main and deb http://packages.devuan.org/merged jessie-updates main Shall I change them to auto.mirror.devuan.org? Or does that require special privileges? I've only just signed on there and I'm rated a rank newbie. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
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? > > 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. 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. 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 (and Windows)
Steven W. Scott wrote: > Wow. Funny that, my view is: > Windows: Gaming > Linux: everything else I am kind of a "hardcore" gamer, nowadays especially in Sauerbraten and Urban Terror, back then in RedEclipse, I actually think that the situation with games is good. Count here 0 A.D., Battle for Wesnoth, Quake(s), OpenArena, AssaultCube, Speed Dreams and its parent, TORCS. On Steam Dota 2 and CS 1.6, CS:GO are available. Probably some other very popular games too. Some claim that performance in Linux is better due to the quality of the drivers. So, in my opinion: Windows - I couldn't find FreeDOS/Linux pre-installed; Linux - everything; OS X - I am gay. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Odp: Re: OpenRC and Devuan
+1 Dnia Wtorek, 3 Maja 2016 10:35 Jaromil napisał(a) this is what is going to happen and $years is a variable between releases. Our release cycle is clear: packages get in unstable (Ceres), then in testing (Ascii) which will have them in once released. The openrc package proposed is not taking any shortcut. So people willing to help maintaining it should run Ceres. People willing to use it as soon as its ready: Ascii. We have no interest in changing the default sysvinit, but we have interest in having other init options working, .. . Therefore we can expect Ascii to have more options ready for use and possibly not even overlapping between one and another. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 03, 2016 at 02:16:55PM -0400, Steve Litt wrote: > On Tue, 3 May 2016 13:00:39 +0100 > KatolaZ wrote: > > > On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote: > > > > [cut] > > > > > > > > I know this is in the very early stages and where things go is > > > still open to discussion, but consider this. > > > > > > 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. > > > > > > Something to consider and discuss, I hope. > > > > > > > I definitely agree with you Jim, and this is certainly one aspect to > > be taken into account seriously. We should strive to allow the maximum > > flexibility in choosing an init system, ensuring that the set of > > constraints remains as small as possible. > > Interesting point. Perhaps that's why Daniel J Bernstein (djb) put > the /service directory directly off the root. He also put his > executables in, IIRC, /command directly off the root. I always thought > he was crazy, but Jim's point brings some sense to what djb did. > > One distro I saw (perhaps Debian) put the /service directory > under /etc. At the time I thought the packager was psychotic, but Jim's > point makes me wonder if the real truth is I was a little shortsighted. There's a small number of directories that are supposed to be on the root filesystem, or otherwise available during boot. I believe /etc and /bin are two of these. /usr is not. I suspect /var isn't either. init is supposed to be able to read /etc/fstab to find the others. That's why /etc has to be on the root filesystem. So it is available for init-time configuration files. -- hendrik > > Perhaps LSB should add a directory called /mustnotbemountpoint directly > off the root, for stuff that must be available immediately upon > mounting the root partition for the first time. There are already several suuch directories. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan (and Windows)
Actually, since Valve released a native Steam client for Linux, I've even abandoned Windows for gaming. Yes, I'm quite limited to what I can play, but it has enough titles to keep me busy. Linux O'Beardly @LinuxOBeardly http://o.beard.ly linux.obear...@gmail.com On Tue, May 3, 2016 at 3:00 PM, Steven W. Scott wrote: > Wow. Funny that, my view is: > > Windows: Gaming > Linux: everything else > > Linux for pentest, hell yes, mostly because it lends itself extremely well > to quickly implementing a prototype and automating it in a reliable manner. > Windows scheduler is a joke, Windows development is a masochist's dream. > Poweshell is an indicator that MS has only recently come to the > understanding that automation is more than just a room full of low-skilled > operators reacting to pop-up dialogs. Where does the cloud live, on > Windows? Lol! > > SWS > On May 3, 2016 5:05 AM, "Go Linux" wrote: > >> On Tue, 5/3/16, Mitt Green wrote: >> >> Subject: Re: [DNG] OpenRC and Devuan >> To: dng@lists.dyne.org >> Date: Tuesday, May 3, 2016, 1:51 AM >> >> >> The current init system is old. Ancient. >> >> We should all agree on it. Devuan is looking >> >> for a new init system that is not systemd and my >> >> personal choice for this task from now on is >> >> Gentoo's OpenRC. >> > >> > Unix is old. Ancient. We should all agree on it. >> > Devuan is looking for a new base system that >> > is not Unix and my personal choice for this >> > task from now is Microsoft's Windows. >> > >> >> >> >> Mitt's response reminded me of a post that was made to the forum earlier >> today in the topic "Windows explained to Devuan supporters" at >> https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 : >> >> >> >> Linux = Pen testing >> Windows = everything else >> >> There are no advantages in using any linux distros other than pen testing >> and that it can be installed on a USB key(and I think that's very cool). >> Even Software Defined Radio (SDR) with maybe the exception of GMS >> intercepting and decoding, has more development under Windows. Night and >> day. One works extremely well on all PCs and permits the User to actually >> be productive and do things. The other one is a clunky Windows wannabe with >> a couple of specialized advantages that most don't care about. So.. >> >> YES >> I like its functionality, its popularity(more software dev and hardware >> support), its clarity and ease of use. >> The only thing wrong with my Windows is its lack of pen testing >> capability, and that is why I'm here (KL2 using Debian8 and now looking for >> an alternative with Dev-one as a base), otherwise I would >> n e v e r << >> bother with anything linux, life is too short >> >> >> >> I'll spare you my personal thoughts on this evaluation of Linux but >> looking forward to all of yours. :) >> >> golinux >> >> >> >> >> ___ >> 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 > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan (and Windows)
Wow. Funny that, my view is: Windows: Gaming Linux: everything else Linux for pentest, hell yes, mostly because it lends itself extremely well to quickly implementing a prototype and automating it in a reliable manner. Windows scheduler is a joke, Windows development is a masochist's dream. Poweshell is an indicator that MS has only recently come to the understanding that automation is more than just a room full of low-skilled operators reacting to pop-up dialogs. Where does the cloud live, on Windows? Lol! SWS On May 3, 2016 5:05 AM, "Go Linux" wrote: > On Tue, 5/3/16, Mitt Green wrote: > > Subject: Re: [DNG] OpenRC and Devuan > To: dng@lists.dyne.org > Date: Tuesday, May 3, 2016, 1:51 AM > > >> The current init system is old. Ancient. > >> We should all agree on it. Devuan is looking > >> for a new init system that is not systemd and my > >> personal choice for this task from now on is > >> Gentoo's OpenRC. > > > > Unix is old. Ancient. We should all agree on it. > > Devuan is looking for a new base system that > > is not Unix and my personal choice for this > > task from now is Microsoft's Windows. > > > > > > Mitt's response reminded me of a post that was made to the forum earlier > today in the topic "Windows explained to Devuan supporters" at > https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 : > > > > Linux = Pen testing > Windows = everything else > > There are no advantages in using any linux distros other than pen testing > and that it can be installed on a USB key(and I think that's very cool). > Even Software Defined Radio (SDR) with maybe the exception of GMS > intercepting and decoding, has more development under Windows. Night and > day. One works extremely well on all PCs and permits the User to actually > be productive and do things. The other one is a clunky Windows wannabe with > a couple of specialized advantages that most don't care about. So.. > > YES > I like its functionality, its popularity(more software dev and hardware > support), its clarity and ease of use. > The only thing wrong with my Windows is its lack of pen testing > capability, and that is why I'm here (KL2 using Debian8 and now looking for > an alternative with Dev-one as a base), otherwise I would >> n e v e r << > bother with anything linux, life is too short > > > > I'll spare you my personal thoughts on this evaluation of Linux but > looking forward to all of yours. :) > > golinux > > > > > ___ > 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
On Tue, 3 May 2016 13:00:39 +0100 KatolaZ wrote: > On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote: > > [cut] > > > > > I know this is in the very early stages and where things go is > > still open to discussion, but consider this. > > > > 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. > > > > Something to consider and discuss, I hope. > > > > I definitely agree with you Jim, and this is certainly one aspect to > be taken into account seriously. We should strive to allow the maximum > flexibility in choosing an init system, ensuring that the set of > constraints remains as small as possible. Interesting point. Perhaps that's why Daniel J Bernstein (djb) put the /service directory directly off the root. He also put his executables in, IIRC, /command directly off the root. I always thought he was crazy, but Jim's point brings some sense to what djb did. One distro I saw (perhaps Debian) put the /service directory under /etc. At the time I thought the packager was psychotic, but Jim's point makes me wonder if the real truth is I was a little shortsighted. Perhaps LSB should add a directory called /mustnotbemountpoint directly off the root, for stuff that must be available immediately upon mounting the root partition for the first time. Steve 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
On Tue, 3 May 2016 12:18:13 +0100 KatolaZ wrote: > Ideally, switching between init systems (e.g., reverting back to an > init system which is known to work) should be achievable from a > single-user root shell spawned as an emergency "init", using only a > few executables in /bin and /sbin. Anything more complicated than that > risks to become not that useful or even harmful in the long run, IMHO. I was going to mention that. My understanding is that in Debian if you install one init it removes the others. I like having multiple inits for much the same reason many people have multiple kernels: You might need to switch, you might need to A/B test, etc. IMHO the package should install everything, and from what I understand each init has completely different files than the others, and then compile the pid1 to be runit.pid1 or s6.pid1 or epoch.pid1. If so, then switching to, let's say, epoch, would be as simple as this: cp -p /sbin/epoch.pid1 /sbin/init 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 (and Windows)
I assume "penetration testing", and seems like a shortsighted view. On Tue, May 3, 2016 at 1:57 PM Steve Litt wrote: > On Tue, 3 May 2016 09:05:03 + (UTC) > Go Linux wrote: > > > > > > > > Linux = Pen testing > > Windows = everything else > > What is pen testing? Am I out of touch, or is this guy making up words? > > 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] cloud
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. 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] network-manager depends on libpam-systemd
On Tue, 3 May 2016 11:53:33 +0200 Didier Kryn wrote: > Yes, I know. All these front-ends use wpa_supplicant in their > kitchen. I just wonder why they find it more clever to re-do on their > own what wpa_supplicant can do alone. I think I can answer that. Wpa_supplicant has three front ends that I know of: wpa_cli, wpa_gui, and wpa_passphrase. Wpa_passphrase' capability is limited to taking an SSID and password and making something that can be appended to /etc/wpa_supplicant/wpa_supplicant.conf in order to interact with that SSID. Wpa_gui, and *especially* wpa_cli, are structured so the human must give information in wpa_supplicant API terms, rather than in human terms. Wpa_gui does one of the worst jobs of human engineering of any software I've seen. The ideal interface would be an nCurses thing that is structured pretty much like Network Manager. Network Manager got the human engineering almost completely right. Too bad about all the dbus and X requirements. 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 (and Windows)
On Tue, 3 May 2016 09:05:03 + (UTC) Go Linux wrote: > > > Linux = Pen testing > Windows = everything else What is pen testing? Am I out of touch, or is this guy making up words? 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
On Tue, 3 May 2016 11:24:01 +0200 Didier Kryn wrote: > Le 03/05/2016 08:51, Mitt Green a écrit : > >> The current init system is old. Ancient. > >> We should all agree on it. Devuan is looking > >> for a new init system that is not systemd and my > >> personal choice for this task from now on is > >> Gentoo's OpenRC. > > > > Unix is old. Ancient. We should all agree on it. > > Devuan is looking for a new base system that > > is not Unix and my personal choice for this > > task from now is Microsoft's Windows. > > > > Debian-potato was systemd-free. OK it's old now, but still less > than Unix. Why not still use it? No need for Devuan. > > Didier I'm so tired of all of this complexification that I'm pulling my Kaypro 2x out of the closet and going back to CPM. 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
On Tue, May 03, 2016 at 07:31:35PM +0200, parazyd wrote: > On Tue, 03 May 2016, Rob Owens wrote: > > > - Original Message - > > > From: "parazyd" > > > > > On Tue, 03 May 2016, Rob Owens wrote: > > > > > >> - Original Message - > > >> > From: "KatolaZ" > > >> > > >> > But do we really need all that complication? Couldn't we just leave > > >> > the initscript of each init system in a different directory and *tell > > >> > the init system* where they are to be found? This will allow a much > > >> > easier coexistence of different confs. > > >> > > > >> > Basically, everything related to sysvinit, stays in /etc/init.d, and > > >> > sysvinit knows it has to look there. OpenRC stuff stays in > > >> > /etc/openrc, and openrc knows it has to look there for its scripts. > > >> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > > >> > there for its stuff. We add the next-init-system, it will have its > > >> > scripts in /etc/. > > >> > > >> 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). > > >> > > >> 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. > > >> > > > > > > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and > > > set it to /etc/openrc. Then all will be found inside, and the system > > > will already know what to do, without symlinking. > > > > 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). > > With OpenRC one actually has to do: `rc-service foo start` So what we probably want is a 'service' command that checks what init was running as process 1 and issues the proper command for that init. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 3 May 2016 09:59:40 +0100 KatolaZ wrote: > On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote: > > [cut] > > > > > This can all be handled in each package with the package triggers > > enabled easily with a debhelper script similar to dh-systemd which > > makes it easy to deploy init scripts/unit files/runscripts etc in > > their own namespace and /etc/ and only deploy them > > when the init system is installed and removes them when it is > > removed. This shifts the burden to package maintainers, but that > > is the right place for them and we can make it easy to add > > additional init-scripts by filing bugs with patches. > > But do we really need all that complication? Couldn't we just leave > the initscript of each init system in a different directory and *tell > the init system* where they are to be found? This will allow a much > easier coexistence of different confs. As you read my response, please keep in mind my biases. I tend to break away from the package manager at the first hint of trouble... If katolaz was saying "hey, it doesn't have to be that difficult", then I agree with him. Having installed Runit, s6, and Epoch direct from upstream developer source code, I find that the upstream developers had the best ideas about where to put which kinds of files. To the extent that the Devuan package conforms to what the init's developer used, you KNOW where its files go. I see one instance in which Devuan should depart from upstream ideas, and that's in situations where the init's developer saw fit to create a new directory off of the root, such as /service in daemontools. Changing that to /var/service isn't difficult at all. Anyway, including extra inits needn't be a big effort (except for creating runscripts/EpochConfigs: the original developers pretty much got everything right. 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
On Tue, 03 May 2016, Rob Owens wrote: > - Original Message - > > From: "parazyd" > > > On Tue, 03 May 2016, Rob Owens wrote: > > > >> - Original Message - > >> > From: "KatolaZ" > >> > >> > But do we really need all that complication? Couldn't we just leave > >> > the initscript of each init system in a different directory and *tell > >> > the init system* where they are to be found? This will allow a much > >> > easier coexistence of different confs. > >> > > >> > Basically, everything related to sysvinit, stays in /etc/init.d, and > >> > sysvinit knows it has to look there. OpenRC stuff stays in > >> > /etc/openrc, and openrc knows it has to look there for its scripts. > >> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > >> > there for its stuff. We add the next-init-system, it will have its > >> > scripts in /etc/. > >> > >> 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). > >> > >> 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. > >> > > > > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and > > set it to /etc/openrc. Then all will be found inside, and the system > > will already know what to do, without symlinking. > > 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). With OpenRC one actually has to do: `rc-service foo start` -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpf9DfiXw62r.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Files .udeb
On Tue, May 03, 2016 at 04:43:11PM +0200, aitor_czr wrote: > On 05/03/2016 02:00 PM, "Stephanie Daugherty" wrote: > >udeb files (aka micro-deb) are stripped down packages only used in building > >the installer and loading installer components into memory via a network > >connection > > Some of them do it via network connection, but not all of them... Thanks to > this fact, there are a lot of distributions wich don't need any network > connection during the installation. It all depends on how fat an image you build. It can be "mini.iso" which has everything you need to start the installer and get the network running, netinst which carries all the udebs and some debs for a small system (at a glance it looks like priority:standard and up), or a CD/DVD with a buttload of assorted crap. Contrary to its name, netinst is enough to install a standalone system that can boot on itself then install more, only mini absolutely requires network. I've attached the list of udebs on jessie-x32 mini.iso. -- A tit a day keeps the vet away. nano-udeb serial-modules-3.16.0-4-amd64-di udev-udeb mountmedia ethdetect libuuid1-udeb scsi-core-modules-3.16.0-4-amd64-di libnl-3-200-udeb usb-modules-3.16.0-4-amd64-di libfribidi0-udeb network-preseed lowmemcheck netcfg wide-dhcpv6-client-udeb di-utils-reboot nic-pcmcia-modules-3.16.0-4-amd64-di nic-modules-3.16.0-4-amd64-di media-retriever usb-storage-modules-3.16.0-4-amd64-di hw-detect busybox-udeb mmc-modules-3.16.0-4-amd64-di nic-usb-modules-3.16.0-4-amd64-di rescue-check usb-serial-modules-3.16.0-4-amd64-di debian-archive-keyring-udeb crypto-modules-3.16.0-4-amd64-di download-installer nic-shared-modules-3.16.0-4-amd64-di pciutils-udeb crc-modules-3.16.0-4-amd64-di archdetect libblkid1-udeb wpasupplicant-udeb rootskel udpkg libasound2-udeb nic-wireless-modules-3.16.0-4-amd64-di main-menu mmc-core-modules-3.16.0-4-amd64-di choose-mirror choose-mirror-bin i2c-modules-3.16.0-4-amd64-di installation-locale preseed-common bogl-bterm-udeb cdebconf-text-udeb pcmciautils-udeb console-setup-udeb anna cdebconf-udeb env-preseed libkmod2-udeb save-logs kbd-udeb pcmcia-modules-3.16.0-4-amd64-di libtextwrap1-udeb cdebconf-priority input-modules-3.16.0-4-amd64-di virtio-modules-3.16.0-4-amd64-di acpi-modules-3.16.0-4-amd64-di libiw30-udeb libcrypto1.0.0-udeb libnss-files-udeb net-retriever console-setup-pc-ekmap cdebconf-newt-terminal cdebconf-newt-udeb gpgv-udeb util-linux-udeb fat-modules-3.16.0-4-amd64-di di-utils-terminfo initrd-preseed zlib1g-udeb rdnssd-udeb di-utils-shell libnl-genl-3-200-udeb libdebian-installer4-udeb di-utils localechooser hyperv-modules-3.16.0-4-amd64-di libdebconfclient0-udeb fb-modules-3.16.0-4-amd64-di brltty-udeb kernel-image-3.16.0-4-amd64-di libnss-dns-udeb ndisc6-udeb file-preseed core-modules-3.16.0-4-amd64-di uinput-modules-3.16.0-4-amd64-di debian-installer ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
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. > > Launching Devuan while maintaining the sysvinit status quo > has already stressed the pool of volunteer manpower to the > limit. > > So the practical way forward is to leave the task of > developing init scripts for the alternative init systems > to the users of those systems. Yes yes yes yes YES!!! 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. > > If someone would volunteer to coordinate the infrastructure > needed to collect, systematize, debug and distribute the the > tens or hundreds of scripts involved (one for each service), > multiplied by the number of init systems to be supported, I think the preceding can be accomplished by a wiki. The user clicks on the desired init, then on the desired (for want of a better word) daemon, and sees the proper init script/run script/EpochConfig. There would be a place to edit a given init/daemon combination. This wiki should be passworded so neither systemd fanatics nor whacko out of control anti-systemd crazies can sabotage it. Perhaps give edit rights by init system. For instance, you'd want me to have edit rights for Runit, s6 and Epoch, but not for OpenRC, perp or nosh. > I'm sure the Devuan project leads could consider in future > ways to bring them into the Devuan package ecosystem. Yes, and it could be done slowly, with no pressure. > > For those with time to invest, I would suggest the > following: > > * determine a subset, those esssential services that, if supported, > would allow a user to get a usable base system: > > * choose one or two best-of-breed init systems to work on, > and provide infrastructure for collecting contributions > for *all* init systems, even less popular ones. > > With cheers for the volunteers, I might volunteer for Runit. 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
On Tue, 3 May 2016 09:12:26 +0200 parazyd wrote: > On Mon, 02 May 2016, Hendrik Boom wrote: > > > Is there a summary of some sort explaining the various init > > systems, how they're put together, how they work, and especially > > the salient points on which they differ? > > Perhaps this as a short intro: > https://wiki.gentoo.org/wiki/Comparison_of_init_systems For some reason I can't begin to fathom, the preceding link ignores the existence of all the daemontools-inspired inits: * Runit * S6, s6-rc * nosh * perp * Suckless init + daemontools-encore I can't help this reminding me of Lennart Poettering's statement that systemd is better than Upstart and sysvinit, as if no other alternatives existed. 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] For all you automounter programmers
On 05/03/2016 08:46 AM, Jim Murphy wrote: > On Tue, May 3, 2016 at 7:28 AM, Didier Kryn wrote: >> Le 03/05/2016 14:06, Jim Murphy a écrit : >>> >>> On Tue, May 3, 2016 at 4:04 AM, Didier Kryn wrote: Le 02/05/2016 14:12, fsmithred a écrit : > > 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. > > -fsr > > > On 04/28/2016 01:52 PM, fsmithred wrote: >> >> On 04/27/2016 08:28 PM, fsmithred wrote: >>> >>> You could get the label from lsblk, do 'pmount label' and it will be >>> mounted at /media/label. Every time you plug in a thumb drive labeled >>> backup, it'll go to the same place. If you unmount the drive, >>> /media/label >>> will no longer exist, so you could even have the backup script check >>> to >>> make sure it's there. >>> >>> -fsr >>> >> Correction - Only root can get the label from lsblk. User can get the >> label from '/sbin/blkid -s LABEL', but only after root has run blkid at >> least once. Other than that, I've now got a script that will handle the >> labels... sometimes. >> >> -fsr >> >> kryn@apcnb98:~$ /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/" UUID="d91acaa3-5fdc-49e9-9f2b-ba7f3efb33f9" UUID_SUB="6a0c80cd-5dc6-4135-8018-575686e7e11e" TYPE="btrfs" kryn@apcnb98:~$ /sbin/blkid /dev/sda6 /dev/sda6: LABEL="/usr" UUID="05f9f811-b8b1-445f-ac8c-9537a202a9f9" UUID_SUB="52b8e1b8-7080-4696-94e1-8f7580005871" TYPE="btrfs" Didier >>> >>> 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. >>> >>> Jim >> >> >> I cannot reproduce what you describe. I just tried it with a usb stick: >> kryn@apcnb98:~$ /sbin/blkid /dev/sdb2 >> /dev/sdb2: LABEL="Didier-Kryn-2" UUID="64f73abe-34b9-4d4c-bac7-6dd85f0e4696" >> TYPE="reiserfs" >> >> This was done on debian-wheezy, from the console, without any DE >> running, and even display manager stopped, and after a fresh reboot. If >> blkid, invoked by normal user, runs from cache, then it means it has been >> invoked by root after insertion - I suspect udev and consider it a good >> thing, and I can tell you that vdev does systematically invoke blkid for >> every block device. >> >> Didier >> > > Not sure where the change took place, wheezy is 2.20, I'm look at 2.25 right > now on grm(rebuild my other system right now)l and there has been changes. > Not sure why they changed it. Even the man page states you have to be root > to update the cache. fsr is reporting the same issue. You are correct on > wheezy it does appear to work. > > Jim I first learned of the problem in August 2014 with util-linux-2.25 in jessie/testing when 'fdisk -l' stopped working for user in a script. (refracta2usb) In the first jessie-based refracta isos, we had util-linux pinned to the wheezy version (2.20). @Didier - try pulling out the usb stick and replacing it with a different one. When I do that, the cache does not get updated. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "parazyd" > On Tue, 03 May 2016, Rob Owens wrote: > >> - Original Message - >> > From: "KatolaZ" >> >> > But do we really need all that complication? Couldn't we just leave >> > the initscript of each init system in a different directory and *tell >> > the init system* where they are to be found? This will allow a much >> > easier coexistence of different confs. >> > >> > Basically, everything related to sysvinit, stays in /etc/init.d, and >> > sysvinit knows it has to look there. OpenRC stuff stays in >> > /etc/openrc, and openrc knows it has to look there for its scripts. >> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look >> > there for its stuff. We add the next-init-system, it will have its >> > scripts in /etc/. >> >> 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). >> >> 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. >> > > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and > set it to /etc/openrc. Then all will be found inside, and the system > will already know what to do, without symlinking. 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). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Assuming Piotr means "sysvinit" when he says "init", I agree 100%. Unless you're a Debian Dev, Lennart Poettering, or a Red Hat stockholder, there's no rush to move away from sysvinit, which has been serving us very well for what, three decades? On Tue, 3 May 2016 08:41:37 +0200 poitr pogo wrote: > I vote for init to be default for at least few years. > Devuan might consider switching to something else few years after > wheezy lts will be dead. > > Meantime, all other init systems should be optional in Devuan. > > -- > Regards > Piotr > > On 5/3/16, Steve Litt wrote: > > On Mon, 2 May 2016 21:05:18 -0400 > > Hendrik Boom wrote: > > > >> Is there a summary of some sort explaining the various init > >> systems, how they're put together, how they work, and especially > >> the salient points on which they differ? > > > > I've tried. See > > http://troubleshooters.com/linux/init/features_and_benefits.htm#init_system_feature_matrix > > > > Keep in mind these two things: > > > > 1) I'm an order of magnitude less knowledeable on init systems than > > the average person on the supervis...@list.skarnet.org mailing list. > >Those guys found several mistakes in my matrix, and I'm not sure > > I corrected all of them. > > > > 2) Like everyone else, I have likes, dislikes and maybe an agenda. > > I'm a huge fan of daemontools-inspired inits, and I have a > > significant dislike of systemd. > > > > 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
On Tue, May 03, 2016 at 05:19:19PM +0200, parazyd wrote: [cut] > > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and > set it to /etc/openrc. Then all will be found inside, and the system > will already know what to do, without symlinking. > Great. It would b ideal if all the init systems would do the same, i.e. providing a configurable option to specify where their scripts are located. This will enforce isolation, and avoid moving around files or symlinks unnecessarily. 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] Fwd: For all you automounter programmers
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Rob Owens wrote: > - Original Message - > > From: "KatolaZ" > > > But do we really need all that complication? Couldn't we just leave > > the initscript of each init system in a different directory and *tell > > the init system* where they are to be found? This will allow a much > > easier coexistence of different confs. > > > > Basically, everything related to sysvinit, stays in /etc/init.d, and > > sysvinit knows it has to look there. OpenRC stuff stays in > > /etc/openrc, and openrc knows it has to look there for its scripts. > > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > > there for its stuff. We add the next-init-system, it will have its > > scripts in /etc/. > > 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). > > 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. > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and set it to /etc/openrc. Then all will be found inside, and the system will already know what to do, without symlinking. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgp8gAxom6MNU.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] .iso images label
On 05/03/2016 03:15 PM, hellekin wrote: On 04/29/2016 05:36 PM, Jim Murphy wrote: >Minor but it would be nice to see Devuan and not Debian >as the label. > >[snip] > >Would someone check and correct before the next release? > Follow up to https://git.devuan.org/devuan-packages/debian-installer/issues/52 == hk I use the following script: #!/bin/sh WORKDIR="$HOME" ISOTMP="DEVUAN" CREATEISO="`which mkisofs`" if [ "$CREATEISO" = "" ]; then CREATEISO="`which genisoimage`" fi LIVECDLABEL="unofficial Devuan 1.0 Alpha2" CUSTOMISO="unofficial-Devuan-1.0-Alpha2_amd64.iso" find $WORKDIR/$ISOTMP -xdev -type f -print0 | xargs -0 md5sum > md5sums $CREATEISO\ -quiet \ -r\ -V "$LIVECDLABEL"\ -cache-inodes\ -J\ -l\ -b isolinux/isolinux.bin\ -c isolinux/boot.cat\ -no-emul-boot\ -boot-load-size 4\ -boot-info-table\ -o $WORKDIR/$CUSTOMISO "$WORKDIR/$ISOTMP" isohybrid $WORKDIR/$CUSTOMISO md5sum $WORKDIR/$CUSTOMISO > $WORKDIR/$CUSTOMISO.md5 ### END OF THE SCRIPT # Supposing the content of the iso located in $HOME/DEVUAN. The label of the stick is $LABELCDLABEL Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] linux-libre-4.3.5-1
Hi Ismael, On 05/03/2016 02:35 PM, "Ismael L. Donis Garcia" wrote: Hi, > >I uploaded the kernel linux-libre-4.3.5-1, built for devuan jessie: > >http://gnuinos.org/linux-libre/pool/main/l/linux/ > >Cheers, > > Aitor. > >___ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > Because not lead the effort to the 4.4... kernel, I have understood that the branch stopped having 4.3 updates thanks for all your efforts, that God him good health | ISMAEL | This packaging is fetched in 05/03/2016 [*]. I tryed it with the 4.4 version, but i couldn't build it. I don't know if it was my fault... On the other hand, i use a lot of debian security patches. So, i prefer to use a version used by debian: in this case, debian sid (at the date of the packaging) Cheers, Aitor. [*] Yes, it's fetched in the present !! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 2016-05-03 at 10:06 -0400, Rob Owens wrote: > - Original Message - > > > > From: "KatolaZ" > > > > But do we really need all that complication? Couldn't we just leave > > the initscript of each init system in a different directory and *tell > > the init system* where they are to be found? This will allow a much > > easier coexistence of different confs. > > > > Basically, everything related to sysvinit, stays in /etc/init.d, and > > sysvinit knows it has to look there. OpenRC stuff stays in > > /etc/openrc, and openrc knows it has to look there for its scripts. > > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > > there for its stuff. We add the next-init-system, it will have its > > scripts in /etc/. > 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). So does Debian openrc. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Files .udeb
On 05/03/2016 02:00 PM, "Stephanie Daugherty" wrote: udeb files (aka micro-deb) are stripped down packages only used in building the installer and loading installer components into memory via a network connection Some of them do it via network connection, but not all of them... Thanks to this fact, there are a lot of distributions wich don't need any network connection during the installation. At the same that some of .deb packages need a network connection, some of .udeb packages need a network connection. Both have their own dependencies. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Files .udeb
On 05/03/2016 02:00 PM, "Ismael L. Donis Garcia"
wrote:
>udeb files (aka micro-deb) are stripped down packages only used in building
>the installer and loading installer components into memory via a network
>connection - they are >explicitly intended for tightly constrained
>environments such as the installation environment and embedded systems, and
>not meant to be installable on a standard system.
>
>
>
>>On Mon, May 2, 2016 at 10:59 AM Ismael L. Donis Garcia
>> wrote:
>>
>>what are the .udeb files?
>>
>>correcting error translating...
>>
>>I'm trying to create a local repository, but I do not download the files
>>.udeb
>>as you could download these files?
>>
>>#!/bin/sh
>>ARQUITECTURA=i386,amd64
>>METODO=http
>>RAMA=jessie
>>HOST=packages.devuan.org
>>DIR_MIRROR=/mnt/datos/sistemas/linux/devuan/merged
>>SECCIONES=main,contrib,non-free
>>
>>echo
>>"=="
>>echo "Actualizando los repositorios DEVUAN 'merged'; main, contrib,
>>non-free"
>>echo
>>"=="
>>echo ""
>>debmirror -a ${ARQUITECTURA} \
>>-s ${SECCIONES} \
>>-h ${HOST}/merged \
>>-d ${RAMA} -r / --progress \
>>-e
>>${METODO} --postcleanup --ignore-small-errors --ignore-missing-release
--ignore-release-gpg
>>--nosource --allow-dist-rename \
>>--diff=none \
>>${DIR_MIRROR}
>>
>>Best Regards
>>
>>| ISMAEL |
>>
Thanks you for the explanation
| ISMAEL |
If you want to download the *.udeb* packages, yout need to add:
SECCIONES=main/debian-installer
This is:
--section=main/debian-installer, etc...
and if you want to download also the sources, then remove "--nosource"
Hasta luego ;-)
Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
parazyd writes: > The current init system is old. Ancient. We should all agree on it. The current init system is younger than me. Despite I'm 43 (and will be 44 in a few months), people still want to see a proof of me being already 18 with annoying regularity (although the frequency has decreased). Further, I'm still being put down as "too young to be taken seriously" by a lot of people => I'm apparently not old and certainly not ancient. => 'The current init system' is then obviously neither old nor ancient. However, what was this now supposed to communicate from a technical point of view>? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
- Original Message - > From: "KatolaZ" > But do we really need all that complication? Couldn't we just leave > the initscript of each init system in a different directory and *tell > the init system* where they are to be found? This will allow a much > easier coexistence of different confs. > > Basically, everything related to sysvinit, stays in /etc/init.d, and > sysvinit knows it has to look there. OpenRC stuff stays in > /etc/openrc, and openrc knows it has to look there for its scripts. > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > there for its stuff. We add the next-init-system, it will have its > scripts in /etc/. 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). 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. -Rob ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: For all you automounter programmers
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On 03/05/16 21:43, KatolaZ wrote: > On Tue, May 03, 2016 at 09:24:42PM +1200, Daniel Reurich wrote: > > [cut] > >> >> Absolutely, but for the average user, having /etc/init.d and >> /etc/openrc and /etc/wtf all there when using sysvinit (and not >> changing between init systems) is only going to lead to confusion. >> Being able to have them only installed when the init system is >> installed reduces the cruft left around - and the only way to do >> that is with triggers ala init-system-helpers and deb-helper shim >> for each init that's added to a package. >> > > Agreed. But still, it would me much easier to maintain the whole > mess if each init system is isolated from the others, with no > interactions whatsoever. Different inits, separate scripts, separate > directories. That's what I'm saying also - keep them separate but only install those parts when their respective init systems are installed. > >> The bonus is that each init system can be implemented independently >> and the service packages have support built-in as people wanting >> their fav init system get it added in to the package. This will in >> most cases be a small patch adding the necessary init scripts and >> adding dh- into debian/rules. No extra cruft will be >> installed on the end users system unless the user installs that >> init system. >> > > This might become a bit of a mess, if I understood correctly, since > we would have to maintain either a package of scripts for each init > system, or thousands packages like "apache-scripts-sysv", > "apache-scripts-openrc", "apache-scripts-wtf". > No. The init scripts for all inits go directly in the package - apache. But they should be deployed to (or removed from) the filesystem by a dpkg-trigger that is tripped by the installation or removal of the respective init-system to which those packages belong. > Why we don't just ship the init scripts for each system with the > corresponding service, install them "somewhere else" (e.g., > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been > already suggested by others) Yes I agree about this too! > and then copy (or symlink) the corresponding directory in /etc/ only > when the user selects "wtf" as init system? No this is wrong.. because the user will have all this cruft installed for all possible init systems which will be confusing. The dpkg-triggers way means that only when "wtf" init is installed does dpkg-trigger install the scripts for "wtf" from each services package into /etc/wtf. > This could be managed much more easily by update-alternatives, which > has just to update two symlinks, e.g. he one corresponding to > /sbin/init and the one corresponding to it's bloody scripts > directory I'm not sure the first is best managed that way and the second is entirely superfluous as each respective init should point to it's own binary and directory of init scripts directly. I'd prefer to have a -base and package with: -base being installed/removed triggering deployment/removal of all the service scripts (and any work arounds for services without scripts for that specific init system) providing the init binary and pre-depending on -base (so can't be installed without -base, and -base can't be installed without first changing the initsystem. As already is the case depends on the package "init" which is a meta-package that enforces one to be installed and also sets the default Anyway this is pie in the skie talk until we have a final release out. Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [helle...@dyne.org: Re: Missing packages]
On 04/29/2016 09:50 PM, Haines Brown wrote: > >> Hellekin wrote: >> >> You should use http://packages.devuan.org/merged/ for >> Devuan sources. Not anything else. > Update: auto.mirror.devuan.org gives you the closest (fastest) mirror available, and is preferred. > Let me see if I understand you correctly. the package firmware-iwlwifi > is not open software, and so is not available from the devuan package > archive. So > > a) The sources.list line > deb http://packages.devuan.org/merged jessie main non-free contrib > should not have non-free appended because devuan does not support > non-free packages. > No. If you choose to append "non-free", non-free packages will be transparently made available from the Debian archive. Amprolla does the transparent proxy and keep systemd dependencies off your system. It's a bit sad to block free software and allow non-free software, but this is how it goes now. Hopefully someday we don't need to block any free software, nor allow any non-free software. > b) The only way to get firmware-iwlwifi, an essential package I cannot > do without, is to get it as I did from the Debian mirror, but I'm > "on my own" because Devuan does not support it. > Wrong. See above. > c) The same for task-mail-server, which apparently has some non-free > drivers. Is this why it is absent? I had to install the obvious > applications such as exim4, procmail, mutt, spamassassin, > individually. > You should use Devuan like you use Debian, except the sources should use devuan.org exclusively. BTW we're trying to push auto.mirror.devuan.org and CC.mirror.devuan.org (CC = country code) instead of packages.devuan.org, e.g., deb http://auto.mirror.devuan.org/merged/ jessie main deb-src http://auto.mirror.devuan.org/merged/ jessie main == 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] Could not resolve 'mirror.cc.columbia.edu'
On Tue, 03 May 2016, fsmithred wrote: > (Rant on) Are the only good dns servers on the planet the ones who are in > bed with spy agencies? I've tried several of the "open" ones, and I always > seem to have trouble with them. (Rant off) have a look at https://dnscrypt.org I cannot vet for each single provider, but at least avoids sniffing we also use it by default in Dowse https://github.com/dyne/dowse (which is under heavy development ATM and of course running on Devuan) by chaining dnsmasq (local cache) to dnscrypt-proxy and works well. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] .iso images label
On 04/29/2016 05:36 PM, Jim Murphy wrote: > Minor but it would be nice to see Devuan and not Debian > as the label. > > [snip] > > Would someone check and correct before the next release? > Follow up to https://git.devuan.org/devuan-packages/debian-installer/issues/52 == 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] OpenRC and Devuan
On Tue, 2016-05-03 at 12:44 +, hellekin wrote:
> On 05/03/2016 12:00 PM, KatolaZ wrote:
> >
> >
> > I definitely agree with you Jim, and this is certainly one aspect to
> > be taken into account seriously. We should strive to allow the maximum
> > flexibility in choosing an init system, ensuring that the set of
> > constraints remains as small as possible.
> >
> I like Dan's proposal to use update-alternatives to manage which init
> system to run. Usually choosing an init for a given system only happens
> once during the install phase, unless you're actually testing setup of
> inits.
>
> What about an init-freedom meta-package working like mail-server and
> linking to various working combinations of init + process manager +
> device manager? It could provide a choice at install time, and be
> changeable using dpkg-reconfigure init-freedom.
>
> In passing, are there init script converters between various approaches?
>
> Maintaining compatibility of a given package with various init systems
> should be easy to track ("hey, your package is compatible with the
> default init system [currently: sysvinit], but lacks support for:
> openrc, systemd"). At least automatically create issues for this so
> that package maintainers can add the relevant scripts.
>
> That way, when we decide to switch the default init system away from
> sysvinit, it's because we know most or all packages support the new
> default system, *and* flipping back and forth from new to old default in
> case anything goes wrong. Lotsa werk ahead.
Nice idea, and name, fully supported!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: For all you automounter programmers
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 == 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] OpenRC and Devuan
On 05/03/2016 12:00 PM, KatolaZ wrote:
>
> I definitely agree with you Jim, and this is certainly one aspect to
> be taken into account seriously. We should strive to allow the maximum
> flexibility in choosing an init system, ensuring that the set of
> constraints remains as small as possible.
>
I like Dan's proposal to use update-alternatives to manage which init
system to run. Usually choosing an init for a given system only happens
once during the install phase, unless you're actually testing setup of
inits.
What about an init-freedom meta-package working like mail-server and
linking to various working combinations of init + process manager +
device manager? It could provide a choice at install time, and be
changeable using dpkg-reconfigure init-freedom.
In passing, are there init script converters between various approaches?
Maintaining compatibility of a given package with various init systems
should be easy to track ("hey, your package is compatible with the
default init system [currently: sysvinit], but lacks support for:
openrc, systemd"). At least automatically create issues for this so
that package maintainers can add the relevant scripts.
That way, when we decide to switch the default init system away from
sysvinit, it's because we know most or all packages support the new
default system, *and* flipping back and forth from new to old default in
case anything goes wrong. Lotsa werk ahead.
==
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
On Tue, May 3, 2016 at 7:28 AM, Didier Kryn wrote: > Le 03/05/2016 14:06, Jim Murphy a écrit : >> >> On Tue, May 3, 2016 at 4:04 AM, Didier Kryn wrote: >>> >>> Le 02/05/2016 14:12, fsmithred a écrit : 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. -fsr On 04/28/2016 01:52 PM, fsmithred wrote: > > On 04/27/2016 08:28 PM, fsmithred wrote: >> >> You could get the label from lsblk, do 'pmount label' and it will be >> mounted at /media/label. Every time you plug in a thumb drive labeled >> backup, it'll go to the same place. If you unmount the drive, >> /media/label >> will no longer exist, so you could even have the backup script check >> to >> make sure it's there. >> >> -fsr >> > Correction - Only root can get the label from lsblk. User can get the > label from '/sbin/blkid -s LABEL', but only after root has run blkid at > least once. Other than that, I've now got a script that will handle the > labels... sometimes. > > -fsr > > >>> kryn@apcnb98:~$ /sbin/blkid /dev/sda5 >>> /dev/sda5: LABEL="/" UUID="d91acaa3-5fdc-49e9-9f2b-ba7f3efb33f9" >>> UUID_SUB="6a0c80cd-5dc6-4135-8018-575686e7e11e" TYPE="btrfs" >>> kryn@apcnb98:~$ /sbin/blkid /dev/sda6 >>> /dev/sda6: LABEL="/usr" UUID="05f9f811-b8b1-445f-ac8c-9537a202a9f9" >>> UUID_SUB="52b8e1b8-7080-4696-94e1-8f7580005871" TYPE="btrfs" >>> >>> Didier >> >> 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. >> >> Jim > > > I cannot reproduce what you describe. I just tried it with a usb stick: > kryn@apcnb98:~$ /sbin/blkid /dev/sdb2 > /dev/sdb2: LABEL="Didier-Kryn-2" UUID="64f73abe-34b9-4d4c-bac7-6dd85f0e4696" > TYPE="reiserfs" > > This was done on debian-wheezy, from the console, without any DE > running, and even display manager stopped, and after a fresh reboot. If > blkid, invoked by normal user, runs from cache, then it means it has been > invoked by root after insertion - I suspect udev and consider it a good > thing, and I can tell you that vdev does systematically invoke blkid for > every block device. > > Didier > Not sure where the change took place, wheezy is 2.20, I'm look at 2.25 right now on grm(rebuild my other system right now)l and there has been changes. Not sure why they changed it. Even the man page states you have to be root to update the cache. fsr is reporting the same issue. You are correct on wheezy it does appear to work. Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] For all you automounter programmers
Le 03/05/2016 14:06, Jim Murphy a écrit : On Tue, May 3, 2016 at 4:04 AM, Didier Kryn wrote: Le 02/05/2016 14:12, fsmithred a écrit : 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. -fsr On 04/28/2016 01:52 PM, fsmithred wrote: On 04/27/2016 08:28 PM, fsmithred wrote: You could get the label from lsblk, do 'pmount label' and it will be mounted at /media/label. Every time you plug in a thumb drive labeled backup, it'll go to the same place. If you unmount the drive, /media/label will no longer exist, so you could even have the backup script check to make sure it's there. -fsr Correction - Only root can get the label from lsblk. User can get the label from '/sbin/blkid -s LABEL', but only after root has run blkidat least once. Other than that, I've now got a script that will handle the labels... sometimes. -fsr kryn@apcnb98:~$ /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/" UUID="d91acaa3-5fdc-49e9-9f2b-ba7f3efb33f9" UUID_SUB="6a0c80cd-5dc6-4135-8018-575686e7e11e" TYPE="btrfs" kryn@apcnb98:~$ /sbin/blkid /dev/sda6 /dev/sda6: LABEL="/usr" UUID="05f9f811-b8b1-445f-ac8c-9537a202a9f9" UUID_SUB="52b8e1b8-7080-4696-94e1-8f7580005871" TYPE="btrfs" Didier 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. Jim I cannot reproduce what you describe. I just tried it with a usb stick: kryn@apcnb98:~$ /sbin/blkid /dev/sdb2 /dev/sdb2: LABEL="Didier-Kryn-2" UUID="64f73abe-34b9-4d4c-bac7-6dd85f0e4696" TYPE="reiserfs" This was done on debian-wheezy, from the console, without any DE running, and even display manager stopped, and after a fresh reboot. If blkid, invoked by normal user, runs from cache, then it means it has been invoked by root after insertion - I suspect udev and consider it a good thing, and I can tell you that vdev does systematically invoke blkid for every block device. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] sources.list targets
On 05/03/2016 10:28 AM, Jaromil wrote: > On Tue, 03 May 2016, Daniel Reurich wrote: > >> Indeed we need a canonical FAQ for Devuan - one that contains correct >> information and properly managed. > > best strategy for that is to restart it on our forum https://talk.devuan.org > FYI: https://talk.devuan.org/t/frequently-answered-questions/231 and: https://devuan.org/os/documentation/faq/ (the two are interdependent, the latter is supposed to synthesize the former) == 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] linux-libre-4.3.5-1
- Original Message - From: "aitor_czr" To: Sent: Monday, May 02, 2016 5:13 PM Subject: [DNG] linux-libre-4.3.5-1 Hi, I uploaded the kernel linux-libre-4.3.5-1, built for devuan jessie: http://gnuinos.org/linux-libre/pool/main/l/linux/ Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Because not lead the effort to the 4.4... kernel, I have understood that the branch stopped having 4.3 updates thanks for all your efforts, that God him good health | ISMAEL | ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Fwd: For all you automounter programmers
Sorry for forward everyone, forgot to send to list. -- Forwarded message -- From: Jim Murphy Date: Tue, May 3, 2016 at 7:06 AM Subject: Re: [DNG] For all you automounter programmers To: Didier Kryn On Tue, May 3, 2016 at 4:04 AM, Didier Kryn wrote: > Le 02/05/2016 14:12, fsmithred a écrit : >> >> 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. >> >> -fsr >> >> >> On 04/28/2016 01:52 PM, fsmithred wrote: >>> >>> On 04/27/2016 08:28 PM, fsmithred wrote: You could get the label from lsblk, do 'pmount label' and it will be mounted at /media/label. Every time you plug in a thumb drive labeled backup, it'll go to the same place. If you unmount the drive, /media/label will no longer exist, so you could even have the backup script check to make sure it's there. -fsr >>> >>> Correction - Only root can get the label from lsblk. User can get the >>> label from '/sbin/blkid -s LABEL', but only after root has run blkid at >>> least once. Other than that, I've now got a script that will handle the >>> labels... sometimes. >>> >>> -fsr >>> >>> >> > > kryn@apcnb98:~$ /sbin/blkid /dev/sda5 > /dev/sda5: LABEL="/" UUID="d91acaa3-5fdc-49e9-9f2b-ba7f3efb33f9" > UUID_SUB="6a0c80cd-5dc6-4135-8018-575686e7e11e" TYPE="btrfs" > kryn@apcnb98:~$ /sbin/blkid /dev/sda6 > /dev/sda6: LABEL="/usr" UUID="05f9f811-b8b1-445f-ac8c-9537a202a9f9" > UUID_SUB="52b8e1b8-7080-4696-94e1-8f7580005871" TYPE="btrfs" > > Didier 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. Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
IMHO i would expect package init scripts for default init system to be part of a package (binary,base, etc) and scripts for alternate systems to be in separate package(s). Of course all residing in single src package maintained by the devuan package maintainer. Someone who decides to use alternate init is in some sense on his own, but has all available scripts in packages so can install them. Or the package for alternate init system can provide helper tools to install available packages and even inform the user which packages have missing scripts for selected alternate init system and have to be provided manually. So several init systems can coexist with one beeing more priviledged than others. Some enthusiast may even provide single package with all available optional init scripts for all applications. Whatever suits. Several options, one default with strict rules. Regarding handling init scripts for different inits, the only hard moment i can imagine is the time when devuan comes to decision to select new init system as a default one. But even then it will probably happen with a new release. So all packages will be recreated including by default init scripts for new system. And moving old sysvinit into separate, additional package, making sysvinit optional. -- Regards piotr written using my smartphone 03-05-2016 13:18, "KatolaZ" napisał(a): > On Tue, May 03, 2016 at 12:18:37PM +0200, parazyd wrote: > > On Tue, 03 May 2016, KatolaZ wrote: > > > > [cut] > > > > Why we don't just ship the init scripts for each system with the > > > corresponding service, install them "somewhere else" (e.g., > > > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been > > > already suggested by others) and then copy (or symlink) the > > > corresponding directory in /etc/ only when the user selects "wtf" as > > > init system? This could be managed much more easily by > > > update-alternatives, which has just to update two symlinks, e.g. he > > > one corresponding to /sbin/init and the one corresponding to it's > > > bloody scripts directory... > > > > This is very much a hack. Not really a good way to do it. As Dan says, > > submitting patches to the already existing packages is a much more > > elegant way. I think Dan proposed a very good thing, almost a complete > > solution. > > > > I am not against submitting patches to existing packags to include > init scripts. > > Only, whatever smart solution you come up with guys, please try as > hard as possible to keep it as *simple* as possible, not a single bit > more, not a single bit less. The fewer interactions we have among sets > of init scripts belonging to different init systems (ideally, no > interaction whatsoever), the easier maintaining them in the long run, > and plugging in new init systems as yet unforeseen. > > Ideally, switching between init systems (e.g., reverting back to an > init system which is known to work) should be achievable from a > single-user root shell spawned as an emergency "init", using only a > few executables in /bin and /sbin. Anything more complicated than that > risks to become not that useful or even harmful in the long run, IMHO. > > PrimoDevuanStabilisCreandaEst > > 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 > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote: [cut] > > I know this is in the very early stages and where things go is > still open to discussion, but consider this. > > 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. > > Something to consider and discuss, I hope. > I definitely agree with you Jim, and this is certainly one aspect to be taken into account seriously. We should strive to allow the maximum flexibility in choosing an init system, ensuring that the set of constraints remains as small as possible. 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] Files .udeb
- Original Message -
From: Stephanie Daugherty
To: Ismael L. Donis Garcia ; Lista de Devuan
Sent: Monday, May 02, 2016 2:58 PM
Subject: Re: [DNG] Files .udeb
udeb files (aka micro-deb) are stripped down packages only used in building
the installer and loading installer components into memory via a network
connection - they are >explicitly intended for tightly constrained
environments such as the installation environment and embedded systems, and
not meant to be installable on a standard system.
On Mon, May 2, 2016 at 10:59 AM Ismael L. Donis Garcia
wrote:
what are the .udeb files?
correcting error translating...
I'm trying to create a local repository, but I do not download the files
.udeb
as you could download these files?
#!/bin/sh
ARQUITECTURA=i386,amd64
METODO=http
RAMA=jessie
HOST=packages.devuan.org
DIR_MIRROR=/mnt/datos/sistemas/linux/devuan/merged
SECCIONES=main,contrib,non-free
echo
"=="
echo "Actualizando los repositorios DEVUAN 'merged'; main, contrib,
non-free"
echo
"=="
echo ""
debmirror -a ${ARQUITECTURA} \
-s ${SECCIONES} \
-h ${HOST}/merged \
-d ${RAMA} -r / --progress \
-e
${METODO} --postcleanup --ignore-small-errors --ignore-missing-release
--ignore-release-gpg
--nosource --allow-dist-rename \
--diff=none \
${DIR_MIRROR}
Best Regards
| ISMAEL |
Thanks you for the explanation
| ISMAEL |
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 3, 2016 at 4:43 AM, KatolaZ wrote: --- cut --- > Why we don't just ship the init scripts for each system with the > corresponding service, install them "somewhere else" (e.g., > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been > already suggested by others) and then copy (or symlink) the > corresponding directory in /etc/ only when the user selects "wtf" as > init system? This could be managed much more easily by > update-alternatives, which has just to update two symlinks, e.g. he > one corresponding to /sbin/init and the one corresponding to it's > bloody scripts directory... > > PrimoDevuanStabilisCreandaEst > I know this is in the very early stages and where things go is still open to discussion, but consider this. 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. Something to consider and discuss, I hope. Thanks, Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Could not resolve 'mirror.cc.columbia.edu'
On 05/03/2016 04:54 AM, Daniel Reurich wrote: > On 03/05/16 20:28, Jaromil wrote: >> On Mon, 02 May 2016, fsmithred wrote: >> >>> I've been having trouble installing beta due to packages not >>> downloading. This was with the netinstall, the CD and the DVD. >>> Tonight, I couldn't do a debootstrap install because some packages >>> wouldn't download. Also can't do update/upgrade of existing >>> installation for same reason. >> >>> This error has come up a few times: Could not resolve >>> 'mirror.cc.columbia.edu' >> >>> I tried changing sources.list to packages.devuan.org, but I still >>> get the same error. Is there another address for a repo I can use >>> that won't try to resolve to columbia.edu? >> >> while this may have been a problem of your network setup, it is true >> that hickups may be experienced from time to time. We are monitoring >> them and it seems they are due to the httpredir.debian.org hop that >> amprolla does when packages are not into the devuan repo. >> >> nextime is working on a solution for this, but meanwhile re-trying >> mostly leads to the solution of the problem, since httpredir will >> rotate to another mirror. >> >> still I believe your problem here is due to dns configuration on >> your side, since the mirror in question seems to resolve and work >> > We have a potential solution for this, can if you have a reliable in > country debian mirror and can email me the details we can set up a > redirect for your country code to use that mirror instead of debians > httpredir > > Regards > Daniel. > Jaromil nailed it. I recently changed the dns I was using, and now that I've changed it back, all is working smoothly. If you want to know a reliable debian mirror in the northease US, this one is good. (It's a replacement for the old debian.lcs.mit.edu.) http://debian.csail.mit.edu/debian/ (Rant on) Are the only good dns servers on the planet the ones who are in bed with spy agencies? I've tried several of the "open" ones, and I always seem to have trouble with them. (Rant off) Thanks for the quick help, guys. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 03, 2016 at 12:18:37PM +0200, parazyd wrote: > On Tue, 03 May 2016, KatolaZ wrote: > [cut] > > Why we don't just ship the init scripts for each system with the > > corresponding service, install them "somewhere else" (e.g., > > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been > > already suggested by others) and then copy (or symlink) the > > corresponding directory in /etc/ only when the user selects "wtf" as > > init system? This could be managed much more easily by > > update-alternatives, which has just to update two symlinks, e.g. he > > one corresponding to /sbin/init and the one corresponding to it's > > bloody scripts directory... > > This is very much a hack. Not really a good way to do it. As Dan says, > submitting patches to the already existing packages is a much more > elegant way. I think Dan proposed a very good thing, almost a complete > solution. > I am not against submitting patches to existing packags to include init scripts. Only, whatever smart solution you come up with guys, please try as hard as possible to keep it as *simple* as possible, not a single bit more, not a single bit less. The fewer interactions we have among sets of init scripts belonging to different init systems (ideally, no interaction whatsoever), the easier maintaining them in the long run, and plugging in new init systems as yet unforeseen. Ideally, switching between init systems (e.g., reverting back to an init system which is known to work) should be achievable from a single-user root shell spawned as an emergency "init", using only a few executables in /bin and /sbin. Anything more complicated than that risks to become not that useful or even harmful in the long run, IMHO. PrimoDevuanStabilisCreandaEst 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] Devuan Security Repo (was Re: invalid security certificate)
So now, when information on web site is correct please consider removing 'mirrors' workaround so it will not get propagated. And clear message will be sent to users which address should be used. Once removed people will be forced to clean their setup now, and new mistakenly created setups will simply not work. The small mess will be cleaned fast. Proper message on web page, for those who read old outdated mails/post might be helpful. But once the official info is corected, remove the 's' workaround when the cost of removing it is rather small. IMHO -- Regards piotr 03-05-2016 12:52, "hellekin" napisał(a): > On 05/02/2016 09:15 AM, Arnt Gulbrandsen wrote: > > helle...@dyne.org writes: > >> auto.mirrors does not exist: only auto.mirror does. Unknown names point > >> to www.devuan.org. > > > > Auto.mirrors exists as of yesterday. It was on the devuan home page due > > to a typo. Nextime made the typo work, then fixed the typo. > > > > Indeed. Hopefully this is the last instance of a typo going into > production. Wrong links have a cost: compare with losing bitcoins, > related to the namespace; multiple links to the same resource is Bad™. > > So even if auto.mirrors exists, you shouldn't use it nor rely on it, and > consider it doesn't exist. The link might be removed in the future, so > if you're currently using mirrors with an s, use mirror instead. > > == > 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 > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Security Repo (was Re: invalid security certificate)
On 05/02/2016 09:15 AM, Arnt Gulbrandsen wrote: > helle...@dyne.org writes: >> auto.mirrors does not exist: only auto.mirror does. Unknown names point >> to www.devuan.org. > > Auto.mirrors exists as of yesterday. It was on the devuan home page due > to a typo. Nextime made the typo work, then fixed the typo. > Indeed. Hopefully this is the last instance of a typo going into production. Wrong links have a cost: compare with losing bitcoins, related to the namespace; multiple links to the same resource is Bad™. So even if auto.mirrors exists, you shouldn't use it nor rely on it, and consider it doesn't exist. The link might be removed in the future, so if you're currently using mirrors with an s, use mirror instead. == 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] cloud
On 05/02/2016 11:37 AM, Herb Garcia wrote: > By that metric, using the phrase "cloud-init" is at least descriptive, > and not marketing buzzword driven. > It reminds me of the silver ion spreading technique used in China to create rain and wash Beijing's roofs from desert sand. Now *that* is "cloud init". In a computing context, still no luck for me to understand what it means. Whoever coined the term "cloud" in this context didn't want to be descriptive. I want to call it "rabbit" or "Shub-Niggurath" to make that clear: "Everything about rabbit-init, a set of python scripts and utilities to make your rabbit images be all they can be!" -> bullshit "Shub-Niggurath-init is the defacto multi-distribution package that handles early initialization of a Shub-Niggurath instance." -> that must be the ritual part, before the rain comes. == 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] sources.list targets
On Tue, 03 May 2016, Daniel Reurich wrote: > Indeed we need a canonical FAQ for Devuan - one that contains correct > information and properly managed. best strategy for that is to restart it on our forum https://talk.devuan.org which will facilitate contributions in place of the git/docbook setup of the "canonical" debian FAQ. the latter also does not contain really important information, the few useful things in there can be imported this is an open task for anyone willing to volunteer, it does not require particular technical skills and guidance can be asked on the irc #devuan channel, hellekin is the forum admin ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] sources.list targets
canonical url should be auto.mirror.devuan.org or .mirror.devuan.org where the CC is either the country code which will soon point to a canonical debian mirror (or mirrors) for that country. > > Also, dev1fanboy's pages (and their derivatives) suggest using > packages.devuan.org hmm that needs to be updated too then. > > Finally, I see that the devuan project has sprouted a lot of pages, and > suddenly there is a problem of which ones are authoritative. > I'll note that the FAQ, which is where many people go first > for answers, contains only stubs. I'm sure several on this > list would be happy to contribute! Indeed we need a canonical FAQ for Devuan - one that contains correct information and properly managed. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, KatolaZ wrote: > > The bonus is that each init system can be implemented independently and > > the service packages have support built-in as people wanting their fav > > init system get it added in to the package. This will in most cases be > > a small patch adding the necessary init scripts and adding > > dh- into debian/rules. No extra cruft will be installed on > > the end users system unless the user installs that init system. > > > > This might become a bit of a mess, if I understood correctly, since we > would have to maintain either a package of scripts for each init > system, or thousands packages like "apache-scripts-sysv", > "apache-scripts-openrc", "apache-scripts-wtf". > > Why we don't just ship the init scripts for each system with the > corresponding service, install them "somewhere else" (e.g., > /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been > already suggested by others) and then copy (or symlink) the > corresponding directory in /etc/ only when the user selects "wtf" as > init system? This could be managed much more easily by > update-alternatives, which has just to update two symlinks, e.g. he > one corresponding to /sbin/init and the one corresponding to it's > bloody scripts directory... This is very much a hack. Not really a good way to do it. As Dan says, submitting patches to the already existing packages is a much more elegant way. I think Dan proposed a very good thing, almost a complete solution. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpbxz1jDGPoh.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] network-manager depends on libpam-systemd
Le 03/05/2016 11:35, Daniel Reurich a écrit : On 03/05/16 20:56, Didier Kryn wrote: >Le 02/05/2016 03:41, Nate Bargmann a écrit : >>I know, I would probably be better off doing everything it does by >>hand. That said there is something very nice about opening the lid and >>by the time I enter my password to unlock Xscreensaver, NM has the >>network configured on my AP. > > FYI, this functionality is achieved by a proper configuration of >wpa_supplicant. > > No need for an additional layer encumbered with so many dependencies. > You realise that NM uses wpa-supplicant right? It just doesn't do it via the standard debian config files. We can fix the backend to do that - but for now making it build to run without systemd is what we need. :D Yes, I know. All these front-ends use wpa_supplicant in their kitchen. I just wonder why they find it more clever to re-do on their own what wpa_supplicant can do alone. However, IIUC, NM is also taking care of some usb connections, which is out of the scope of wpa_supplicant. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 03, 2016 at 09:24:42PM +1200, Daniel Reurich wrote: [cut] > > Absolutely, but for the average user, having /etc/init.d and /etc/openrc > and /etc/wtf all there when using sysvinit (and not changing between > init systems) is only going to lead to confusion. Being able to have > them only installed when the init system is installed reduces the cruft > left around - and the only way to do that is with triggers ala > init-system-helpers and deb-helper shim for each init that's added to a > package. > Agreed. But still, it would me much easier to maintain the whole mess if each init system is isolated from the others, with no interactions whatsoever. Different inits, separate scripts, separate directories. > The bonus is that each init system can be implemented independently and > the service packages have support built-in as people wanting their fav > init system get it added in to the package. This will in most cases be > a small patch adding the necessary init scripts and adding > dh- into debian/rules. No extra cruft will be installed on > the end users system unless the user installs that init system. > This might become a bit of a mess, if I understood correctly, since we would have to maintain either a package of scripts for each init system, or thousands packages like "apache-scripts-sysv", "apache-scripts-openrc", "apache-scripts-wtf". Why we don't just ship the init scripts for each system with the corresponding service, install them "somewhere else" (e.g., /var/cache/sysvinit, /var/cache/openrc, /var/cache/wtf, as has been already suggested by others) and then copy (or symlink) the corresponding directory in /etc/ only when the user selects "wtf" as init system? This could be managed much more easily by update-alternatives, which has just to update two symlinks, e.g. he one corresponding to /sbin/init and the one corresponding to it's bloody scripts directory... PrimoDevuanStabilisCreandaEst 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] network-manager depends on libpam-systemd
On 03/05/16 20:56, Didier Kryn wrote: > Le 02/05/2016 03:41, Nate Bargmann a écrit : >> I know, I would probably be better off doing everything it does by >> hand. That said there is something very nice about opening the lid and >> by the time I enter my password to unlock Xscreensaver, NM has the >> network configured on my AP. > > FYI, this functionality is achieved by a proper configuration of > wpa_supplicant. > > No need for an additional layer encumbered with so many dependencies. > You realise that NM uses wpa-supplicant right? It just doesn't do it via the standard debian config files. We can fix the backend to do that - but for now making it build to run without systemd is what we need. :D -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On 03/05/16 17:24, Didier Kryn wrote: Le 03/05/2016 08:51, Mitt Green a écrit : The current init system is old. Ancient. We should all agree on it. Devuan is looking for a new init system that is not systemd and my personal choice for this task from now on is Gentoo's OpenRC. Unix is old. Ancient. We should all agree on it. Devuan is looking for a new base system that is not Unix and my personal choice for this task from now is Microsoft's Windows. Debian-potato was systemd-free. OK it's old now, but still less than Unix. Why not still use it? No need for Devuan. I am still using it in several locations, but for net connected systems security updates are nice. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On 03/05/16 20:59, KatolaZ wrote: > On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote: > > [cut] > >> >> This can all be handled in each package with the package triggers >> enabled easily with a debhelper script similar to dh-systemd which makes >> it easy to deploy init scripts/unit files/runscripts etc in their own >> namespace and /etc/ and only deploy them when the init >> system is installed and removes them when it is removed. This shifts >> the burden to package maintainers, but that is the right place for them >> and we can make it easy to add additional init-scripts by filing bugs >> with patches. > > But do we really need all that complication? Couldn't we just leave > the initscript of each init system in a different directory and *tell > the init system* where they are to be found? This will allow a much > easier coexistence of different confs. Actually yes it will be much easier and cleaner that way and make transitioning from one to another much simpler. > > Basically, everything related to sysvinit, stays in /etc/init.d, and > sysvinit knows it has to look there. OpenRC stuff stays in > /etc/openrc, and openrc knows it has to look there for its scripts. > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > there for its stuff. We add the next-init-system, it will have its > scripts in /etc/. Absolutely, but for the average user, having /etc/init.d and /etc/openrc and /etc/wtf all there when using sysvinit (and not changing between init systems) is only going to lead to confusion. Being able to have them only installed when the init system is installed reduces the cruft left around - and the only way to do that is with triggers ala init-system-helpers and deb-helper shim for each init that's added to a package. The bonus is that each init system can be implemented independently and the service packages have support built-in as people wanting their fav init system get it added in to the package. This will in most cases be a small patch adding the necessary init scripts and adding dh- into debian/rules. No extra cruft will be installed on the end users system unless the user installs that init system. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
Le 03/05/2016 08:51, Mitt Green a écrit : The current init system is old. Ancient. We should all agree on it. Devuan is looking for a new init system that is not systemd and my personal choice for this task from now on is Gentoo's OpenRC. Unix is old. Ancient. We should all agree on it. Devuan is looking for a new base system that is not Unix and my personal choice for this task from now is Microsoft's Windows. Debian-potato was systemd-free. OK it's old now, but still less than Unix. Why not still use it? No need for Devuan. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] For all you automounter programmers
Le 02/05/2016 14:12, fsmithred a écrit : 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. -fsr On 04/28/2016 01:52 PM, fsmithred wrote: On 04/27/2016 08:28 PM, fsmithred wrote: You could get the label from lsblk, do 'pmount label' and it will be mounted at /media/label. Every time you plug in a thumb drive labeled backup, it'll go to the same place. If you unmount the drive, /media/label will no longer exist, so you could even have the backup script check to make sure it's there. -fsr Correction - Only root can get the label from lsblk. User can get the label from '/sbin/blkid -s LABEL', but only after root has run blkid at least once. Other than that, I've now got a script that will handle the labels... sometimes. -fsr kryn@apcnb98:~$ /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/" UUID="d91acaa3-5fdc-49e9-9f2b-ba7f3efb33f9" UUID_SUB="6a0c80cd-5dc6-4135-8018-575686e7e11e" TYPE="btrfs" kryn@apcnb98:~$ /sbin/blkid /dev/sda6 /dev/sda6: LABEL="/usr" UUID="05f9f811-b8b1-445f-ac8c-9537a202a9f9" UUID_SUB="52b8e1b8-7080-4696-94e1-8f7580005871" TYPE="btrfs" Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan (and Windows)
On Tue, 5/3/16, Mitt Green wrote: Subject: Re: [DNG] OpenRC and Devuan To: dng@lists.dyne.org Date: Tuesday, May 3, 2016, 1:51 AM >> The current init system is old. Ancient. >> We should all agree on it. Devuan is looking >> for a new init system that is not systemd and my >> personal choice for this task from now on is >> Gentoo's OpenRC. > > Unix is old. Ancient. We should all agree on it. > Devuan is looking for a new base system that > is not Unix and my personal choice for this > task from now is Microsoft's Windows. > Mitt's response reminded me of a post that was made to the forum earlier today in the topic "Windows explained to Devuan supporters" at https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 : Linux = Pen testing Windows = everything else There are no advantages in using any linux distros other than pen testing and that it can be installed on a USB key(and I think that's very cool). Even Software Defined Radio (SDR) with maybe the exception of GMS intercepting and decoding, has more development under Windows. Night and day. One works extremely well on all PCs and permits the User to actually be productive and do things. The other one is a clunky Windows wannabe with a couple of specialized advantages that most don't care about. So.. YES I like its functionality, its popularity(more software dev and hardware support), its clarity and ease of use. The only thing wrong with my Windows is its lack of pen testing capability, and that is why I'm here (KL2 using Debian8 and now looking for an alternative with Dev-one as a base), otherwise I would >> n e v e r << bother with anything linux, life is too short I'll spare you my personal thoughts on this evaluation of Linux but looking forward to all of yours. :) golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, May 03, 2016 at 08:50:20PM +1200, Daniel Reurich wrote: [cut] > > This can all be handled in each package with the package triggers > enabled easily with a debhelper script similar to dh-systemd which makes > it easy to deploy init scripts/unit files/runscripts etc in their own > namespace and /etc/ and only deploy them when the init > system is installed and removes them when it is removed. This shifts > the burden to package maintainers, but that is the right place for them > and we can make it easy to add additional init-scripts by filing bugs > with patches. But do we really need all that complication? Couldn't we just leave the initscript of each init system in a different directory and *tell the init system* where they are to be found? This will allow a much easier coexistence of different confs. Basically, everything related to sysvinit, stays in /etc/init.d, and sysvinit knows it has to look there. OpenRC stuff stays in /etc/openrc, and openrc knows it has to look there for its scripts. WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look there for its stuff. We add the next-init-system, it will have its scripts in /etc/. No files to be moved around. No need to update any symlink. I am sure it is a too naive proposal, for reasons that I don't understand. PrimoDevuanStabilisCreandaEst 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] network-manager depends on libpam-systemd
Le 02/05/2016 03:41, Nate Bargmann a écrit : I know, I would probably be better off doing everything it does by hand. That said there is something very nice about opening the lid and by the time I enter my password to unlock Xscreensaver, NM has the network configured on my AP. FYI, this functionality is achieved by a proper configuration of wpa_supplicant. No need for an additional layer encumbered with so many dependencies. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Could not resolve 'mirror.cc.columbia.edu'
On 03/05/16 20:28, Jaromil wrote: > On Mon, 02 May 2016, fsmithred wrote: > >> I've been having trouble installing beta due to packages not >> downloading. This was with the netinstall, the CD and the DVD. >> Tonight, I couldn't do a debootstrap install because some packages >> wouldn't download. Also can't do update/upgrade of existing >> installation for same reason. > >> This error has come up a few times: Could not resolve >> 'mirror.cc.columbia.edu' > >> I tried changing sources.list to packages.devuan.org, but I still >> get the same error. Is there another address for a repo I can use >> that won't try to resolve to columbia.edu? > > while this may have been a problem of your network setup, it is true > that hickups may be experienced from time to time. We are monitoring > them and it seems they are due to the httpredir.debian.org hop that > amprolla does when packages are not into the devuan repo. > > nextime is working on a solution for this, but meanwhile re-trying > mostly leads to the solution of the problem, since httpredir will > rotate to another mirror. > > still I believe your problem here is due to dns configuration on > your side, since the mirror in question seems to resolve and work > We have a potential solution for this, can if you have a reliable in country debian mirror and can email me the details we can set up a redirect for your country code to use that mirror instead of debians httpredir Regards Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On 03/05/16 20:15, Joel Roth wrote: > Steve Litt wrote: >> On Mon, 2 May 2016 21:05:18 -0400 >> Hendrik Boom wrote: >> >>> Is there a summary of some sort explaining the various init systems, >>> how they're put together, how they work, and especially the salient >>> points on which they differ? >> >> I've tried. See >> http://troubleshooters.com/linux/init/features_and_benefits.htm#init_system_feature_matrix >> >> Keep in mind these two things: >> >> 1) I'm an order of magnitude less knowledeable on init systems than the >>average person on the supervis...@list.skarnet.org mailing list. >>Those guys found several mistakes in my matrix, and I'm not sure I >>corrected all of them. >> >> 2) Like everyone else, I have likes, dislikes and maybe an agenda. I'm >>a huge fan of daemontools-inspired inits, and I have a significant >>dislike of systemd. > > The problem with supporting multiple init systems is that > there is an init script for each service that has to be > ported or rewritten. This can all be handled in each package with the package triggers enabled easily with a debhelper script similar to dh-systemd which makes it easy to deploy init scripts/unit files/runscripts etc in their own namespace and /etc/ and only deploy them when the init system is installed and removes them when it is removed. This shifts the burden to package maintainers, but that is the right place for them and we can make it easy to add additional init-scripts by filing bugs with patches. > > Launching Devuan while maintaining the sysvinit status quo > has already stressed the pool of volunteer manpower to the > limit. Only because of the prolific infestation of packages with systemd dependencies. Other pure init systems suggested won't carry the same problems once we have systemd eradicated. > > So the practical way forward is to leave the task of > developing init scripts for the alternative init systems > to the users of those systems. > Yeah, with a little help in places. For ascii we should have atleast 2 init systems possible and sysvinit also able to be properly cleansed too. > If someone would volunteer to coordinate the infrastructure > needed to collect, systematize, debug and distribute the the > tens or hundreds of scripts involved (one for each service), > multiplied by the number of init systems to be supported, > I'm sure the Devuan project leads could consider in future > ways to bring them into the Devuan package ecosystem. > > For those with time to invest, I would suggest the > following: > > * determine a subset, those esssential services that, if supported, > would allow a user to get a usable base system: > > * choose one or two best-of-breed init systems to work on, > and provide infrastructure for collecting contributions > for *all* init systems, even less popular ones. * implement the debhelper script in the source package init-system-helpers. Sounds like a reasonable plan. Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Simon Hobson wrote: > Jaromil wrote: > > >> Instead of an openRC effort at this point, I'd rather see a hook > >> for apt-get / aptitude / etc, to move all files specific to init > >> systems not being used to their own file hierarchies, eg. > >> > >> /var/cache/init-systems > >>/sysvinit > >> /etc > >> /lib > >> /usr > >>/openrc > >> /etc > >> /lib > >> /usr > >>/systemd > >> /etc > >> /lib > >> /usr > > > This is an important suggestion, which parazyd himself was evaluating > > yesterday, noting that among the errors made in the previous openrc > > packages was this one: put the files of each init system in the same > > /etc/init.d directory, basically making them overlap. > > > > I agree we should adopt the policy you are proposing in Devuan. > > How does that work in terms of getting the right files into place ? Is it a > case of the switching process will copy the files into /etc and so on ? Or > will they be symlinked, or what ? And possibly more important, what's the > process for removing them when switching to another init ? And what about > having two systems installed for those who want to try one but leave the > other selectable at boot time (for if it doesn't work out ?) > I'm thinking back to the "debate" over /bin and /usr/bin and the discussions > related to what needs to be mounted early during boot - /var isn't typically > mounted until relatively late. > > From that basis, would it be better to perhaps put openrc scripts in > /etc/init-orc or something like that ? > /var/cache/init-systems ?? Yes, I know it's just an example, but is a very wrong one. All OpenRC specific files/dirs like init.d, conf.d, runlevels and such simply go to /etc/openrc/ , much like systemd with /etc/systemd. It is really the correct way to do it. Also, if one switches to OpenRC, you should forget about helper scripts like update-rc.d. If one switches to OpenRC from sysvinit, the install script would just have to look for the enabled initscripts and their runlevels, and enable them accordingly with OpenRC. Provided the initscripts are included in the packages already installed. On that note, Gentoo's package repositories might be a valuable resource. On what could/could be removed, IMHO the old sysvinit scripts can stick around because they will not overlap with OpenRC's scripts. The only thing that comes to mind is the inittab and how it will be handled? Perhaps just a symlink to /etc/openrc/inittab ... -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpTZ_udPcP6E.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
