Erich Schubert wrote: >Hi, > > >>You can use /dev, which means it's accessable from very early in the >>boot, initng does this and it works well. Also, are we sure this needs >>a writable filesystem? I think if the socket exists it might not, I >>can't really remember ;) >> >> > >That only works with FIFOs IIRC - sockets will disappear when closed, >so they only live for the runtime of the program. I don't know if >they'll actually get a node on the disk. >Where I'm skeptical with /dev is with static/udev/devfs. >You would need to ensure that the fifos "survive" the udev mounting. >For FIFOs I'd suggest the location /lib/debinit/fifoo >Since /lib also needs to be accessible early on, and the fifo is >somewhat static. > > > >>I have a bit of experience here, as initng has been trying out a few >>here, fifo's were horrible and unix sockets worked very well, and we can >>solve issues here either with initramfs on boot or by waiting until /dev >>is mounted (which by initng is after the first script is launched). >> >> > >Hmm... kind of a hack to require the first script to make /dev >writeable... but that sure would be a way we could take. Then we could >use socket semantics. >I've worked with fifos - on minit - and they were okay, the biggest >issue is that they occasionally are locked (so you need to retry) and >that you can't use them for having a monitor (e.g. the dbus >connector). We sure could use sockets for the dbus connector later on. >Can anyone comment on the following: "Connecting to the > socket object requires read/write permission. This behavior differs > from many BSD-derived systems which ignore permissions for Unix sock- > ets. Portable programs should not rely on this feature for security." >And wheter we can work around that by placing the sockets into a >restricted directory? > > You can, just make sure the directory has the right permissions and it's not a problem.
> > >>How much do we want to support remotly though? Do we want a plugin api >>or a comunication api? I imagine a comunication api would end up being >>considerably more advanced and a lot harder to implement, but that could >>be because I'm used to working with plugins ;) >> >> > >I'm not sure about that. If we keep the messages to a minimum, it's >just about writing some structs to a fd. Not really difficult. > >I'd like to have a statically linked init, since on a platform I'm >working on there is no dynamic linking available. > >Also I think we are going to need this anyway, because I do not want >the dbus connector to be in init itself. > > How would you handle stuff like suid/nice/chroot/chdir/optional "extra" stuff that can't really be done remotly? Put all of it in defines in the core? >best regards, >Erich Schubert >-- > erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_ > To understand recursion you first need to understand recursion. //\ > Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ > eine Stunde wie eine Heimat aus. --- Herrmann Hesse > >_______________________________________________ >initscripts-ng-devel mailing list >[email protected] >http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel > > > _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
