Re: [Dng] [dng] vdev status updates

On Wed, May 13, 2015 at 7:42 AM, Jack L. Frost wrote: > On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote: > > Hey everyone, > > > > I have the latest news for vdev: > > Hi. I dunno if it's very relevant to this particular mailing list, but > still. > I've packaged vdev and all its depe

Re: [Dng] [dng] vdev status updates

On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote: > Hey everyone, > > I have the latest news for vdev: Hi. I dunno if it's very relevant to this particular mailing list, but still. I've packaged vdev and all its dependencies for Arch: https://aur.archlinux.org/packages/vdev-git https:

Re: [Dng] [dng] vdev status updates

Yes, we need another MacroShaft screwing us over a barrel... NOT. Sent from my Windows Phone From: Laurent Bercot<mailto:ska-de...@skarnet.org> Sent: ‎5/‎5/‎2015 3:21 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [Dng] [dng] vdev st

Re: [Dng] [dng] vdev status updates

On 05/05/2015 23:03, marc...@welz.org.za wrote: Hello No, sorry. Doing chown root:admin && chmod 2750 does not give anybody in the admin group (the ones who should be allowed to run it) any extra rights - they are already running with admin group privileges Ah, yes, my mistake. The pattern I w

Re: [Dng] [dng] vdev status updates

Hello > * I then argue that in the current world, autocompletion is not > reliable, because since it does not stat(), it cannot hide filenames > the user cannot execute, such as a 0644 file. What your autocompletion > is currently printing is an approximation of the programs you can run, > not an

Re: [Dng] [dng] vdev status updates

Le 02/05/2015 14:40, Hendrik Boom a écrit : On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote: Le 30/04/2015 20:16, John Morris a écrit : The FHS was carefully designed to accomodate things like NFS root, readonly NFS mounting of parts of the system, mandating things like */share/ to

Re: [Dng] [dng] vdev status updates

On Sun 03 May 2015 15:09:49 Hendrik Boom wrote: > files are identified *only* by metadata. Has anyone ever > tried something like this? I guess tracker and the way it's used by some apps / OS to locate data

Re: [Dng] [dng] vdev status updates

> On May 3, 2015 at 3:09 PM Hendrik Boom wrote: > > On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote: > > > Even in your dream distro without any path, don't tell me you won't *have* > > *to* come up with another concept for attaching meta info alternative to > > path > > names,

Re: [Dng] [dng] vdev status updates

On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote: > On Sun 03 May 2015 11:15:45 Laurent Bercot wrote: > > I remember 10ish years ago, mount was actually /sbin/mount. > > It migrated to /bin at some point, probably, as you say, when the > > "user" mount option was added. I personall

Re: [Dng] [dng] vdev status updates

On Sun, May 03, 2015 at 06:37:06PM +0200, Joerg Reisenweber wrote: > Even in your dream distro without any path, don't tell me you won't *have* > *to* come up with another concept for attaching meta info alternative to path > names, and then you need to update that instead of "moving files" Tak

Re: [Dng] [dng] vdev status updates

On Sun 03 May 2015 11:15:45 Laurent Bercot wrote: > I remember 10ish years ago, mount was actually /sbin/mount. > It migrated to /bin at some point, probably, as you say, when the > "user" mount option was added. I personally think that moving > executables between places is a bad thing, and one of

Re: [Dng] [dng] vdev status updates

On 03/05/2015 10:15, marc...@welz.org.za wrote: So you have just argued that to hide things from autocompletion, one should make things 0700. We have also established that for this scheme to work the shell needs to do a stat() *for* *each* *candidate* executable. But the my /bin/bash does not do

Re: [Dng] [dng] vdev status updates

On 02.05.2015 15:40, Hendrik Boom wrote: On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote: Le 30/04/2015 20:16, John Morris a écrit : The FHS was carefully designed to accomodate things like NFS root, Years ago I heard that /usr could be mounted read-only, and even shared between

Re: [Dng] [dng] vdev status updates

