Re: user perms
On 12/8/23 12:11, David Wright wrote: On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: On 6/13/22 14:36, Greg Wooledge wrote: On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> I appear as user 1000 seem to be stuck behind some sort of a >> permissions wall. > > SHOW. US. I got tired of fighting with it Greg, so I did install #32 and installed gnome_desktop (that was new) and xfce4 during the install, and now things including the screen colors are back to normal, I've installed the brother printers and scanner drivers and I can modify t them by the usual rules. I also set a root pw in addition to adding myself to /etc/group in the appropriate places. ↑ On Thu 07 Dec 2023 at 20:49:19 (-0500), gene heskett wrote: On 12/7/23 20:24, Greg Wooledge wrote: On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote: Thats bug #1. Single for rescue demands a root pw. This isn't a bug. It's just how things *are*. People who choose not to set a root password are simply setting themselves up for this failure. It *will* happen eventually. I strongly recommend setting a root password on your systems. And you should either *use* it once in a while, so you don't forget what it is, or else make it the same as your regular account's password. So you don't forget what it is. If you *still* choose not to set a root password, then you will need to know how to get around the issue you ran into. You won't be able to use single-user mode to rescue your system, so you'll need other ways. There are two straightforward alternatives: boot from external media (USB or CD or DVD), or learn how to do the "init=/bin/bash" thing from your boot loader, which includes bind-mounting /proc and /dev and so on. . I've now set a root pw, about 34 chars, so they'll be a couple eons guessing it AND (horrors) have written it down. As you set a root password on at least one machine a year ago, can you just check that you now have a root password on all your machines, before we have threads like this for each machine, and Greg gets hoarse. Cheers, David. I have not set a root pw on any other wintel machines, they are all running buster because the newer python broke LinuxCNC till just recently. All my arms do have it set. They are all running a late summer armbian jammy w/xfce4. No video on the early fall versions. . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: user perms
On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: > On 6/13/22 14:36, Greg Wooledge wrote: > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> > > I appear as user 1000 seem to be stuck behind some sort of a >> > permissions wall. > > SHOW. US. > > I got tired of fighting with it Greg, so I did install #32 and installed > gnome_desktop (that was new) and xfce4 during the install, and > now things including the screen colors are back to normal, > > I've installed the brother printers and scanner drivers and I can modify t > them by the usual rules. I also set a root pw in addition to adding myself > to /etc/group in the appropriate places. ↑ On Thu 07 Dec 2023 at 20:49:19 (-0500), gene heskett wrote: > On 12/7/23 20:24, Greg Wooledge wrote: > > On Thu, Dec 07, 2023 at 08:06:52PM -0500, gene heskett wrote: > > > Thats bug #1. Single for rescue demands a root pw. > > > > This isn't a bug. It's just how things *are*. > > > > People who choose not to set a root password are simply setting themselves > > up for this failure. It *will* happen eventually. I strongly recommend > > setting a root password on your systems. And you should either *use* it > > once in a while, so you don't forget what it is, or else make it the same > > as your regular account's password. So you don't forget what it is. > > > > If you *still* choose not to set a root password, then you will need to > > know how to get around the issue you ran into. You won't be able to use > > single-user mode to rescue your system, so you'll need other ways. There > > are two straightforward alternatives: boot from external media (USB or CD > > or DVD), or learn how to do the "init=/bin/bash" thing from your boot > > loader, which includes bind-mounting /proc and /dev and so on. > > > > . > I've now set a root pw, about 34 chars, so they'll be a couple eons > guessing it AND (horrors) have written it down. As you set a root password on at least one machine a year ago, can you just check that you now have a root password on all your machines, before we have threads like this for each machine, and Greg gets hoarse. Cheers, David.
Re: TBird mail (was: user perms)
On 07/12/2022 15:02, gene heskett wrote: And when I find it. the prefs.js file does not contain any of the strings mentioned in the reply I quoted and everyone but you have clipped. Am I to add these below? According to the top of the file, t-bird must be stopped before editing as it saves this anew when stopping. That is why I suggested you to use built-in config editor. Doesn't your preferred search engine gives relevant result for "thunderbird config editor"? https://support.mozilla.org/en-US/kb/config-editor You may bypass looking up for the profile directory and change or create any options in Hamburger menu / Settings / Config Editor (at ---^^ the bottom of the page).
Re: TBird mail (was: user perms)
On 12/6/22 22:53, Max Nikulin wrote:
On 07/12/2022 06:58, gene heskett wrote:
profiledir:
what or where is this "profiledir:"? after sudo updatedb today, I find
Querying search engine "thunderbird profile directory" gives
https://support.mozilla.org/en-US/kb/profiles-where-thunderbird-stores-user-data
http://kb.mozillazine.org/Profile_folder_-_Thunderbird
How to find your profile
- Click on the menu button or menu bar.
- From the Help menu, click Troubleshooting Information.
- In the Application Basics section, Profile Directory, click on Open
Directory.
- The Files window will show the name of the profile as well as the path
to it.
And when I find it. the prefs.js file does not contain any of the
strings mentioned in the reply I quoted and everyone but you have clipped.
Am I to add these below? According to the top of the file, t-bird must
be stopped before editing as it saves this anew when stopping.
user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);
You may bypass looking up for the profile directory and change or create
any options in Hamburger menu / Settings / Config Editor (at the bottom
of the page).
Hamburger? does not exist.
Confusing...
.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page
Re: TBird mail (was: user perms)
On 07/12/2022 06:58, gene heskett wrote:
profiledir:
what or where is this "profiledir:"? after sudo updatedb today, I find
Querying search engine "thunderbird profile directory" gives
https://support.mozilla.org/en-US/kb/profiles-where-thunderbird-stores-user-data
http://kb.mozillazine.org/Profile_folder_-_Thunderbird
How to find your profile
- Click on the menu button or menu bar.
- From the Help menu, click Troubleshooting Information.
- In the Application Basics section, Profile Directory, click on Open
Directory.
- The Files window will show the name of the profile as well as the path
to it.
user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);
You may bypass looking up for the profile directory and change or create
any options in Hamburger menu / Settings / Config Editor (at the bottom
of the page).
Re: TBird mail (was: user perms)
On Tue, Dec 06, 2022 at 06:58:20PM -0500, gene heskett wrote: > gene@coyote:~$ locate prefs.js > /home/amanda/.mozilla/firefox/nz58vim6.default-esr/prefs.js > /home/gene/.local/share/digikam/QtWebEngine/Default/user_prefs.json > /home/gene/.local/share/kmail2/QtWebEngine/Default/user_prefs.json > /home/gene/.local/share/konqueror/QtWebEngine/Default/user_prefs.json > /home/gene/.local/share/plasmashell/QtWebEngine/Default/user_prefs.json > /home/gene/.local/share/thumbnail.so/QtWebEngine/Default/user_prefs.json > /home/gene/.moonchild productions/pale moon/1n4tfecn.default/prefs.js > /home/gene/.mozilla/firefox/cfkfrtdm.default-esr/prefs.js > /home/gene/.mozilla/firefox/f8j7d2lj.default-esr/prefs.js > /home/gene/.thunderbird/f37v8icg.default-default/chrome_debugger_profile/prefs.js > /home/gene/.thunderbird/f37v8icg.default-default/prefs.js > /home/gene/bin/firefox/defaults/pref/channel-prefs.js > /usr/lib/firefox-esr/defaults/pref/channel-prefs.js > /usr/share/thunderbird/defaults/pref/channel-prefs.js > > I count 8 prefs.js in the above list, so which one is actually being talked > about here? I count two in your home directory that refer to Thunderbird, one of which belongs to what looks like a profile you set up for debugging Chrome. By a very short process of elimination, that only leaves one prefs.js of interest. -- True to our past we work with an inherited, observed, and accepted vision of personal futility, and of the beauty of the world. -- David Mamet signature.asc Description: PGP signature
Re: TBird mail (was: user perms)
On 6/18/22 19:26, Chuck Zmudzinski wrote:
Going thru some old email and found I had tagged this message which
contains some unfinished business someone might clarify now:
On 6/15/22 7:14 AM, Felix Miata wrote:
gene heskett composed on 2022-06-15 06:34 (UTC-0400):
What the heck is this vertical bar it uses for a quote level
That's taken care of here with one or both of these two entries in prefs.js in
the
profiledir:
what or where is this "profiledir:"? after sudo updatedb today, I find this:
gene@coyote:~$ locate prefs.js
/home/amanda/.mozilla/firefox/nz58vim6.default-esr/prefs.js
/home/gene/.local/share/digikam/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/kmail2/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/konqueror/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/plasmashell/QtWebEngine/Default/user_prefs.json
/home/gene/.local/share/thumbnail.so/QtWebEngine/Default/user_prefs.json
/home/gene/.moonchild productions/pale moon/1n4tfecn.default/prefs.js
/home/gene/.mozilla/firefox/cfkfrtdm.default-esr/prefs.js
/home/gene/.mozilla/firefox/f8j7d2lj.default-esr/prefs.js
/home/gene/.thunderbird/f37v8icg.default-default/chrome_debugger_profile/prefs.js
/home/gene/.thunderbird/f37v8icg.default-default/prefs.js
/home/gene/bin/firefox/defaults/pref/channel-prefs.js
/usr/lib/firefox-esr/defaults/pref/channel-prefs.js
/usr/share/thunderbird/defaults/pref/channel-prefs.js
I count 8 prefs.js in the above list, so which one is actually being
talked about here?
user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);
I haven't noticed whether or not in GUI preferences if either has a counterpart.
I also use this setting to help get rid of the vertical bar:
user_pref("mailnews.send_plaintext_flowed", false);
and I take care to check Options-> Delivery Format is set to
no such option shows in my current copy here. Makes it kinda hard to check.
"Plain Text Only" before sending a message.
This is not "sticky" ? s/b :o(>
.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page
Re: user perms
On Fri 17 Jun 2022 at 18:14:41 (-0400), gene heskett wrote: > On 6/17/22 16:29, Anssi Saari wrote: > > gene heskett writes: > > > > > I just did all that, so now I have an /etc/rc.local but not an rc-local > > > but he changes from rc.local to rc-local in the middle. confusing. > > > > > > So which is it. I originally created an rc.local, changed it to > > > rc-local, and back with mv. > > The script file is /etc/rc.local but the systemd service name is > > rc-local. > > > > > Now, I'm not aware of who heyu runs as, probably gene since I'm the > > > one running it and there is no user heyu. > > > > > > Now, 2 new questions: > > > > > > So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0, > > > which has the cm11a on the other side of an fdti adaptor? > > Since you seem to have the expected permissions for /dev/ttyUSB0 and > > /dev/ttyUSB1 maybe you could just add gene and nut users to the dialout > > group? adduser gene dialout and adduser nut dialout. > > > > But if you really want to use rc.local then setting the group to nut > > for the UPS line /dev/ttyUSB1 would work, so just > > > > chgrp nut /dev/ttyUSB1 > > > > And then chgrp gene /dev/ttyUSB0 > > > > Hope it helps! > Absolutely the magic twanger Anssi. I put it all in rc.local, or in > /etc/group > then ran rc.local for S, checked the devices were changed, restarted > nut-server and nut-client, works as expected, then ran "heyu info" as me > and got the expected response. > > Finally, someone was not afraid to answer my questions. I missed seeing the answer to your first question, at the beginning of the month, where you asked how to determine which way round the ttyUSBs have been assigned at boot.¹ I've only seen your reports of unplugging and replugging the connections each time. I'm afraid that's the question I was interested in answering by means of the example I gave. Until you know which is which, you can't reliably assign the port to TTY in nut (which should set the ownerships itself, shouldn't it?). I don't know about those for heyu as it's not in Debian at present. ¹ "As a furinstance, I used to be able to cat a /dev/ttyUSB*, which made self indentifying which was which easy, cuz if you unplug a cm11a, it will send … … …". Cheers, David.
Re: TBird mail (was: user perms)
On 6/15/22 7:14 AM, Felix Miata wrote:
> gene heskett composed on 2022-06-15 06:34 (UTC-0400):
>
> > What the heck is this vertical bar it uses for a quote level
>
> That's taken care of here with one or both of these two entries in prefs.js
> in the
> profiledir:
>
> user_pref("mail.quoteasblock", false);
> user_pref("mail.quoted_graphical", false);
>
> I haven't noticed whether or not in GUI preferences if either has a
> counterpart.
I also use this setting to help get rid of the vertical bar:
user_pref("mailnews.send_plaintext_flowed", false);
and I take care to check Options-> Delivery Format is set to
"Plain Text Only" before sending a message.
Re: user perms
On 6/17/22 16:29, Anssi Saari wrote: gene heskett writes: I just did all that, so now I have an /etc/rc.local but not an rc-local but he changes from rc.local to rc-local in the middle. confusing. So which is it. I originally created an rc.local, changed it to rc-local, and back with mv. The script file is /etc/rc.local but the systemd service name is rc-local. Now, I'm not aware of who heyu runs as, probably gene since I'm the one running it and there is no user heyu. Now, 2 new questions: So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0, which has the cm11a on the other side of an fdti adaptor? Since you seem to have the expected permissions for /dev/ttyUSB0 and /dev/ttyUSB1 maybe you could just add gene and nut users to the dialout group? adduser gene dialout and adduser nut dialout. But if you really want to use rc.local then setting the group to nut for the UPS line /dev/ttyUSB1 would work, so just chgrp nut /dev/ttyUSB1 And then chgrp gene /dev/ttyUSB0 Hope it helps! Absolutely the magic twanger Anssi. I put it all in rc.local, or in /etc/group then ran rc.local for S, checked the devices were changed, restarted nut-server and nut-client, works as expected, then ran "heyu info" as me and got the expected response. Finally, someone was not afraid to answer my questions. Thank you Anssi, take care and stay well. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: user perms
gene heskett writes: > I just did all that, so now I have an /etc/rc.local but not an rc-local > but he changes from rc.local to rc-local in the middle. confusing. > > So which is it. I originally created an rc.local, changed it to > rc-local, and back with mv. The script file is /etc/rc.local but the systemd service name is rc-local. > Now, I'm not aware of who heyu runs as, probably gene since I'm the > one running it and there is no user heyu. > > Now, 2 new questions: > > So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0, > which has the cm11a on the other side of an fdti adaptor? Since you seem to have the expected permissions for /dev/ttyUSB0 and /dev/ttyUSB1 maybe you could just add gene and nut users to the dialout group? adduser gene dialout and adduser nut dialout. But if you really want to use rc.local then setting the group to nut for the UPS line /dev/ttyUSB1 would work, so just chgrp nut /dev/ttyUSB1 And then chgrp gene /dev/ttyUSB0 Hope it helps!
Re: user perms
On Thu 16 Jun 2022 at 12:22:48 (+0300), Anssi Saari wrote:
> David Wright writes:
>
> > As it happens, I find I have (but don't use):
>
> > $ grep -i ttyusb /lib/udev/rules.d/*
>
> I actually found this in 50-udev-default.rules:
>
> KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
> GROUP="dialout"
>
> So that should set the group for ttySx and ttyUSBx also to dialout and
> in fact I see exactly that happening in my Debian 11 router which has
> devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4:
>
> $ ls -l /dev/ttyUSB* /dev/ttyS*
> crw-rw 1 root dialout 4, 64 Jun 13 12:12 /dev/ttyS0
> crw-rw 1 root dialout 4, 65 Jun 13 12:12 /dev/ttyS1
> crw-rw 1 root dialout 4, 66 Jun 13 12:12 /dev/ttyS2
> crw-rw 1 root dialout 4, 67 Jun 13 12:12 /dev/ttyS3
> crw-rw 1 root dialout 188, 0 Jun 13 12:12 /dev/ttyUSB0
> crw-rw 1 root dialout 188, 1 Jun 13 12:12 /dev/ttyUSB1
> crw-rw 1 root dialout 188, 2 Jun 13 12:12 /dev/ttyUSB2
> crw-rw 1 root dialout 188, 3 Jun 13 12:12 /dev/ttyUSB3
> crw-rw 1 root dialout 188, 4 Jun 13 12:12 /dev/ttyUSB4
>
> I didn't find a rule which sets the perms for these to 0660 but
> something does that for me.
>
> This rule comes with the udev package itself so it should be always
> installed in a Debian installation.
>
> Still, it seems for Gene these are overwritten somehow but I don't know
> why or how. I have exactly one USB-to-serial cable I can try to plug in
> and see what happens. However it's a CP210x and I think Gene's stuff is
> FTDI.
I don't have any of these devices, so the closest I can manage is a
mouse that keeps disconnecting and reconnecting every few minutes,
which means it loses its acceleration settings.
I've run
$ udevadm monitor -k -p
and
$ udevadm monitor -u -p
in two xterms, dumping the output to files, and I've kept a copy of
the corresponding kern.log to match up with them. I need to find
time to peruse it all.
I was going to suggest to Gene to run these commands, to see where
the serial numbers of his two devices are given, and which attribute
gives them, as Gene plugs the devices into the ports.
If you have /lib/udev/rules.d/60-serial.rules, which runs after the
above, you can see some more specific rules for ttyUSB[0-9]* devices.
I need to read up on what IMPORT{builtin}="usb_id" does, as that's
a udev rule that I've not used before.
(Actually, /I/ need to read up on stuff like
IMPORT{builtin}="hwdb
'mouse:$env{ID_BUS}:v$attr{id/vendor}p$attr{id/product}:name:$attr{nam
e}:'", …
whatever that does, from 70-mouse.rules.)
But it looks as if a file /etc/udev/rules.d/60-serial.rules
could be coerced into creating symlinks called /dev/
for each device (solves the "swapping" problem), and setting
the group/permissions for the ttyUSBn itself. Of course, we
don't know what permissions /do/ work yet, from Gene's posts.
Gene needs to copy that file, and add a simple rule to do something,
anything, to check it works, like touching a file or creating a
symlink (named with a timestamp). Gene might get a feel for how udev
operates, by doing something simple like that.
Cheers,
David.
Re: user perms
On 6/16/22 05:25, Anssi Saari wrote: David Wright writes: As it happens, I find I have (but don't use): $ grep -i ttyusb /lib/udev/rules.d/* I actually found this in 50-udev-default.rules: KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout" So that should set the group for ttySx and ttyUSBx also to dialout and in fact I see exactly that happening in my Debian 11 router which has devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4: $ ls -l /dev/ttyUSB* /dev/ttyS* crw-rw 1 root dialout 4, 64 Jun 13 12:12 /dev/ttyS0 crw-rw 1 root dialout 4, 65 Jun 13 12:12 /dev/ttyS1 crw-rw 1 root dialout 4, 66 Jun 13 12:12 /dev/ttyS2 crw-rw 1 root dialout 4, 67 Jun 13 12:12 /dev/ttyS3 crw-rw 1 root dialout 188, 0 Jun 13 12:12 /dev/ttyUSB0 crw-rw 1 root dialout 188, 1 Jun 13 12:12 /dev/ttyUSB1 crw-rw 1 root dialout 188, 2 Jun 13 12:12 /dev/ttyUSB2 crw-rw 1 root dialout 188, 3 Jun 13 12:12 /dev/ttyUSB3 crw-rw 1 root dialout 188, 4 Jun 13 12:12 /dev/ttyUSB4 I didn't find a rule which sets the perms for these to 0660 but something does that for me. This rule comes with the udev package itself so it should be always installed in a Debian installation. Still, it seems for Gene these are overwritten somehow but I don't know why or how. I have exactly one USB-to-serial cable I can try to plug in and see what happens. However it's a CP210x and I think Gene's stuff is >FTDI Yes, I had so much trouble with prolific crap I eventually threrw it away. $40 1998 dollars for junk. At Radio Shack of course. :( And I wish someone could tell me how to fix tbirds busted quoting, I wrote what starts with "yes" above and "I" CANNOT remove the quoting that looks like Anssi Saari wrote it. tbird is buggier than 10 day old road kill in August! I just did fix it, but extensive keyboard calisthentics were required. Thanks Anssi Saari, take care & stay well. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: user perms
On 6/16/22 03:58, Anssi Saari wrote: gene heskett writes: now my additional reply is munged, backspaces or Del's will not "take" What the heck is this vertical bar it uses for a quote level, whats wrong with > >> etc for quote indicators? There's a button containing an A overlaid by a graphical double square as the last line above the window that claims to "remove text styling" but it does nothing. Under options ->delivery format, plain text is checked, but obviously its still sending and rendering what I see as HTML. That's not the end of the bug list Just a note, in my end your post is just text: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Not HTML, not multipart/alternative with one part text and one HTML. I don't know if there's any filtering in-between, I read this list via Gmane's NNTP server. This install feels good yet, but at 36 hours uptime, I've used half the typical uptime I've managed in 30 previous installs. I have had to replace some memory, but now memtest can't be found, I guess because it is a 16 bit build, and can't be changed. But it ran ON THIS 6 core i5, probably 8 or 9 times pre bullseye. Debian 11 packages memtest86 and memtest86+ in the main repository with those package names exactly. Those are quite old and if you managed a UEFI installation they aren't bootable. So what replaces it? From the thread about its MIA status, I am not the only one wanting it or a 64 bit substitute back on the grub menu. I have a $100 bill for the talented coder who brings that or a new 64 bit from scratch version back. The commercial memtest86 v9 Pro from Passmark goes for $44 today. They have a free edition too with limited features. I now have that one installed on an sd card in a reader, works fine. I rebooted, found it in the bios, and ran it one pass, no errors. It does not!! That's what I'm screaming about. It sets the perms so only root can use them. I just plugged at least one of them in: root@coyote:/lib/udev/rules.d# ls -l /dev/ttyUSB* crw-rw 1 root dialout 188, 0 Jun 15 05:31 /dev/ttyUSB0 020660. The common user can't touch it. So what IS the "approved fix" so the user CAN use it? A fix that will actually survive a reboot. That's the question asked that every reply so far has ignored. I've looked into this and I have a draft of another post about that but basically it looks like it'll amount to just "I don't know why" and "it works for me." I need to test a few things though. A rude hack to fix the permissions would be to setup /etc/rc.local and do your chgrps and/or chmods in there. Instructions at https://blog.wijman.net/enable-rc-local-in-debian-bullseye/ for example. I just did all that, so now I have an /etc/rc.local but not an rc-local but he changes from rc.local to rc-local in the middle. confusing. So which is it. I originally created an rc.local, changed it to rc-local, and back with mv. But a root@coyote:/etc# systemctl status rc-local ● rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled) Drop-In: /usr/lib/systemd/system/rc-local.service.d └─debian.conf Active: active (exited) since Thu 2022-06-16 07:50:14 EDT; 19min ago Docs: man:systemd-rc-local-generator(8) Process: 49522 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS) CPU: 764us Jun 16 07:50:14 coyote systemd[1]: Starting /etc/rc.local Compatibility... Jun 16 07:50:14 coyote systemd[1]: Started /etc/rc.local Compatibility. Which looks good. So now I put what I want in which file? in this rc.local? or do I create an rc-local and put the needed chowns, chgrps chmods in yet another new file? What I have done is unplugged them in order to delete the /dev entries, so an ls -l /dev/ttyUSB* returns this: ls: cannot access '/dev/ttyUSB*': No such file or directory Then I plugged them back in, getting this for an ls -l /dev/ttyUSB* root@coyote:/etc# ls -l /dev/ttyUSB* crw-rw 1 root dialout 188, 0 Jun 16 08:18 /dev/ttyUSB0 crw-rw 1 root dialout 188, 1 Jun 16 08:18 /dev/ttyUSB1 Now, I'm not aware of who heyu runs as, probably gene since I'm the one running it and there is no user heyu. Now, 2 new questions: So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0, which has the cm11a on the other side of an fdti adaptor? Then: root@coyote:/etc# grep nut group nut:x:122: root@coyote:/etc# grep nut passwd nut:x:115:122::/var/lib/nut:/usr/sbin/nologin So what do I put in this rc.local to enable nut to use /dev/ttyUSB1, which is an APC 1500 UPS. Both are returning no perms errors now gene@coyote:~$ heyu info starting heyu_relay HEYU: Can't open tty line. Check the permissions. and as root: root@coyote:/dev# /etc/init.d/nut-server start Starting nut-server (via systemctl): nut-server.service. root@coyote:/dev# /etc/init.d/nut-client start Starting
Re: user perms
David Wright writes: > As it happens, I find I have (but don't use): > $ grep -i ttyusb /lib/udev/rules.d/* I actually found this in 50-udev-default.rules: KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout" So that should set the group for ttySx and ttyUSBx also to dialout and in fact I see exactly that happening in my Debian 11 router which has devices ttyS0-ttyS3 and ttyUSB0-ttyUSB4: $ ls -l /dev/ttyUSB* /dev/ttyS* crw-rw 1 root dialout 4, 64 Jun 13 12:12 /dev/ttyS0 crw-rw 1 root dialout 4, 65 Jun 13 12:12 /dev/ttyS1 crw-rw 1 root dialout 4, 66 Jun 13 12:12 /dev/ttyS2 crw-rw 1 root dialout 4, 67 Jun 13 12:12 /dev/ttyS3 crw-rw 1 root dialout 188, 0 Jun 13 12:12 /dev/ttyUSB0 crw-rw 1 root dialout 188, 1 Jun 13 12:12 /dev/ttyUSB1 crw-rw 1 root dialout 188, 2 Jun 13 12:12 /dev/ttyUSB2 crw-rw 1 root dialout 188, 3 Jun 13 12:12 /dev/ttyUSB3 crw-rw 1 root dialout 188, 4 Jun 13 12:12 /dev/ttyUSB4 I didn't find a rule which sets the perms for these to 0660 but something does that for me. This rule comes with the udev package itself so it should be always installed in a Debian installation. Still, it seems for Gene these are overwritten somehow but I don't know why or how. I have exactly one USB-to-serial cable I can try to plug in and see what happens. However it's a CP210x and I think Gene's stuff is FTDI.
Re: user perms
gene heskett writes: > now my additional reply is munged, backspaces or Del's will not "take" > What the heck is this vertical bar it uses for a quote level, whats wrong > with > >> etc for quote indicators? There's a button containing an A > overlaid by a graphical double square as the last line above the window > that claims to "remove text styling" but it does nothing. Under options > ->delivery format, plain text is checked, but obviously its still sending > and rendering what I see as HTML. That's not the end of the bug list Just a note, in my end your post is just text: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Not HTML, not multipart/alternative with one part text and one HTML. I don't know if there's any filtering in-between, I read this list via Gmane's NNTP server. > This install feels good yet, but at 36 hours uptime, I've used > half the typical uptime I've managed in 30 previous installs. > I have had to replace some memory, but now memtest can't > be found, I guess because it is a 16 bit build, and can't be > changed. But it ran ON THIS 6 core i5, probably 8 or 9 times > pre bullseye. Debian 11 packages memtest86 and memtest86+ in the main repository with those package names exactly. Those are quite old and if you managed a UEFI installation they aren't bootable. > So what replaces it? From the thread about its MIA status, I > am not the only one wanting it or a 64 bit substitute back > on the grub menu. > > I have a $100 bill for the talented coder who brings that > or a new 64 bit from scratch version back. The commercial memtest86 v9 Pro from Passmark goes for $44 today. They have a free edition too with limited features. > It does not!! That's what I'm screaming about. > It sets the perms so only root can use them. I just > plugged at least one of them in: > root@coyote:/lib/udev/rules.d# ls -l /dev/ttyUSB* > crw-rw 1 root dialout 188, 0 Jun 15 05:31 /dev/ttyUSB0 > > 020660. The common user can't touch it. So what IS > the "approved fix" so the user CAN use it? A fix that > will actually survive a reboot. That's the question > asked that every reply so far has ignored. I've looked into this and I have a draft of another post about that but basically it looks like it'll amount to just "I don't know why" and "it works for me." I need to test a few things though. A rude hack to fix the permissions would be to setup /etc/rc.local and do your chgrps and/or chmods in there. Instructions at https://blog.wijman.net/enable-rc-local-in-debian-bullseye/ for example.
Re: user perms
On 6/15/22 14:45, David Wright wrote:
[...]
/lib/udev/rules.d/ unsurprisingly contains examples of
almost every sort of device.
But not once does is specifically mention /dev/ttyUSB. Its a bit
hard to find the rule for a serial adapter when its not mention
any place it the whole directory tree.
It is there but apparently my use of grep was defective.
> Well, there might not be, if you don't install anything that requires
those sorts of devices to be configured. Debian doesn't see the need
to include hundreds of configuration files for no particular reason.
You could try installing a few serial-ish packages to see what turns
up, or you could google for any mention of these files.
nut and heyu are both serial port users who have long since learned
how to speak serial thru USB shaped holes in back panels.
As it happens, I find I have (but don't use):
$ grep -i ttyusb /lib/udev/rules.d/*
/lib/udev/rules.d/40-usb_modeswitch.rules:# Adds a symlink "gsmmodem[n]" to the
lowest ttyUSB port with interrupt
/lib/udev/rules.d/40-usb_modeswitch.rules:KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*",
PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
/lib/udev/rules.d/60-serial.rules:KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*",
GOTO="serial_end"
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB0 (if #0): QCDM port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB1 (if #1): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #2): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #3): Ignore
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0): QCDM/DIAG
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS data
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT primary
port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
$
And so do I
ene@coyote:/lib/udev/rules.d$ grep -i ttyusb /lib/udev/rules.d/*
/lib/udev/rules.d/40-usb_modeswitch.rules:# Adds a symlink "gsmmodem[n]"
to the lowest ttyUSB port with interrupt
/lib/udev/rules.d/40-usb_modeswitch.rules:KERNEL=="ttyUSB*",
ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name
%p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
/lib/udev/rules.d/60-serial.rules:KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*",
GOTO="serial_end"
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB0 (if #0):
QCDM port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB1 (if #1): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #2): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #3): Ignore
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0):
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS
data port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB2 (if #2): AT
primary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB3 (if #3): AT
secondary port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0):
QCDM/DIAG port
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB1 (if #1): GPS
data port
Re: user perms
On Wed 15 Jun 2022 at 06:34:41 (-0400), gene heskett wrote:
> On 6/15/22 01:00, David Wright wrote:
What I wrote is slipping into a morass of IDK what.
> And I'm going to snip down to what I'm replying to, I think.
Yes, I'll join you in snipping.
[ … snipped stuff about email quoting … ]
> Generally I can. but a reboot fixes things so I have to do it
> all over again at every reboot, just because this list refuses
> to answer a simple question about setting the perms on 2
> devices that are identified as /dev/ttyUSB*.
Anyone reading this list can see this is not true.
> This install feels good yet, but at 36 hours uptime, I've used
> half the typical uptime I've managed in 30 previous installs.
I don't understand the concept of "using up" uptime. Surely
uptime just carries on ad infinitum until you have some downtime.
[ … snipped stuff about pigs and pocket money … ]
[ … snipped stuff about a blind person … ]
[ … snipped recapitulation of screen reader … ]
> > > > > but haven't changed the perms of /dev/ttyUSB* yet.
> > > > Of course, the idea was that /you/ don't have to do that: udev should
> > > > do it when you boot up the machine or plug in the items. That's what
> > > > makes it permanent. And by reading their distinctive serial numbers,
> > > > FTDHG45D and FTOOS09N, it also prevents the names of the two devices
> > > > being swapped around by a race, or the order of insertion.
> It does not!! That's what I'm screaming about.
Of course it doesn't, /as of now/. I see no evidence of your having
written the necessary file to tell udev to do what you want it to do.
Until you write it, "It does not!".
Look, if I write:
Here's how I make udev do X for me. Now you make it do Y for you
in the same manner, using my example and the system's examples
to help you,
there's no point in screaming that a) your question has fallen on
deaf ears for a decade, b) I haven't fixed your problem for you.
> It sets the perms so only root can use them. I just
> plugged at least one of them in:
> root@coyote:/lib/udev/rules.d# ls -l /dev/ttyUSB*
> crw-rw 1 root dialout 188, 0 Jun 15 05:31 /dev/ttyUSB0
Duh—yes, that's what the current rules on your system specify
that it should do, I suppose (I ain't there to look see).
> 020660. The common user can't touch it. So what IS
> the "approved fix" so the user CAN use it? A fix that
> will actually survive a reboot. That's the question
> asked that every reply so far has ignored.
It's not a "fix". You don't zap, or nuke, some file. You
write a bit of code (that's what the rules look like) to
tell it what you want doing. Like I did. That's what my
example is for. As they used to say on children's
TV 60 years ago, "Now /you/ try it".
Or if you're very lucky, you find something sufficiently alike
that you can copy the file under /etc/, and your modified
version will overrule the original file under /lib/.
Do you need telling that "your modified version" becomes
"your modified version" by your modifying it, and not by
magic just because I told you to copy it from /lib/ to /etc/.
> > /My/ example is for usb-devices that are mass-storage (sticks,
> > cards and drives), and so it deals in mount points. Your devices
> > aren't.
> Because at the moment, none of the serial adapters
> were plugged in. They both are now. and despite
> me, heyu, & nut
> being added to the dialout group, neither utility can talk to
> its hardware, no permission. So I'll remove the additions to /etc/group
> and await advice.
> > /lib/udev/rules.d/ unsurprisingly contains examples of
> > almost every sort of device.
> But not once does is specifically mention /dev/ttyUSB. Its a bit
> hard to find the rule for a serial adapter when its not mention
> any place it the whole directory tree.
Well, there might not be, if you don't install anything that requires
those sorts of devices to be configured. Debian doesn't see the need
to include hundreds of configuration files for no particular reason.
You could try installing a few serial-ish packages to see what turns
up, or you could google for any mention of these files.
As it happens, I find I have (but don't use):
$ grep -i ttyusb /lib/udev/rules.d/*
/lib/udev/rules.d/40-usb_modeswitch.rules:# Adds a symlink "gsmmodem[n]" to the
lowest ttyUSB port with interrupt
/lib/udev/rules.d/40-usb_modeswitch.rules:KERNEL=="ttyUSB*",
ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p
%s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
/lib/udev/rules.d/60-serial.rules:KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*",
GOTO="serial_end"
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB0 (if #0): QCDM port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB1 (if #1): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #2): AT port
/lib/udev/rules.d/77-mm-fibocom-port-types.rules:# ttyUSB2 (if #3): Ignore
/lib/udev/rules.d/77-mm-quectel-port-types.rules:# ttyUSB0 (if #0):
Re: memtest (was: user perms)
On Wed, Jun 15, 2022 at 07:26:25AM -0400, Felix Miata wrote: > gene heskett composed on 2022-06-15 06:34 (UTC-0400): > > > I have had to replace some memory, but now memtest can't > > be found, I guess because it is a 16 bit build, and can't be > > changed. But it ran ON THIS 6 core i5, probably 8 or 9 times > > pre bullseye. > > > So what replaces it? From the thread about its MIA status, I > > am not the only one wanting it or a 64 bit substitute back > > on the grub menu. > > > I have a $100 bill for the talented coder who brings that > > or a new 64 bit from scratch version back. > > I don't even try to use FOSS memtest86+ on UEFI PCs. Instead, I use the free > version [...] For those who care, "free" seems here to mean "free of cost", not "free software". The website weasels around this point (which is somewhat irritating). Cheers -- t signature.asc Description: PGP signature
Re: memtest (was: user perms)
gene heskett composed on 2022-06-15 06:34 (UTC-0400):
> I have had to replace some memory, but now memtest can't
> be found, I guess because it is a 16 bit build, and can't be
> changed. But it ran ON THIS 6 core i5, probably 8 or 9 times
> pre bullseye.
> So what replaces it? From the thread about its MIA status, I
> am not the only one wanting it or a 64 bit substitute back
> on the grub menu.
> I have a $100 bill for the talented coder who brings that
> or a new 64 bit from scratch version back.
I don't even try to use FOSS memtest86+ on UEFI PCs. Instead, I use the free
version of the proprietary memtest86 from https://www.memtest86.com/. I run it
from this Grub stanza in /boot/grub/custom.cfg on my fastest/newest x86_64 PC:
menuentry "memtest86 7.4 EFI" {
search --no-floppy --label --set=root TM8P01ESP
chainloader /mt74x64.efi
}
That menu entry is pointing to the FAT32 ESP partition, which has the filesystem
label TM8P01ESP.
The current free version is much newer than 7.4.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Re: TBird mail (was: user perms)
gene heskett composed on 2022-06-15 06:34 (UTC-0400):
> What the heck is this vertical bar it uses for a quote level
That's taken care of here with one or both of these two entries in prefs.js in
the
profiledir:
user_pref("mail.quoteasblock", false);
user_pref("mail.quoted_graphical", false);
I haven't noticed whether or not in GUI preferences if either has a counterpart.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Re: user perms
On 6/15/22 01:00, David Wright wrote: And I'm going to snip down to what I'm replying to, I think. I am not at all sure tbird will do as I ask though. So my only instant question is when will the developers understand that stuff that runs as a $USER, needs one of two changes, either a .conf file someplace readable by the $USER that tells things like t-bird, running as the user, can have write privs to /var/log, /or/ an entry in that *.conf so logging can be done instead of just gobbling up the denial w/o bothering to tell the user it can't open the log. Its trivial to fix logrotate to service the logs in /home/$USER/logs where there's no perms problem because the $USER owns the whole path. No idea what this is all about, sorry. The above s/b one quote level but tbird won't lt me fix it. and now my additional reply is munged, backspaces or Del's will not "take" What the heck is this vertical bar it uses for a quote level, whats wrong with > >> etc for quote indicators? There's a button containing an A overlaid by a graphical double square as the last line above the window that claims to "remove text styling" but it does nothing. Under options ->delivery format, plain text is checked, but obviously its still sending and rendering what I see as HTML. That's not the end of the bug list Same perms story for heyu and nut, but some somebody, thinking security as opposed to usability, insists on building /dev/ttyUSB*, with 0660 perms. Neither nut, nor heyu can get past that to get their job done. And IF I reset those two devices to 0777, it all works but a reboot screws it up again I must have asked 15 or 20 times in the last decade, how to fix this in permanently in /lib/udev, and have been ignored when I ask that for several years. Usability, letting a computer actually DO its job simply isn't on the menu. With a record like that, can you blame me for being frustrated? Frustrated by asking for advice so I do do it right, and being ignored. The trouble with writing this is that people can look back. There was a thread in May 2020 on this topic, where all your posts have followups except for the two that sign out just like this one does below; ie "Now I know how but my editing foo is burned out for today", and "I'll see about it tomorrow, having used up my creative juices on another project today". In that thread, there is a working set of rules showing how udev runs a script when a USB stick is inserted or removed, the scripts themselves, and the data files that the scripts read¹. The scripts have no problem performing mkdir and rmdir in the /media directory: USB sticks aren't the issue here, serial adapter's are. $ ls -ld /media drwxr-xr-x 3 root root 4096 Jun 14 08:30 /media $ [...] You're a goddamned 20+ year Linux veteran. You should be able to handle something as ridiculously simple as this. Generally I can. but a reboot fixes things so I have to do it all over again at every reboot, just because this list refuses to answer a simple question about setting the perms on 2 devices that are identified as /dev/ttyUSB*. This install feels good yet, but at 36 hours uptime, I've used half the typical uptime I've managed in 30 previous installs. I have had to replace some memory, but now memtest can't be found, I guess because it is a 16 bit build, and can't be changed. But it ran ON THIS 6 core i5, probably 8 or 9 times pre bullseye. So what replaces it? From the thread about its MIA status, I am not the only one wanting it or a 64 bit substitute back on the grub menu. I have a $100 bill for the talented coder who brings that or a new 64 bit from scratch version back. Payable by whatever legal means puts the money in his or her pocket to extend the height of their ladder up the side of the hog. As usual, we don't know what you actually did to handle it. yes I did, but you snipped that part. How convenient... Get a grip: your entire post was quoted in mine, apart from your signature. So I write it again: As soon as it rebooted from the install, and I had gained root, I nano'd /etc/group and added me to group lp, so I could configure my 2 printers. I see; so messing about with /etc/group was "handling it". Well then, I'll repeat myself too: > > "adding myself to /etc/group in the appropriate places" sounds just > > like the sort of thing that might have caused /etc/passwd to become > > screwed up in installation #31. The catted group listing today, from install #32, now has me all over that file 12 times where the previous 31 installs only had me in sudo. Is that because I finally gave up and defined a root pw during the install? In that event IMNSHO the installer is broken in 2 ways. In ways not apparently related to to the auto install of all the brltty and orca crap that drives a sighted person into screaming fits. It stalls the machine while it trying to speak every keypress, fails because it hasn't learned how to speak English and can't be turned off w/o destroying the
Re: user perms
On Tue 14 Jun 2022 at 18:20:15 (-0400), gene heskett wrote: > On 6/14/22 13:25, David Wright wrote: > > On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: > > > On 6/13/22 14:36, Greg Wooledge wrote: > > > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> > > > > I appear as user 1000 seem to be stuck behind some sort of a >> > > > permissions wall. > > SHOW. US. > > > > > > I got tired of fighting with it Greg, so I did install #32 and installed > > > gnome_desktop (that was new) and xfce4 during the install, and > > > now things including the screen colors are back to normal, > > > > > > I've installed the brother printers and scanner drivers and I can modify t > > > them by the usual rules. I also set a root pw in addition to adding myself > > > to /etc/group in the appropriate places. I created an /sshnet tree with > > > the > > > other 5 machines here, did a root chown -R me:me on that path and just now > > > mounted all of them as me, so I own the path to me on the other 5 > > > machines. > > "adding myself to /etc/group in the appropriate places" sounds just > > like the sort of thing that might have caused /etc/passwd to become > > screwed up in installation #31. > > > > > And my working environment is getting close to completed, something > > > that only been workable occasionally since that last Seagate 2T drive > > > went tits down in the night last Dec 8th. > > > > > > Kmail5 is buggier than road kill in June, but t-bird is more like > > > August, so > > > I'm looking for a mailer that actually works. tbirds sort filters > > > don't, and > > > they think everybody uses only html, so word wrap doesn't work So I'm > > > doing this by hand.. > > > > > > So my only instant question is when will the developers understand that > > > stuff that runs as a $USER, needs one of two changes, either a .conf file > > > someplace readable by the $USER that tells things like t-bird, running as > > > the user, can have write privs to /var/log, /or/ an entry in that *.conf > > > so > > > logging can be done instead of just gobbling up the denial w/o bothering > > > to tell the user it can't open the log. Its trivial to fix logrotate > > > to service > > > the logs in /home/$USER/logs where there's no perms problem because > > > the $USER owns the whole path. > > No idea what this is all about, sorry. > > > > > Same perms story for heyu and nut, > > > but some somebody, thinking security as opposed to usability, insists > > > on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can > > > get past that to get their job done. And IF I reset those two devices > > > to 0777, > > > re reboot fixes that. > > > > > > I must have asked 15 or 20 times in the last decade, how to fix this in > > > permanently in /lib/udev, and have been ignored when I ask that for > > > several years. Usability, letting a computer actually DO its job simply > > > isn't on the menu. With a record like that, can you blame me for being > > > frustrated? Frustrated by asking for advice so I do do it right, and being > > > ignored. > > The trouble with writing this is that people can look back. > > > > There was a thread in May 2020 on this topic, where all your posts > > have followups except for the two that sign out just like this one > > does below; ie "Now I know how but my editing foo is burned out for > > today", and "I'll see about it tomorrow, having used up my creative > > juices on another project today". > > > > In that thread, there is a working set of rules showing how udev > > runs a script when a USB stick is inserted or removed, the scripts > > themselves, and the data files that the scripts read¹. The scripts > > have no problem performing mkdir and rmdir in the /media directory: > > > > $ ls -ld /media > > drwxr-xr-x 3 root root 4096 Jun 14 08:30 /media > > $ > > > > > [...] > > > > > > > You're a goddamned 20+ year Linux veteran. You should be able to > > > > handle something as ridiculously simple as this. > > > I just did, > > As usual, we don't know what you actually did to handle it. > > > yes I did, but you snipped that part. How convenient... Get a grip: your entire post was quoted in mine, apart from your signature. > So I write it again: > As soon as it rebooted from the install, and I had gained root, > I nano'd /etc/group and added me to group lp, so I could configure > my 2 printers. I see; so messing about with /etc/group was "handling it". Well then, I'll repeat myself too: > > "adding myself to /etc/group in the appropriate places" sounds just > > like the sort of thing that might have caused /etc/passwd to become > > screwed up in installation #31. > The catted group listing today, from install #32, now has > me all over that file 12 times where the previous 31 installs only had > me in > sudo. > > Is that because I finally gave up and defined a root pw during the install? > In that event IMNSHO the installer is broken in 2 ways. In ways
Re: user perms
On 6/14/22 13:25, David Wright wrote: On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: On 6/13/22 14:36, Greg Wooledge wrote: On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> I appear as user 1000 seem to be stuck behind some sort of a >> permissions wall. > > SHOW. US. I got tired of fighting with it Greg, so I did install #32 and installed gnome_desktop (that was new) and xfce4 during the install, and now things including the screen colors are back to normal, I've installed the brother printers and scanner drivers and I can modify t them by the usual rules. I also set a root pw in addition to adding myself to /etc/group in the appropriate places. I created an /sshnet tree with the other 5 machines here, did a root chown -R me:me on that path and just now mounted all of them as me, so I own the path to me on the other 5 machines. "adding myself to /etc/group in the appropriate places" sounds just like the sort of thing that might have caused /etc/passwd to become screwed up in installation #31. And my working environment is getting close to completed, something that only been workable occasionally since that last Seagate 2T drive went tits down in the night last Dec 8th. Kmail5 is buggier than road kill in June, but t-bird is more like August, so I'm looking for a mailer that actually works. tbirds sort filters don't, and they think everybody uses only html, so word wrap doesn't work So I'm doing this by hand.. So my only instant question is when will the developers understand that stuff that runs as a $USER, needs one of two changes, either a .conf file someplace readable by the $USER that tells things like t-bird, running as the user, can have write privs to /var/log, /or/ an entry in that *.conf so logging can be done instead of just gobbling up the denial w/o bothering to tell the user it can't open the log. Its trivial to fix logrotate to service the logs in /home/$USER/logs where there's no perms problem because the $USER owns the whole path. No idea what this is all about, sorry. Same perms story for heyu and nut, but some somebody, thinking security as opposed to usability, insists on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can get past that to get their job done. And IF I reset those two devices to 0777, re reboot fixes that. I must have asked 15 or 20 times in the last decade, how to fix this in permanently in /lib/udev, and have been ignored when I ask that for several years. Usability, letting a computer actually DO its job simply isn't on the menu. With a record like that, can you blame me for being frustrated? Frustrated by asking for advice so I do do it right, and being ignored. The trouble with writing this is that people can look back. There was a thread in May 2020 on this topic, where all your posts have followups except for the two that sign out just like this one does below; ie "Now I know how but my editing foo is burned out for today", and "I'll see about it tomorrow, having used up my creative juices on another project today". In that thread, there is a working set of rules showing how udev runs a script when a USB stick is inserted or removed, the scripts themselves, and the data files that the scripts read¹. The scripts have no problem performing mkdir and rmdir in the /media directory: $ ls -ld /media drwxr-xr-x 3 root root 4096 Jun 14 08:30 /media $ [...] You're a goddamned 20+ year Linux veteran. You should be able to handle something as ridiculously simple as this. I just did, As usual, we don't know what you actually did to handle it. yes I did, but you snipped that part. How convenient... So I write it again: As soon as it rebooted from the install, and I had gained root, I nano'd /etc/group and added me to group lp, so I could configure my 2 printers. The catted group listing today, from install #32, now has me all over that file 12 times where the previous 31 installs only had me in sudo. Is that because I finally gave up and defined a root pw during the install? In that event IMNSHO the installer is broken in 2 ways. In ways not apparently related to to the auto install of all the brltty and orca crap that drives a sighted person into screaming fits. It stalls the machine while it trying to speak every keypress, fails because it hasn't learned how to speak English and can't be turned off w/o destroying the uptime. I've met your blind person. He is running OpenSCAD, the gfx composer from that synth. I'd have to assume it speaks a lot better german than it does English. I have to admire his determination, he has a quadruple share of it to run OpenSCAD blind. If that's not changeable, then it should advertise the diff, but it does not. but haven't changed the perms of /dev/ttyUSB* yet. Of course, the idea was that /you/ don't have to do that: udev should do it when you boot up the machine or plug in the items. That's what makes it permanent. And by reading their distinctive serial
Re: user perms
On Mon, 13 Jun 2022 19:03:47 -0400 gene heskett wrote: > > Kmail5 is buggier than road kill in June, but t-bird is more like > August, so > > I'm looking for a mailer that actually works. tbirds sort filters > don't, and > > they think everybody uses only html, so word wrap doesn't work So I'm > > doing this by hand.. Have you tried Claws-mail? It used to be a bit buggy, but usable, but I haven't had any trouble for quite a while (the remaining bugs are well-hidden). I switched to it when I finally tired of waiting for TB to wake up and do things, it was cheaper than buying a faster computer. > > > So my only instant question is when will the developers understand > that > > stuff that runs as a $USER, needs one of two changes, either a .conf > file > > someplace readable by the $USER that tells things like t-bird, > running as > > the user, can have write privs to /var/log, /or/ an entry in that > *.conf so > I haven't installed MS Office for a while, but last time I did, it required root privileges on the first run, as all previous versions have done. A user file had to be created in a Windows system directory. It was no good doing it as root, each *user* had to be given admin privileges for that first run (of each Office component) and if the IT admin isn't allowed to know the users' passwords (as he shouldn't be) this required the presence of the user, at least to log on. In an office where anyone may log on to any computer, that's a monumental pain. When last I had to do that, there was no centralised way to do it, even in a domain. Beat that. -- Joe
Re: user perms
On Tue 14 Jun 2022 at 12:22:05 -0500, David Wright wrote: > On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: > > On 6/13/22 14:36, Greg Wooledge wrote: > > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> > > > I appear as user 1000 seem to be stuck behind some sort of a >> > > permissions wall. > > SHOW. US. > > > > I got tired of fighting with it Greg, so I did install #32 and installed > > gnome_desktop (that was new) and xfce4 during the install, and > > now things including the screen colors are back to normal, > > > > I've installed the brother printers and scanner drivers and I can modify t > > them by the usual rules. I also set a root pw in addition to adding myself > > to /etc/group in the appropriate places. I created an /sshnet tree with the > > other 5 machines here, did a root chown -R me:me on that path and just now > > mounted all of them as me, so I own the path to me on the other 5 machines. > > "adding myself to /etc/group in the appropriate places" sounds just > like the sort of thing that might have caused /etc/passwd to become > screwed up in installation #31. "...appropriate places" is about as fuzzy as it gets. The user appears to have been put is group lp. This is completely unwanted as it opens up a security hole. Thank goodness the OP is not managing my machines (or my TV reception capabilities :) ). -- Brian.
Re: user perms
On Tue, Jun 14, 2022 at 12:22:05PM -0500, David Wright wrote: > On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: > > On 6/13/22 14:36, Greg Wooledge wrote: > > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> > > > I appear as user 1000 seem to be stuck behind some sort of a >> > > permissions wall. > > SHOW. US. > > > > I got tired of fighting with it Greg, so I did install #32 and installed > > gnome_desktop (that was new) and xfce4 during the install, and > > now things including the screen colors are back to normal, > > > > I've installed the brother printers and scanner drivers and I can modify t > > them by the usual rules. I also set a root pw in addition to adding myself > > to /etc/group in the appropriate places. I created an /sshnet tree with the > > other 5 machines here, did a root chown -R me:me on that path and just now > > mounted all of them as me, so I own the path to me on the other 5 machines. > > "adding myself to /etc/group in the appropriate places" sounds just > like the sort of thing that might have caused /etc/passwd to become > screwed up in installation #31. > adduser gene would be the way to do it and have adduser write the file appropriately, in my experience. Manually editing /etc/passwd /etc/group or whatever is error-prone, yes. In the days when Raspbian defaulted to setting a pi user and default group I'd use the groups command to check whcich groups were set and then set them by using adduser for my own user, add my own user to the appropriate group for sudo then, at that point, logout, login as my own user and userdel -r pi > > And my working environment is getting close to completed, something > > that only been workable occasionally since that last Seagate 2T drive > > went tits down in the night last Dec 8th. > > > > Kmail5 is buggier than road kill in June, but t-bird is more like > > August, so > > I'm looking for a mailer that actually works. tbirds sort filters > > don't, and > > they think everybody uses only html, so word wrap doesn't work So I'm > > doing this by hand.. > > Thunderbird and the like do have options to set what they accept and what they display. Here, I'm using mutt - but I will admit that I had someone more knowledgeable help me set up mail forwarding and so on. Glad to hear you've finally got an environment that more or less works - maybe leave it working for more than a week if you possibly can All the very best to all on the list, as ever Andy Cater
Re: user perms
On Mon 13 Jun 2022 at 19:03:47 (-0400), gene heskett wrote: > On 6/13/22 14:36, Greg Wooledge wrote: > > On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> > > I appear as user 1000 seem to be stuck behind some sort of a >> > permissions wall. > > SHOW. US. > > I got tired of fighting with it Greg, so I did install #32 and installed > gnome_desktop (that was new) and xfce4 during the install, and > now things including the screen colors are back to normal, > > I've installed the brother printers and scanner drivers and I can modify t > them by the usual rules. I also set a root pw in addition to adding myself > to /etc/group in the appropriate places. I created an /sshnet tree with the > other 5 machines here, did a root chown -R me:me on that path and just now > mounted all of them as me, so I own the path to me on the other 5 machines. "adding myself to /etc/group in the appropriate places" sounds just like the sort of thing that might have caused /etc/passwd to become screwed up in installation #31. > And my working environment is getting close to completed, something > that only been workable occasionally since that last Seagate 2T drive > went tits down in the night last Dec 8th. > > Kmail5 is buggier than road kill in June, but t-bird is more like > August, so > I'm looking for a mailer that actually works. tbirds sort filters > don't, and > they think everybody uses only html, so word wrap doesn't work So I'm > doing this by hand.. > > So my only instant question is when will the developers understand that > stuff that runs as a $USER, needs one of two changes, either a .conf file > someplace readable by the $USER that tells things like t-bird, running as > the user, can have write privs to /var/log, /or/ an entry in that *.conf so > logging can be done instead of just gobbling up the denial w/o bothering > to tell the user it can't open the log. Its trivial to fix logrotate > to service > the logs in /home/$USER/logs where there's no perms problem because > the $USER owns the whole path. No idea what this is all about, sorry. > Same perms story for heyu and nut, > but some somebody, thinking security as opposed to usability, insists > on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can > get past that to get their job done. And IF I reset those two devices > to 0777, > re reboot fixes that. > > I must have asked 15 or 20 times in the last decade, how to fix this in > permanently in /lib/udev, and have been ignored when I ask that for > several years. Usability, letting a computer actually DO its job simply > isn't on the menu. With a record like that, can you blame me for being > frustrated? Frustrated by asking for advice so I do do it right, and being > ignored. The trouble with writing this is that people can look back. There was a thread in May 2020 on this topic, where all your posts have followups except for the two that sign out just like this one does below; ie "Now I know how but my editing foo is burned out for today", and "I'll see about it tomorrow, having used up my creative juices on another project today". In that thread, there is a working set of rules showing how udev runs a script when a USB stick is inserted or removed, the scripts themselves, and the data files that the scripts read¹. The scripts have no problem performing mkdir and rmdir in the /media directory: $ ls -ld /media drwxr-xr-x 3 root root 4096 Jun 14 08:30 /media $ > [...] > > > You're a goddamned 20+ year Linux veteran. You should be able to > > handle something as ridiculously simple as this. > > I just did, As usual, we don't know what you actually did to handle it. > but haven't changed the perms of /dev/ttyUSB* yet. Of course, the idea was that /you/ don't have to do that: udev should do it when you boot up the machine or plug in the items. That's what makes it permanent. And by reading their distinctive serial numbers, FTDHG45D and FTOOS09N, it also prevents the names of the two devices being swapped around by a race, or the order of insertion. > Only so > much time in one 24 hour day. Up since 4:40 my time, by 20:00 I'm burned > out for the day. ¹ https://lists.debian.org/debian-user/2020/05/msg00510.html Unlike the email posts, the web version doesn't show that "usgs1g" (the mount point) is the contents of an attached file called "2017-0403" (the USB stick's UUID), and likewise "cdrom3" in file "KZ3E2DH0440" (the portable DVD Writer's serial number). Cheers, David.
Re: user perms
On 2022-06-14 00:03, gene heskett wrote: I'm looking for a mailer that actually works. tbirds sort filters don't, and they think everybody uses only html, so word wrap doesn't work So I'm doing this by hand.. I'd have thought if you've got PCs in different buildings Dovecot, Roundcube, Seive on the PC with Apache on it would work for you. Think it uses postfix which seems automagically installed. I like it but really should upgrade. getmail from https://pyropus.ca./software/getmail/ for getting the mail mick
Re: user perms
On 6/13/22 14:36, Greg Wooledge wrote: On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: >> I appear as user 1000 seem to be stuck behind some sort of a >> permissions wall. > > SHOW. US. I got tired of fighting with it Greg, so I did install #32 and installed gnome_desktop (that was new) and xfce4 during the install, and now things including the screen colors are back to normal, I've installed the brother printers and scanner drivers and I can modify t them by the usual rules. I also set a root pw in addition to adding myself to /etc/group in the appropriate places. I created an /sshnet tree with the other 5 machines here, did a root chown -R me:me on that path and just now mounted all of them as me, so I own the path to me on the other 5 machines. And my working environment is getting close to completed, something that only been workable occasionally since that last Seagate 2T drive went tits down in the night last Dec 8th. Kmail5 is buggier than road kill in June, but t-bird is more like August, so I'm looking for a mailer that actually works. tbirds sort filters don't, and they think everybody uses only html, so word wrap doesn't work So I'm doing this by hand.. So my only instant question is when will the developers understand that stuff that runs as a $USER, needs one of two changes, either a .conf file someplace readable by the $USER that tells things like t-bird, running as the user, can have write privs to /var/log, /or/ an entry in that *.conf so logging can be done instead of just gobbling up the denial w/o bothering to tell the user it can't open the log. Its trivial to fix logrotate to service the logs in /home/$USER/logs where there's no perms problem because the $USER owns the whole path. Same perms story for heyu and nut, but some somebody, thinking security as opposed to usability, insists on building /dev/ttyUSB*, with 0600 perms. Neither nut, nor heyu can get past that to get their job done. And IF I reset those two devices to 0777, re reboot fixes that. I must have asked 15 or 20 times in the last decade, how to fix this in permanently in /lib/udev, and have been ignored when I ask that for several years. Usability, letting a computer actually DO its job simply isn't on the menu. With a record like that, can you blame me for being frustrated? Frustrated by asking for advice so I do do it right, and being ignored. [...] You're a goddamned 20+ year Linux veteran. You should be able to > handle something as ridiculously simple as this. I just did, but haven't changed the perms of /dev/ttyUSB* yet. Only so much time in one 24 hour day. Up since 4:40 my time, by 20:00 I'm burned out for the day. Take care and stay well, Greg. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: user perms
On 13/06/2022 18:39, Felix Miata wrote: Eduardo M KALINOWSKI composed on 2022-06-13 16:29 (UTC-0400): And Gene is one of a few users that never help themselves, even when repeatedly told what to do and what not to do. Just wait until your wife of 60 years is gone and you're 89. See how you like having no one there to talk to any more while your memory is fading from memory. It may be poor excuse, but it isn't something you can expect to go away through razzing, if ever. Be kind. At this stage, I cannot rule out the possibility that Gene Heskett is actually a social experiment to figure out how far people on debian-user will go in trying to help someone that asks for help, and then ignores the actual attempts at help received. Or maybe it's performance art, as someone else observed. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: user perms
Eduardo M KALINOWSKI composed on 2022-06-13 16:29 (UTC-0400): > And Gene is one of a few users that never help themselves, even when > repeatedly told what to do and what not to do. Just wait until your wife of 60 years is gone and you're 89. See how you like having no one there to talk to any more while your memory is fading from memory. It may be poor excuse, but it isn't something you can expect to go away through razzing, if ever. Be kind. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: user perms
On 13/06/2022 15:33, Greg Wooledge wrote: Why the hell do you CONTINUE to make these vague statements with NO demonstration of what the actual problem is? And why do you continue asking for the same things, knowing that they won't be provided? Not that your request in invalid - certainly if the user wants actual help, they must provided good and accurate details of the problem and of what they have tried in order to identify and/or solve the problem. But the OP in question never provides such details - even after repeatedly being asked for them, by you and other equally patient people. I understand the desire to help, but the user must be willing to help themselves - providing details when asked for, showing output of diagnostic commands, or just not jumping from unrelated problem to unrelated problem in the same conversation. And Gene is one of a few users that never help themselves, even when repeatedly told what to do and what not to do. -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, "Wolf in the Fold", stardate 3615.4 Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: MC settings (was: user perms)
Joe composed on 2022-06-13 20:03 (UTC+0100): > I don't know if you know this, but when you close mc the *current* > version of the config file is re-saved. So if you edited the file in > mc, the new version will be overwritten. That's an unfortunate default, not carved in stone. Turn off auto save setup and saving of settings won't happen unless you goto menu and select save. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: user perms
On Mon, 13 Jun 2022 13:56:12 -0400 gene heskett wrote: > I can't modify screen colors in any terminal or in mc, and mc's > colors are all so alike I can only read a directory list which is in > a different color, if I want to read a file, I have to use nano. > I don't know if you know this, but when you close mc the *current* version of the config file is re-saved. So if you edited the file in mc, the new version will be overwritten. I edit it in mc, save it under a different name, close mc and rename my file mc.ini. What I haven't yet found is a means of changing the colour of comments in files that mc recognises as programs. -- Joe
Re: user perms
On 6/13/2022 2:33 PM, Greg Wooledge wrote: On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: I appear as user 1000 seem to be stuck behind some sort of a permissions wall. SHOW. US. No need to shout in all caps. Why the hell no need for language You're a goddamned 20+ year Linux veteran. You should be able to handle something as ridiculously simple as this. again language and personal attack I just got an email saying there's a FAQ and a code of conduct. Bijan
Re: user perms
On Mon, Jun 13, 2022 at 01:56:12PM -0400, gene heskett wrote: > I appear as user 1000 seem to be stuck behind some sort of a permissions > wall. SHOW. US. Why the hell do you CONTINUE to make these vague statements with NO demonstration of what the actual problem is? It would take you FIVE SECONDS to paste the offending results from your terminal to the email you're already writing. Anyway, if you're seeing "1000" instead of "gene" in the output of some command such as "ls -ld ~" then it's probably your /etc/passwd file being broken in some way. Permissions on the file. Contents of the file. Permissions on the directories leading up to the file (/ and /etc). One of those things. Whatever it is, fix it. You're a goddamned 20+ year Linux veteran. You should be able to handle something as ridiculously simple as this.
user perms
Greetings all; I appear as user 1000 seem to be stuck behind some sort of a permissions wall. I can't modify screen colors in any terminal or in mc, and mc's colors are all so alike I can only read a directory list which is in a different color, if I want to read a file, I have to use nano. I've installed cups which wasn't before along with the brother drivers for my two printers, but they aren't configured, so I installed apache2 to use localhost:631 to set them up, firefox won't run as root and cups is denying me permissions to do anything to the displayed printers its finding, without asking me for a pw. So obviously, something is wrong. I am a member of the sudo group and the lp group. Do I have to do a 32nd install so it all hopefully gets fixed so I can actually do something? hanks for any ideas. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
