Re: [DNG] vdev - scanner
On 02/09/16 23:39, Ralph Ronnquist wrote:
Dave Turner wrote on 02/09/16 20:12:
On 02/09/16 01:38, Ralph Ronnquist wrote:
Ralph Ronnquist wrote on 01/09/16 08:51:
My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners.
Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...
I'm a little bit at a loss here, as I can't find anything in the vdev
tree dealing with, say, scanners or, say, mode switching USB devices.
Since those are major chunks in udev rules, I'm just confused. Have I
misunderstood?
I find "scanner" mentioned in the hwdb, but there is no formal
classification of those other than identifying as usb (or pci);
nothing classifying them as scanners (unless you'd regard the model
label as such). I wish someone could explain things for me...
Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
I loathe the 'feature' of udev that forces you to create or modify
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted
Android Device get through udev security. And now it seems that vdev is
about to force the same thing. I know it isn't easy to completely
re-think how things should be done, do OSX and the BSDs have a different
and better way of doing this sort of thing?
I want to ask you why a database of $V/$P/$N mappings is needed. It is
my laptop and my cheap Android tablet and I want to plug it into the USB
socket and have them play nicely together. God knows what I would have
done if I was just a normal ordinary person. I would have concluded that
linux was shit and gone back to my Mac or Windoze.
dmesg knew all about my android tablet when I plugged it in, why can't
vdev pick it up from there?
this is what I had to add into 51-android having had a look at dmesg
first.
#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"
I suppose the issue is to make sure that the right user have the right
access to the right devices when she wants to use the computer, whilst
making sure that the wrong user doesn't have the wrong access
regardless of what he wants to do.
Traditionally on Linux, the means to achieve this would be to use file
permissions. Then more recently, the notion of access control lists
was invented to offer a more dynamic access control. And then even
more recently "people" have decided that this is an insanely hard
problem, which requires an insane solution.
Given the scope of possible use cases, perhaps the permission handling
should be taken elsewhere, and make the hotplug handler only deal with
ensuring the device is functional and available to the permission
handling sub system. Maybe even the latter could be PAM (although I
don't know if PAM can make device access be allowed rather than just
judging whether or not it is allowed).
Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
So, what if some daemon or other knows I have plugged in my Android
device and brings up a window telling me to click here to access my
Android device or Cancel? The daemon then does the necessary things and
it Just Works.
(managed to hit Reply List 1st time!)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Raspberry Pi 2 and other ARM based credit card computers
On Thu, 01 Sep 2016 16:47:23 +0200 shraptor wrote: > I want to ask florian here why he disables IPv6 by blacklisting the > IPv6 kernel module? Hallo Shraptor, I have an ip4 uplink and don't need ip6 atm, so I disable it (on all my machines in the LAN). I call this "minimalism" ;) Blacklisting the kernel module is IMHO the easiest and besides setting the kernel parameter in /etc/default/grub the only reliable way: IIRC, disabling it in sysctl.conf disabled ip6 but didn't survive a reboot without explicitly running 'sysctl -p' again, e.g. from /etc/rc.local. > any security considerations? Definitely. I read quite thoroughly into the ip6 standard and found that there's /a lot/ of complexity in it and its implementation. As long as I don't need it, I wait for the dust to settle and at least /some/ hidden bugs and other creepers to appear... Libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] If not TruOS, maybe Illumian?
Steve Litt, since you liked playing with PC-BSD before it suddenly took a left turn into TruOS, maybe you would consider Illumian? It's IllumOS (ex-Solaris) with Debian packaging -- successor to the short-lived but promising Nexenta project. (I was a little more enthusiastic about Nexenta, as that was the entire GNU userspace atop the then-ex-Solaris kernel, but this is still worthy of respect.) See Bryan Cantrill's LISA conference slide at https://www.youtube.com/watch?v=-zRN7XLCRhc&t=59m36s Actually, the whole LISA talk is engaging (especially if you don't yet have enough reasons to distrust Oracle Corporation). On that latter note, also, viva LibreOffice! ASF, give it up with Open Office, already! http://linuxmafia.com/pipermail/conspire/2016-September/008550.html http://linuxmafia.com/pipermail/conspire/2016-September/008551.html Illumian is here: http://illumian.org/ (Yeah, they're not much for marketing.) I gather that they're not yet a mature project, and don't expect anything even remotely approaching a desktop distribution at this early stage. I'm just saying, if you're considering BSD-based builds, you should certainly consider IllumOS-based ones, too. Among other things, you get top-notch implementations of ZFS, dtrace, and zones for free. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] If not TruOS, maybe Illumian?
On Sat, Sep 03, 2016 at 10:58:05AM -0700, Rick Moen wrote: > Steve Litt, since you liked playing with PC-BSD before it suddenly took > a left turn into TruOS, maybe you would consider Illumian? It's > IllumOS (ex-Solaris) with Debian packaging -- successor to the > short-lived but promising Nexenta project. (I was a little more > enthusiastic about Nexenta, as that was the entire GNU userspace atop > the then-ex-Solaris kernel, but this is still worthy of respect.) How does it compare with Dyson? That one looks at least somewhat alive, and I make at least token effort to port/test stuff I mess with on Dyson. (I'm not involved with them in any way beside making another checkmark on my archs list.) -- Second "wet cat laying down on a powered on box-less SoC on the desk" close shave in a week. Protect your ARMs, folks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] If not TruOS, maybe Illumian?
Quoting Adam Borowski (kilob...@angband.pl): > How does it compare with Dyson? Sorry, no experience. You'd have to check it for yourself and see. -- Cheers,"Why struggle to open a door between us, Rick Moen when the whole wall is an illusion?" r...@linuxmafia.com -- Rumi McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] ifupdown, udev, libudev1 and systemd
Warning: upgrading Devuan jessie brings in a new version of ifupdown entangled with Systemd. Here is the message: --- beginning of message -- ifupdown (0.8.1) unstable; urgency=medium The /etc/default/networking file is now read even when systemd is used, although its use is not recommended. -- Guus Sliepen Wed, 02 Dec 2015 23:25:41 +0100 ifupdown (0.8) unstable; urgency=medium Ifupdown now comes with a systemd service file. Any options specified in /etc/default/networking will no longer be used. If you are using CONFIGURE_INTERFACES=no, then run "systemctl disable networking" instead. If you are using EXCLUDE_INTERFACES, then edit /etc/network/interfaces and remove those interfaces from any "auto" keywords. Ifupdown will now be more strict when errors occur, and will also properly return a non-zero exit code when (de)configuring an interface fails. Please ensure your /etc/network/interfaces is correct and that your interfaces can be brought up and down without errors, especially during system startup. Ifupdown now has more fine-grained locking, allowing concurrent calls of ifup and ifdown. It is also allowed to call ifup and ifdown from a (pre-)up or (post-)down line from /etc/network/interfaces, as long as no recursion occurs. You can now use the "inherits" keyword to copy settings from another interface stanza. RFC 4361 DDNS support is now enabled by default for inet dhcp interfaces if isc-dhcp-client is installed. -- Guus Sliepen Sun, 22 Nov 2015 21:19:44 +0100 systemd (220-7) unstable; urgency=medium * The mechanism for providing stable network interface names changed. Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules which mapped device MAC addresses to the (arbitrary) name they got when they first appeared (i. e. mostly at the time of installation). As this had several problems and is not supported any more, this is deprecated in favor of the "net.ifnames" mechanism. With this most of your network interfaces will get location-based names. If you have ifupdown, firewall, or other configuration that relies on the old names, you need to update these by Debian 10/Ubuntu 18.04 LTS, and then remove /etc/udev/rules.d/70-persistent-net.rules. Please see /usr/share/doc/udev/README.Debian.gz for details about this. -- Martin Pitt Mon, 15 Jun 2015 15:30:29 +0200 - end of message - The following packages interdepend with ifupdown: udev, libudev1. I had to lock the version of all three. I was alarmed by the message but don't know if upgrading these 3 packages is really harmfull. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ifupdown, udev, libudev1 and systemd
On Sat, 03 Sep 2016, Didier Kryn wrote: > Warning: upgrading Devuan jessie brings in a new version of ifupdown > entangled with Systemd. I'm not sure what is the coincidence, but a new "ifupdown-devel" mailinglist appeared right in August. http://lists.alioth.debian.org/pipermail/ifupdown-devel/ If you or someone else has time, would be good to briefly articulate our concerns and ask if its possible to: > --- beginning of message -- > ifupdown (0.8.1) unstable; urgency=medium > > The /etc/default/networking file is now read even when systemd is used, > although its use is not recommended. ^^ refrain from deprecating use of /etc/default/networking as this will affect an enormous amount of server installations. > Ifupdown will now be more strict when errors occur, and will also > properly return a non-zero exit code when (de)configuring an > interface fails. Please ensure your /etc/network/interfaces is > correct and that your interfaces can be brought up and down > without errors, especially during system startup. Ifupdown now > has more fine-grained locking, allowing concurrent calls of ifup > and ifdown. It is also allowed to call ifup and ifdown from a > (pre-)up or (post-)down line from /etc/network/interfaces, as long > as no recursion occurs. You can now use the "inherits" keyword to > copy settings from another interface stanza. RFC 4361 DDNS > support is now enabled by default for inet dhcp interfaces if > isc-dhcp-client is installed. preserve these changes as independent from systemd, as I believe they are. I also recommend avoiding any flame and if the tones of the conversation quickly become confrontational and bullish then just leave, we'll fork that package. Actually I'm already looking at possible forking strategies. The Git repository is https://anonscm.debian.org/cgit/collab-maint/ifupdown.git ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