Hello again > >> 0700 for root-only binaries would hide them from your shell's > >> autocompletion. > > > >Which would be lots of stat() system calls. > > If a shell doesn't make them, then it doesn't verify that a file is > executable either. (I just checked with zsh: it doesn't indeed.) > Su

Re: [Dng] [dng] vdev status updates

On Sat 02 May 2015 11:01:07 Laurent Bercot wrote: > > So there are very good reasons for keeping the classic/standard layout. > > The reasons you gave so far are pretty minor. The reasons you gave for *changing* stuff are negligible so far: iirc it was a "shorter PATH which would benefit some

Re: [Dng] [dng] vdev status updates

On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote: > > Le 30/04/2015 20:16, John Morris a écrit : > >The FHS was carefully designed to accomodate things like NFS root, > >readonly NFS mounting of parts of the system, mandating things like > >*/share/ to only contain arch neutral data, e

Re: [Dng] [dng] vdev status updates

On 02/05/2015 09:43, marc...@welz.org.za wrote: 0700 for root-only binaries would hide them from your shell's autocompletion. Which would be lots of stat() system calls. If a shell doesn't make them, then it doesn't verify that a file is executable either. (I just checked with zsh: it do

Re: [Dng] [dng] vdev status updates

> On 30/04/2015 22:35, Joerg Reisenweber wrote: > >exactly this PATH issue is what I expect and appreciate here: I do NOT > >expect > >command autocompletion of normal user to get confused by command names that > >are not supposed to even be in user's PATH > > 0700 for root-only binaries would h

Re: [Dng] [dng] vdev status updates

On 30/04/2015 22:35, Joerg Reisenweber wrote: exactly this PATH issue is what I expect and appreciate here: I do NOT expect command autocompletion of normal user to get confused by command names that are not supposed to even be in user's PATH 0700 for root-only binaries would hide them from yo

Re: [Dng] [dng] vdev status updates

Le 30/04/2015 20:16, John Morris a écrit : The FHS was carefully designed to accomodate things like NFS root, readonly NFS mounting of parts of the system, mandating things like */share/ to only contain arch neutral data, etc. The whole FH can be shared by NFS root, except /var, which can

Re: [Dng] [dng] vdev status updates

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote: > It would also shorten PATHs, > which would be a definite blessing on some systems. I guess - just like you said, and according to RFC2119 "SHOULD (NOT)" - you could simply symlink /sbin to /bin on your system when there's a good reason for doi

Re: [Dng] [dng] vdev status updates

On Thu, Apr 30, 2015 at 10:32:54PM +0200, Joerg Reisenweber wrote: > On Thu 30 April 2015 19:02:54 Laurent Bercot wrote: > > - Made sense at the time, doesn't make sense today: the separation between > > administrator commands (/sbin, /usr/sbin) and user commands (/bin, > > /usr/bin). Back then,

Re: [Dng] [dng] vdev status updates

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote: > /sbin/route is not inherently better than > /bin/route; we are just used to /sbin/route and inertia does the rest - but > it would actually be *simpler* to just move everything to /bin and /usr/bin > and be rid of /sbin and /usr/sbin altogether.

Re: [Dng] [dng] vdev status updates

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote: > - Made sense at the time, doesn't make sense today: the separation between > administrator commands (/sbin, /usr/sbin) and user commands (/bin, > /usr/bin). Back then, filesystems were slow and scaled badly, caches were > small, and it was cos

Re: [Dng] [dng] vdev status updates

them, bad things happen. -Jim Sent from my Windows Phone From: Laurent Bercot<mailto:ska-de...@skarnet.org> Sent: ‎4/‎30/‎2015 12:16 PM To: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [Dng] [dng] vdev status updates On 30/04/2015 20:16,

Re: [Dng] [dng] vdev status updates

On 30/04/2015 20:16, John Morris wrote: He is correct on this point. One should always obey the rules until you understand why the rule was made and the consequences of breaking it. Except that the rule we're talking about just shouldn't be violated. Once upon a time the rule was that / sh

Re: [Dng] [dng] vdev status updates

