On Wednesday, October 26, 2016 08:19:17 PM Bob Rea wrote:

On Wednesday, October 26, 2016 04:26:48 PM John Andersen wrote:

...

On 10/26/2016 01:01 PM, Koenraad Lelong wrote:

...

Further investigation revealed my sound was gone too. KMix says I have a Dummy-output.

Check your groups meembership. For me, I found I was no longer a member of user, video, or Audio groups.

I have the same problem and adding those to my user didn't help Yesterday I had the test sound, now I don't have that had been using Chrome streaming for radio station

for a long time that didn't work I did a kernel upgrade and then it did, then 13.2 upgrade for new bug and lost sound again

OK John Anderson's advice in the other audio thread worked I rebooted and got sound back Thank you John.

Also with that upgrade transparency in KDE and can't see how to turn it off

I do still have this problem. The window bar is transparent with light lines in it here and there. this makes it hard to use the window menu to move apps to other windows Any advice for that? -- Bob Rea www.petard.us www.petard.us/blog America, it was a wonderful country Til they took it private and made it a theme park of itself -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op 27-10-16 om 01:26 schreef John Andersen:

On 10/26/2016 01:01 PM, Koenraad Lelong wrote:

...

Further investigation revealed my sound was gone too. KMix says I have a Dummy-output.

Check your groups meembership. For me, I found I was no longer a member of user, video, or Audio groups.

I added myself to the audio and video groups. Now my sound is back. Unfortunately, still no access to my DVD-drive. B.T.W. I added myself to the cdrom group while doing to other groups, but that did not help. Comparing to my OS42.1 does not help. Thanks, Koenraad -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op 27-10-16 om 18:15 schreef Freek de Kruijf:

Op donderdag 27 oktober 2016 16:37:17 CEST schreef Koenraad Lelong:

...

Op 27-10-16 om 01:26 schreef John Andersen:

...

On 10/26/2016 01:01 PM, Koenraad Lelong wrote:

...

Further investigation revealed my sound was gone too. KMix says I have a Dummy-output.> Check your groups meembership. For me, I found I was no longer a member of user, video, or Audio groups.

I added myself to the audio and video groups. Now my sound is back.

Unfortunately, still no access to my DVD-drive. B.T.W. I added myself to the cdrom group while doing to other groups, but that did not help. Comparing to my OS42.1 does not help.

You need to log off and on to make the change in group member effective.

I know. I modified the group memberships, all at once, logged in as root. Then I logged out and logged in as regular user. Koenraad -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Oct 27, 2016 at 08:57:56PM +0200, Knurpht - Gertjan Lettink wrote:

Op donderdag 27 oktober 2016 20:28:11 CEST schreef Koenraad Lelong:

...

Op 27-10-16 om 18:15 schreef Freek de Kruijf:

...

Op donderdag 27 oktober 2016 16:37:17 CEST schreef Koenraad Lelong:

...

Op 27-10-16 om 01:26 schreef John Andersen:

...

On 10/26/2016 01:01 PM, Koenraad Lelong wrote:

...

Further investigation revealed my sound was gone too. KMix says I have a Dummy-output.>

Check your groups meembership. For me, I found I was no longer a member of user, video, or Audio groups.

I added myself to the audio and video groups. Now my sound is back.

Unfortunately, still no access to my DVD-drive. B.T.W. I added myself to the cdrom group while doing to other groups, but that did not help. Comparing to my OS42.1 does not help.

You need to log off and on to make the change in group member effective.

I know. I modified the group memberships, all at once, logged in as root. Then I logged out and logged in as regular user.

Koenraad What does ls -l /dev/sr0 && groups give, for the regular user??

Two days ago the 13.2 kernel update broke ACLs that give out these rights, it will be back with a fix update soonish No need for group member ship btw, all systemd / udev /acl magic these days. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

27.10.2016 22:27, John Andersen пишет:

Where, precisely is the correct place to adjust these things in systemd?

