*WORKED AROUND* Add /proc/bus/usb inside VE ?
Howdy ! First lot of thanks for OpenVZ : it really rocks ! To make it short, my question is : is there a way so one can add "/proc/bus/usb" to a VE ? Such things as SANE (for scanners) seem to require this "proc" entry so they can work... and I cannot add this one through the ".mount" script for the concerned VE, as the documentation suggests "/proc" is not yed avalaible when it is executed. Using now OpenVZ on Debian Lenny, with official packages from there (kernel "linux-image-2.6.26-1-openvz-686-8" and "vzctl-3.0.22-11"), I am testing OpenVZ, while sill using my "old" Etch VServer... On this latter, I have no problem adding "/proc/bus/usb" in a container, through an entry in "/etc/vservers/${NAME}/fstab" such as "none /proc/bus/usb usbfs defaults 0 0"... which has yet proven useful several times on my server (along with SYS_RAWIO capability) : - I have an USB printer that did not show under "/dev/usb/lpX" but required access to /proc/bus/usb (with Lenny, it now works with "/dev/usb/lpX" anyway, so this is good with OpenVZ, now) ; - it makes "lsusb" work ; - my scanner requires access to "/proc/bus/usb"; - some people have printer/scanner combo devices which are rendered half-useful without "/proc/bus/usb" access Well, I am aware this is not as clean as making a simple device node under "/dev/usb" accessible (which works right), but there are cases where this simply is not enough... So, is there a way to do this ?
Well, my bad... it can work by giving the container acces to the nodes in "/dev/bus/usb/"... ... which in turn also enables lsusb to work properly (it will show what has been given to the VE, and nothing else). I guess I will now create some udev rule on HN to create a "/dev/usb/scanner" or something like that, as none is created on my machine, to make it easier to share with the VE. So, "saned" now works and is able to scan in my VE (even the loading of the binary firmware onto the scanner works as it should... with one of my printers, only unmasking "/dev/usb/lp0", I was forced to have hpijs on the HN, without CUPS, so "udev" rules could load another firmware in my Laserjet 1018) : excellent. If others wanted to try this out right now, be aware though that a bug in Debian's "libsane-extras", mandatory dependency of "libsane" in this distro, has just been corrected, for the amd64 package. The package for i386 architecture is not here yet, though, and has "udev" as a mandatory dependency (which was the bug... as "libsane", for itself, doesn't need anything else than "makedev")... ... and OpenVZ containers really do not like "udev" (Lenny containers will not even manage to install this one without tweaking the package postinst scripts). While I am at it : "libsane-extras" Debian maintainer told me that the next release after Lenny (Squeeze) will get rid of makedev, making the use of "udev" mandatory for this kind of things (this is why he did not seem convinced taking care of "udev" older alternatives was a good idea)... are there some kind of future plans, in OpenVZ to manage "udev" in a way or another ?
or use a desktop distro like ubuntu or fedora
What would/should/could this change ? Were it something technical I missed, tell me : I really wonder. If it were a troll, I sincerely could not care less... I would neither use any of the two distributions you mention (for various reasons), but discussing this here does not seem the right place to me... and hence, I will not. Edit : hummm... you meant to reply this one, didn't you ?
i simply thought that if you needed a USB printer attached that is was a desktop CT and a desktop distro would provide better USB support
Re: *WORKED AROUND* Add /proc/bus/usb inside VE ?
Well nope : for the printers, both run in their own dedicated VE, with a headless CUPS for each (I do this on purpose : only the drivers of respective interest are installed on each one, so I can hack on one CUPS, without wreaking havocs in the other, and still have a lightweight ensemble)... and it goes the same way for the scanner, with a headless sane/scanbuttond/lpr combo. All of this used to run within the same VE, when I was using VServer, and I used to simply share "/proc/bus/usb" to access the hardware. But this can be done through sharing "/dev/bus/usb" as well, and an even better solution could be to add a custom udev rule on the HN that makes /dev/usbscanner0 appear (or such thing : I think I will tweak udev to make a symlink inside "/dev/containers_dev/", with indisputable name, eg scanner_1670, for an Epson Perfection 1670, and such, to be sure the right device is picked up). To be fair, one of the reasons I do not use desktop-distro is that I have the feeling I am lost with those : so many things are installed by default that I never know which things I am reasonably in control of, and which I am not. As for the rest, ie a couple (two is a classic couple) of unredistributable binary firmwares (laser printer and scanner) is the most that I need, and, I guess, the most that a desktop distro could eventually (and not even necessarily) bring me : for the rest, Debian should not have such a different support in USB materials than any other distro, IMHO (well, I am already now using the next stable, aka Lenny... it will grow older in a couple of years, when I'll probably be waiting for its successor Squeeze, but for now, it is shiny new, not even released yet as stable, to be exact, and in the league with the pack for "bleeding edgeness"). The only annoyance I must deal with is the problems inherent to the use of udev in a container (needed, for instance, to load the firmware of my laser printer... well, this can be done on the HN, where udev works right) - I am still quite reluctant with it, as I have known the painful era when it was just an all-but-ready outsider (not that pure static /dev was not painful either)... as far as I understood, its use in the VE is unadvisable no matter which distro one uses (I came across those recommandations in Gentoo's documentation as well, for instance ; and in a couple of others), which is another problem, as makedev support and such things may tend to disappear in a few years from now ; which was the thing I was wondering about in the end of my second post (Lenny will surely still be supported in at least something like 3 years from now, but I already wonder how I will manage things if udev is to become a mandatory dependency, without alternatives, for things I put in containers ; better to be worried much too early, than much too late). Sorry if I may have been a bit rough, in my previous answer - I really should sleep more, these times. I hope you'll better undestand my way of viewing things, with those details.
no worries dude i am just hanging in the forum waiting for a help on my question and while i am here picking up the topics which have a low activity i was throwing out a glib solution so that if you really did get stuck then you could break out with an experiment you have the benefit of OpenVZ right. it is an astonishing tool for multiple independent systems. i have a development group and they have as many test servers as they need. once they are done with a test i destroy that CT and clone another from a template i created and off they go again udev was a problem for CentOS 4 but they solved it with CentOS 5. i see udev break once a month in one of the CT with CentOS 4 in the CT. the problem always comes after an update. the fix is to makedev the CT from the HN then hard write the pty and tty into the udev config in the CT. it will then keep it between reboots not yet seen a udev problem in a CentOS 5 CT
OK, good to now. This should go smooth for Lenny (as long one is not using udev, which is still avoidable, generally having at least a double dependency to makedev and udev... though, hopefully not, to hotplug anymore)... ... but I am already investigating what could be changed, to give Debian's udev maintainer as much clues as possible for not breaking it in containers, in a relatively distant future. For now, it seems writing to /proc/sys/kernel/hotplug is not a good idea, as well as starting to populate udev from something in /tmp which also brings up problems (for what I tweaked in Debian's udev postinstall script). Did you have to set a particular kernel capacity, in order for it to work in CentOS ? I heard it may need sysfs or such things, but as I cannot (and do not really want to, for now) manage to make it work, anyway...
have you seen this? http://wiki.openvz.org/Container_enter_failed i edited the node file but he also has a method with udev disabled
With udev disabled (I build my containers with debootstrap, which does not require udev installation : makedev is brought up, and it is really enough), I have no problems at all. Troubles just come when I install the udev package inside a VE, which fails, because the install scripts try to do things that are prohibited in this kind of restricted environment... Well, I guess I will see with Debian udev's maintainer, to see what he could do. OpenVZ officially supported in Debian is very young (to be true, it only starts with Lenny for binary packages, and Lenny will probably not be released as stable until begining of 2009... before, juste a source-patchset for the kernel was supported... so I guess a little bit of time should be given - they did a real good job for VServer, which has been in Debian for much longer : they even brought up custom tools specially designed for Debian, so...).
my days at the bleeding edge of operating systems are way way behind me. never again i want stuff to work out of the box and not break when there is an update
Do not hear me wrong though : OpenVZ, in Debian Lenny, aka next Stable (already frozen, so 99% stable, I'd say... and really very reliable yet), is very usable ; plus it is gonna be labeled as "Stable" and be supported for something like three years from now on (as I am under Sid, quite bleeding-edge, on the desktop, my servers always run a Debian Stable, or frozen Testing)... Three things still bother me : - not being able to set owners/permissions in the "devnodes" stanza from the HN (mainstream problem, I guess, and only annoying for hotplugable devices - worked around with udev script triggering on the HN and init scripts in the VN, though) ; - no VZ quotas in bind-mounts (mainstream as well - worked around with good ol' partitions on the HN) ; - udev anoyances (not that I am convinced udev should be in a VE, but "old" makedev and such is vowed to disappear in some more or less distant future... so - worked around convincing package maintainers to still support makedev for now) ; There is still a 2.6.26 kernel which oopses on heavy network load, in Lenny, but the fix (backported from 2.6.27 - seems it was Linux Vanilla's fault) has been in Sid for a week, and should integrate Lenny in a few days. ... and, while I am at it, OpenVZ in itself is quite bleeding-edge technology... containers are bound to be integrated in mainstream Linux, without VServer or OpenVZ external patches, or with the least, one day or another... huge OpenVZ contributions to mainstream tend to show it. As for things working out of the boxes, I tend to think about it as mirages