On Thu, 2015-04-30 at 15:58 +0200, Joerg Reisenweber wrote: > Poettering clearly understood the implications and outright rejected the > rationale, by claiming nowadays it wasn't modern anymore to have a small root- > fs and a separate partition for /usr He is correct on this point. One should

Re: [Dng] [dng] vdev status updates

On 30/04/2015 15:58, Joerg Reisenweber wrote: I beg to differ on that, to me it seems it has all the sound rationale it needs, to for example understand why /bin should have commands that are needed during early boot, before /usr gets mounted. Thus FHS is not only a summary of current practice b

Re: [Dng] [dng] vdev status updates

On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote: > (i.e. a device file > that shows up in devtmpfs from the kernel does not generate an inotify > event). I wonder if that's a bug or a feature. -- hendrik ___ Dng mailing list Dng@lists.dyne

Re: [Dng] [dng] vdev status updates

On Thu 30 April 2015 15:30:06 Didier Kryn wrote: > This FHS is nothing more than a summary of current practice; it > does not contain any sound rationale I beg to differ on that, to me it seems it has all the sound rationale it needs, to for example understand why /bin should have commands t

Re: [Dng] [dng] vdev status updates

Le 30/04/2015 13:21, Joerg Reisenweber a écrit : and here is more (sorry to link to the obvious): http://www.pathname.com/fhs/pub/fhs-2.3.html (possibly outdated, I didn't check for a long time) Thanks Joerg, for recalling the link. This FHS is nothing more than a summary of current pr

Re: [Dng] [dng] vdev status updates

; core of the system. Usually this is a separate partition usually using a > > long term storage file system like BtrFS, ZFS, JFS, ReiserFS, etc. > > > > Now this may not be 100% accurate but it is a rough estimate of what these > > were purposed for. > > > >

Re: [Dng] [dng] vdev status updates

Le 30/04/2015 01:27, Joerg Reisenweber a écrit : On Wed 29 April 2015 23:46:51 Didier Kryn wrote: >They decided to put them on the second disk which contained user data >and was therefore mounted at /usr AFAIK that's "Unix System Resources" or somesuch, not "User" Maybe it's true, but it s

Re: [Dng] [dng] vdev status updates

use a separated /usr partition. -Jim > From: dr.kl...@gmx.at > To: dng@lists.dyne.org > Date: Thu, 30 Apr 2015 10:12:30 +0200 > Subject: Re: [Dng] [dng] vdev status updates > > From the FreeBSD point of view: > > https://www.freebsd.org/doc/en/books/handbook/dirstructu

Re: [Dng] [dng] vdev status updates

it is a rough estimate of what these were purposed for. I could be wrong... but I have been wrong from time to time. -Jim > Date: Thu, 30 Apr 2015 08:48:10 +0100 > From: kato...@freaknet.org > To: reisenwe...@web.de > CC: dng@lists.dyne.org > Subject: Re: [Dng] [dng] vdev statu

Re: [Dng] [dng] vdev status updates

his may not be 100% accurate but it is a rough estimate of what these > were purposed for. > > I could be wrong... but I have been wrong from time to time. > > -Jim > > > Date: Thu, 30 Apr 2015 08:48:10 +0100 > > From: kato...@freaknet.org > > To: reisenwe...

Re: [Dng] [dng] vdev status updates

On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote: > On Wed 29 April 2015 23:46:51 Didier Kryn wrote: > > They decided to put them on the second disk which contained user data > > and was therefore mounted at /usr > AFAIK that's "Unix System Resources" or somesuch, not "User" > /j

Re: [Dng] [dng] vdev status updates

On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote: > Hi Isaac, > > [Snip] > > > > > Theoretically, it *should* work if /etc/{passwd,group} are present in the > > initramfs, with those paths. It's possible to mistakenly copy them to / > > instead of /etc, but I assume that you've already

Re: [Dng] [dng] vdev status updates

On Wed 29 April 2015 23:46:51 Didier Kryn wrote: > They decided to put them on the second disk which contained user data > and was therefore mounted at /usr AFAIK that's "Unix System Resources" or somesuch, not "User" /j signature.asc Description: This is a digitally signed message part.

Re: [Dng] [dng] vdev status updates