When user logs in on a local console, logind applies ACLs that grant this user read-write access to every device that has "uaccess" tag. Tag is set by udev rules. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On October 27, 2016 8:30:17 PM PDT, Andrei Borzenkov wrote:

27.10.2016 22:27, John Andersen пишет:

...

Where, precisely is the correct place to adjust these things in systemd?

When user logs in on a local console, logind applies ACLs that grant this user read-write access to every device that has "uaccess" tag. Tag is set by udev rules.

That's all well and good, but people do not manage permissions by udev rules. If a user is authorized to use the CD-ROM, they have to be in the cdrom group, and perhaps at the console. And putting them back into that group appears to be all that was necessary. So I don't see what udev has to do with it, and the root cause here must be that the update hozed the passwd and group files. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Oct 28, 2016 at 10:31 AM, John Andersen wrote:

On October 27, 2016 8:30:17 PM PDT, Andrei Borzenkov wrote:

...

27.10.2016 22:27, John Andersen пишет:

...

Where, precisely is the correct place to adjust these things in systemd?

When user logs in on a local console, logind applies ACLs that grant this user read-write access to every device that has "uaccess" tag. Tag is set by udev rules.

That's all well and good, but people do not manage permissions by udev rules.

If a user is authorized to use the CD-ROM, they have to be in the cdrom group, and perhaps at the console.

And putting them back into that group appears to be all that was necessary.

So I don't see what udev has to do with it

Device nodes are created by udev and udev sets their ownership and permissions, whether you like it or not. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 07:44 AM, Carlos E. R. wrote:

udev creates the devices that you want to access with the permissions that it thinks are needed initially. And logind changes those permissions.

And where is that configured? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 08:56 AM, Carlos E. R. wrote:

On 2016-10-28 14:34, Anton Aylward wrote:

...

On 10/28/2016 07:44 AM, Carlos E. R. wrote:

...

udev creates the devices that you want to access with the permissions that it thinks are needed initially. And logind changes those permissions.

And where is that configured?

I don't know.

I know that the last update broke it (logind, I think). Try reverting it.

Udev can be configured.

Changing the udev rules is a ROOT function and strikes me as a bit of a sledgehammer approach. John did say that altering the groups file worked. He also said that an update (install?) hozed the password & groups files.

lopgind I do not know.

I've looked though a variety of man pages and don't see anything that is relevant.

From what Andrei said, logind changes the ACLs to all devices that have a certain flag in udev, so it may be hardcoded.

As far as I can see, setting the entry in the groups file results in group permission when I run 'getfacl' on the devices. It gets back to my point about 'necessary and sufficient'. And yes I've seen source code for logind. But then again, I don't see anything in udev/rules that seems pertinent -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 10:29 AM, Carlos E. R. wrote:

...

Check a not updated machine, and you will see that the user has permissions (ACLs) but no groups.

HMMM If that's so, then no need for "not updated". Just remove the entry in the /etc/groups file and login in again. I'll test that later. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 10:37 AM, Carlos E. R. wrote:

...

No, it will not work, because the patch has not been released. We need a patch to logind or to udev or to the kernel - I don't know which.

If removing them won't work then having them in in the fist place shouldn't have worked Or are you saying that this whole discussion of what logind does/can do is invalid anyway, absent the patch? In which case the whole line of reasoning falls apart. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 03:15 PM, Carlos E. R. wrote:

The problem with adjusting groups (yes, it works) is that you have to remember to do it on all machines and all users that may need that access.

With the current method (logind-udevd) the permissions are adjusted automatically for the user on the chair, any user, the instant he seats, adjusting the ACLs temporarily. The admin needs doing nothing.