Le 29/04/2015 23:54, Jude Nelson a écrit : On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn > wrote: Le 29/04/2015 22:34, Hendrik Boom a écrit : On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote: I'm under the impression you can do most

Re: [Dng] [dng] vdev status updates

On Wed, Apr 29, 2015 at 5:46 PM, Didier Kryn wrote: > > > Le 29/04/2015 22:34, Hendrik Boom a écrit : > >> On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote: >> >>> I'm under the impression you can do most or all of what needs to be >>> done in the actual init, rather than the initramfs.

Re: [Dng] [dng] vdev status updates

Le 29/04/2015 22:34, Hendrik Boom a écrit : On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote: I'm under the impression you can do most or all of what needs to be done in the actual init, rather than the initramfs. This gets a little complicated now that Linux has been "improved" by h

Re: [Dng] [dng] vdev status updates

Le 29/04/2015 19:07, Steve Litt a écrit : On Wed, 29 Apr 2015 18:13:04 +0200 Didier Kryn wrote: Le 29/04/2015 16:47, Steve Litt a écrit : maybe then we could eliminate the initramfs step entirely.:-) Sure that would be nice. It's something you can do for each machine, but is not p

Re: [Dng] [dng] vdev status updates

On Wed, Apr 29, 2015 at 10:47:27AM -0400, Steve Litt wrote: > > I'm under the impression you can do most or all of what needs to be > done in the actual init, rather than the initramfs. This gets a little > complicated now that Linux has been "improved" by having /sbin > and /bin be symlinks to /u

Re: [Dng] [dng] vdev status updates

On Wed, 29 Apr 2015 18:13:04 +0200 Didier Kryn wrote: > > > Le 29/04/2015 16:47, Steve Litt a écrit : > > maybe then we could eliminate the initramfs step entirely.:-) > > Sure that would be nice. It's something you can do for each > machine, but is not practical for a distro intended

Re: [Dng] [dng] vdev status updates

Le 29/04/2015 16:47, Steve Litt a écrit : maybe then we could eliminate the initramfs step entirely.:-) Sure that would be nice. It's something you can do for each machine, but is not practical for a distro intended for all. Some drivers, notably disk, raid, lvm, are necessary to moun

Re: [Dng] [dng] vdev status updates

On Tue, 28 Apr 2015 20:03:02 -0400 Jude Nelson wrote: > * Packaging. I'm working on a way to automatically build a .deb for > vdevd that will, among other things, safely generate and install an > initramfs without having to hack the initramfs tools (as is the case > today). Please see [Help Wa

Re: [Dng] [dng] vdev status updates

On 29/04/15 02:03, Jude Nelson wrote: Hey everyone, Sorry for being incommunicado these past two weeks--I was working on a conference paper that was due last Friday. Thank you all for being patient! I have the latest news for vdev: [Status updates] * Support for booting from LVM2 volumes

Re: [Dng] [dng] vdev status updates

Phone From: Jude Nelson<mailto:jud...@gmail.com> Sent: ‎4/‎28/‎2015 9:34 PM To: Isaac Dunham<mailto:ibid...@gmail.com> Cc: dng@lists.dyne.org<mailto:dng@lists.dyne.org> Subject: Re: [Dng] [dng] vdev status updates Hi Isaac, [Snip] > > Theoretically, it *should* wo

Re: [Dng] [dng] vdev status updates

Hi Isaac, [Snip] > > Theoretically, it *should* work if /etc/{passwd,group} are present in the > initramfs, with those paths. It's possible to mistakenly copy them to / > instead of /etc, but I assume that you've already checked that. > > Detail that shouldn't make a difference but might: > stati

Re: [Dng] [dng] vdev status updates

On Tue, Apr 28, 2015 at 08:03:02PM -0400, Jude Nelson wrote: > [TODO] > > * I still need to figure out how to generate /dev/disk/by-partuuid and > /dev/v4l/by-path, and possibly others. /dev/disk/by-partuuid does not exist on my udev-based Jessie install. It would presumably be the PARTUUID="..."

[Dng] [dng] vdev status updates

Hey everyone, Sorry for being incommunicado these past two weeks--I was working on a conference paper that was due last Friday. Thank you all for being patient! I have the latest news for vdev: [Status updates] * Support for booting from LVM2 volumes has been added. vdevd will create all /dev

Re: [Dng] vdev status updates

* On 2015 18 Mar 10:40 -0500, Joerg Reisenweber wrote: > Sounds all very clean and nice. > Kudos to Jude! Looking forward to using vdev* eventually Seconded. Thanks for your work the past several weeks, Jude. Good to have you aboard. - Nate -- "The optimist proclaims that we live in the best

Re: [Dng] vdev status updates

Le 18/03/2015 16:37, Joerg Reisenweber a écrit : Sounds all very clean and nice. Kudos to Jude! Looking forward to using vdev* eventually /j +1 :-)Didier On Wed 18 March 2015 10:43:06 Jude Nelson wrote: Hi Didier, It's very good to use inotify, because it's a standard Linux too

Re: [Dng] vdev status updates

Sounds all very clean and nice. Kudos to Jude! Looking forward to using vdev* eventually /j On Wed 18 March 2015 10:43:06 Jude Nelson wrote: > Hi Didier, > > > It's very good to use inotify, because it's a standard Linux tool (don't > > know for other nixes), not yet-another-interface. This wa

Re: [Dng] vdev status updates

Hi Didier, > It's very good to use inotify, because it's a standard Linux tool (don't know for other nixes), not yet-another-interface. This way DEs shouldn't have any concern implementing it. That's the plan :) Like udisks2, NetworkManager, and upower, vdevd-user (or something like it) offer DE

Re: [Dng] vdev status updates

It's very good to use inotify, because it's a standard Linux tool (don't know for other nixes), not yet-another-interface. This way DEs shouldn't have any concern implementing it. This means you will provide support for inotify in vdevfs? AFAIK there isn't in every filesystem, eg sysfs

Re: [Dng] vdev status updates

Hi Steve, > Several months ago I did a proof of concept shellscript using > inotifywait, which detected USB thumb drive insertion and removal. It > worked just fine, and if I'd wanted to spend more than 30 minutes, a > combination of tweaking sudoers and writing a few shellscripts could > have giv

Re: [Dng] vdev status updates

> Wow, thank you! You put a lot of work into this. You're welcome! > I am really considering using Devuan with vdev on my server VM. > > I like the approach to let one tool do one thing and do it well and even > more flexible than the current main stream implementations. I'm glad to hear it! If

Re: [Dng] vdev status updates

On Tue, 17 Mar 2015 04:48:46 -0400 Jude Nelson wrote: > > How would that "watching" work? > > vdevd-user would have an inotify(2)-based back-end (hopefully via > libkqueue, so it would be portable). The back-end would set up > inotify watches on /dev and its descendant directories, and translat

Re: [Dng] vdev status updates

Am Dienstag, 17. März 2015, 01:20:43 schrieb Jude Nelson: > Hey everyone, Hi Jude! > I have the latest news on vdev over the past two weeks. I'm not sure if > the news from last week made it to the mailing list; apologies if the > latter half of this email is redundant. > > [Week of March 15] >

Re: [Dng] vdev status updates

> How would that "watching" work? vdevd-user would have an inotify(2)-based back-end (hopefully via libkqueue, so it would be portable). The back-end would set up inotify watches on /dev and its descendant directories, and translate creat(2) and unlink(2) events from inotify into a vdev-specific

Re: [Dng] vdev status updates

On Tue 17 March 2015 01:20:43 Jude Nelson wrote: > What I'm considering doing is creating vdevd-user, a build of > vdevd with a backend for watching the contents of /dev, instead of > listening to the kernel for device events. How would that "watching" work? /jOERG signature.asc Description: Thi

[Dng] vdev status updates

Hey everyone, I have the latest news on vdev over the past two weeks. I'm not sure if the news from last week made it to the mailing list; apologies if the latter half of this email is redundant. [Week of March 15] This week, the Linux port of vdev is now accesses /sys in a manner that is fully