I'm sorry, that is STILL inconsistent. The login-udevd approach will still need the appropriate changes on each machine. The distributed form may be OK for you right now, on single user machines, but I can't see that it is going to be universally applicable in a more corporate, multi-seat context. Part of the changes along with systemd/logind is that ability to have multiple 'seats' on the same machine, just as we had back in the days of UNIX+terminals. Yes, some of those might be remote via modems (or later when networked, telnet). Multi-seat on a huge (e.g. quad CPU motherboard) headless processor supporting a dozen or more X11 sessions is also going to present different hardware from a personal desktop or laptop. What's in the distribution is no longer appropriate. Lets face it, in configuration terms, its never was for that setting! As for adjusting the groups (and password) on each machine in a network, well, surely so as to simplify administration and use of NFS and other stuff, a NIS service of some sort is going to be used. Doing that with YP had been around for ages; doing that with LDAP offers comparability with SAMBA and Windows. Now I'm sure that you are going to come back and tell me that (a) not everyone uses a NIS, which no doubt is true but does make me wonder, and (b) there are going to be exceptions for 'experimental/research/debug' purposes, which is also true. That latter case is also one where the admin is and operation is going to be highly 'customized' and we can't consider it a normal 'use case.' Finally, I'd point out that the udev rules, out of the box, are not customized on a per-user basis. As it is, they are every bit as static as as entries in the group file are, and those are easily customized for different users. What we really need is a RBAC approach, and presented as RBAC. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/28/2016 08:38 PM, Carlos E. R. wrote:

On 2016-10-29 00:30, Anton Aylward wrote:

...

On 10/28/2016 03:15 PM, Carlos E. R. wrote:

...

The problem with adjusting groups (yes, it works) is that you have to remember to do it on all machines and all users that may need that access.

With the current method (logind-udevd) the permissions are adjusted automatically for the user on the chair, any user, the instant he seats, adjusting the ACLs temporarily. The admin needs doing nothing.

I'm sorry, that is STILL inconsistent.

The login-udevd approach will still need the appropriate changes on each machine. The distributed form may be OK for you right now, on single user machines, but I can't see that it is going to be universally applicable in a more corporate, multi-seat context.

There are no multiseat machines in existence. :-P

I disagree. While a literal interpretation of https://www.freedesktop.org/wiki/Software/systemd/multiseat/ implies that the additional video cards and ports (perhaps USB) for mouse and keyboard CAN be physically in the same box, and googling around leads me to believe some people have done just that, there is nothing to exclude it being a networked connection, says from a X-terminal. Or something like this which implements the guts of an X-terminal of old, just add the mouse/keyboard/screen. It uses a USB 'net' rather than Ethernet. https://www.amazon.com/Plugable-DC-125-Docking-Station-Multiseat/dp/B004PXPPNA/ref=sr_1_10?ie=UTF8&qid=1335904746&sr=8-10 Or a later model, which also has Ethernet https://www.amazon.com/Plugable-Universal-DisplayLink-1920x1080-High-Speed/dp/B002PONXAI/ref=sr_1_3?ie=UTF8&qid=1335904746&sr=8-3 Review at http://www.phoronix.com/scan.php?page=article&item=plugable_multiseat_kick

Remote login is not a seat, in this context. Only the seat directly at the computer matters, it is the only one with access to the hardware.

And how is that 'thin client' not 'remote'? The USB might not allow 'in the next country', but it will allow 'at other desks in the classroom'. heck, if you machine can support a few VMs or a dozen Docker jobs then it can support a dozen or more of these 'thin clients'.

There is nothing that needs to be configured in this context. The files as shipped by the distribution work. Unless they break.

Indeed. That's the point that's made about this 'pluggable'. its 'plug and play'.

Anyway... if there were multiseats, well, each one would get the ACLs. You an set as many as you want on a single device. Which is also a problem.

Perhaps not 'as many as you want'. Perhaps not a whole building full. After all, the USB limit is 127. But wait! More than one USB port, right? And I'd really like to see an internet based one rather than a USB based one. Perhaps I should Go Google some more :-)

After all, you do not have a multiseat machine, nor me. No one has.

I have a few spare graphics cards and spare USB ports. I might try it sometime as an alternative to 'dual screen'. As for the 'no-one has', well obviously Phoronix had one. And I'm sure other people have deployed that device or done something similar. "Never says never". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org