[opensuse] DVD gone, Sound gone
Hi, Today I tried to watch a DVD on my OS 13.2 laptop. When putting the disk in the drive I got a message in the tray that DVD-rom was installed. Trying to play it with Kaffeine, I could not. Last weekend, that same disk was announced with it's name and I had no problems playing the disk. Further investigation revealed my sound was gone too. KMix says I have a Dummy-output. Using Yast I had to reconfigure the sound-card. There, playing the test sound works, but I can't have sound from a "real" source. When I right-click on KMix and click sound-settings I get a screen indicating the sound-cards are there, but only the Dummy-output is active, the rest is greyed out. I tried removing .kde4/share/config/kmixctrlrc and kmixrc, but that does nothing. I tried logging in as root, and there everything works. I added a test-user, and there I have the same problems : no dvd, no sound. I tried to open a data-dvd but that fails also. There I get a valid name, and a choice of applications to open the dvd. But selecting file-manager gives an error message. Journalctl -f says this when inserting a data-dvd, as regular user : systemd-udevd[3372]: Failed to apply ACL on /dev/sr0: Invalid argument inserting a video-dvd as regular user gives this : okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Sense Key : Illegal Request [current] okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Add. Sense: Read of scrambled sector without authentication okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] CDB: okt 26 21:44:15 lt19 kernel: Read(10): 28 00 00 00 04 00 00 00 02 00 okt 26 21:44:15 lt19 kernel: end_request: I/O error, dev sr0, sector 4096 okt 26 21:44:15 lt19 kernel: Buffer I/O error on device sr0, logical block 512 okt 26 21:44:15 lt19 systemd-udevd[3401]: Failed to apply ACL on /dev/sr0: Invalid argument okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Sense Key : Illegal Request [current] okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] okt 26 21:44:15 lt19 kernel: Add. Sense: Read of scrambled sector without authentication okt 26 21:44:15 lt19 kernel: sr 1:0:0:0: [sr0] CDB: okt 26 21:44:15 lt19 kernel: Read(10): 28 00 00 00 04 00 00 00 02 00 okt 26 21:44:15 lt19 kernel: end_request: I/O error, dev sr0, sector 4096 okt 26 21:44:15 lt19..be kernel: Buffer I/O error on device sr0, logical block 512 As root : a data-dvd shows nothing. A video-DVD gives this : Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Sense Key : Illegal Request [current] Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Add. Sense: Read of scrambled sector without authentication Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] CDB: Oct 26 21:48:39 lt19 kernel: Read(10): 28 00 00 00 04 00 00 00 02 00 Oct 26 21:48:39 lt19 kernel: end_request: I/O error, dev sr0, sector 4096 Oct 26 21:48:39 lt19 kernel: Buffer I/O error on device sr0, logical block 512 Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Sense Key : Illegal Request [current] Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] Oct 26 21:48:39 lt19 kernel: Add. Sense: Read of scrambled sector without authentication Oct 26 21:48:39 lt19 kernel: sr 1:0:0:0: [sr0] CDB: Oct 26 21:48:39 lt19 kernel: Read(10): 28 00 00 00 04 00 00 00 02 00 Oct 26 21:48:39 lt19 kernel: end_request: I/O error, dev sr0, sector 4096 Oct 26 21:48:39 lt19 kernel: Buffer I/O error on device sr0, logical block 512 As far as I can see, the difference is that ACL that does not work. Any suggestions where to look to debug this ? TIA, Koenraad. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
Same problem here. Just intel sound, and now that is broken since 1.3.2 kernel update. Only Dummy output shown. But Yast Sound config can actually play test sounds.??? Go figure! -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 Also with that upgrade transparency in KDE and can't see how to turn it off -- 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
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
On 10/26/2016 05:35 PM, Bob Rea wrote:
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?
Sounds like some kind of theme problem in Start /config desktop Window decoration. Maybe switch decoration themes and then switch back or something. -- After all is said and done, more is said than done. -- 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 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. -- fr.gr. member openSUSE Freek de Kruijf -- 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
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??
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- 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
On 10/27/2016 12:18 PM, Marcus Meissner wrote:
No need for group member ship btw, all systemd / udev /acl magic these days.
I was indeed beginning to think that this was the case, and the changes to group/users was no longer the correct approach, since I could find no evidence of it in my backups of /etc/passwd or /etc/group. Yet the Yast users/groups module still offers these settings, but apparently does not make the changes to any place that systemd pays attention to. Where, precisely is the correct place to adjust these things in systemd? Where is this info stored? soonish - sounds disheartening, since this can be a rather debilitating. -- After all is said and done, more is said than done. -- 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
Op 28-10-16 om 05:30 schreef Andrei Borzenkov:
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.
An update : just tried to access a USB-stick. Same problem. Eagerly awaiting the fix. Koenraad. -- 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 <arvidjaar@gmail.com> 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 10/28/2016 03:31 AM, John Andersen wrote:
On October 27, 2016 8:30:17 PM PDT, Andrei Borzenkov <arvidjaar@gmail.com> 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.
+1
If a user is authorized to use the CD-ROM, they have to be in the cdrom group, and perhaps at the console.
+1 I'd phrase that as "in order for a user to be authorized", but yes, that's been my experience with previous versions of openSuse, Redhat and Mageia.
And putting them back into that group appears to be all that was necessary.
... and sufficient.
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.
That you can still log in ... oh wait, did the installer do the thing about asking for your id and password over again? Yes, my memory is that the installer hozes the groups file. presumably that Q&A menas it has also hozed the passwd file. The UGO and groups mechanism of *NIX is an adequate and sufficient ACL mechanism. A;; you need to do is understand set (aka group) theory, draw some Venn diagrams. The abomination that is the arbitrary and unstructured ACL mechanism was one of the overlay that came about from the UNIX Systems Group pandering to the forces of academia and the mainframe mentality. we got the P/V-style locks from them too, something Richie showed was unnecessary. -- 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 Fri, Oct 28, 2016 at 10:31 AM, John Andersen <jsamyth@gmail.com> wrote:
On October 27, 2016 8:30:17 PM PDT, Andrei Borzenkov <arvidjaar@gmail.com> 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 2016-10-28 09:31, 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.
You forget ACLs.
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.
udev creates the devices that you want to access with the permissions that it thinks are needed initially. And logind changes those permissions. The idea is that the user that is at the seat gets permissions to access physical devices automatically, whoever he is. The admin changing the group permissions is another method, but it is not automatic and it is fixed. Changing groups is not the current method used by the distribution. The update did not change passwd and group files at all. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 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. lopgind I do not know. From what Andrei said, logind changes the ACLs to all devices that have a certain flag in udev, so it may be hardcoded. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 28/10/2016 16:16, Anton Aylward wrote:
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.
Same as changing which groups you belong to... Yes, it is easier manipulating groups. There is no YaST assist on udev.
John did say that altering the groups file worked.
True.
He also said that an update (install?) hozed the password & groups files.
Not true. It was an hypothesis that later was proved false.
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.
Check a not updated machine, and you will see that the user has permissions (ACLs) but no groups.
It gets back to my point about 'necessary and sufficient'.
Welcome to systemd :-P -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- 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 28/10/2016 16:34, Anton Aylward wrote:
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.
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. -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- 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 2016-10-28 17:02, Anton Aylward wrote:
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.
No. Let me try again to explain. A normal, not broken system (not updated) needs no adjustments to the groups, made by the admin. An update broke the udev-logind-acls mechanism. So things do not work today. A temporary hack till a patch is produced is to adjust the groups. Another hack is to revert the update. I don't know exactly which. 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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 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 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. There is nothing that needs to be configured in this context. The files as shipped by the distribution work. Unless they break. 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. And anyway... I'm not the designer of the method, not even an expert. Ask somebody else. I only told you what is the current method at openSUSE, before it broke by the broken update. As far as I know it. You want to configure groups? It is not needed, once the update is patched and back to normal. If you do it, remember to undo later. After all, you do not have a multiseat machine, nor me. No one has. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
On 10/28/2016 08:38 PM, Carlos E. R. wrote:
After all, you do not have a multiseat machine, nor me. No one has.
If you read though the "Comments" on the Phoronix article you will see that quite a number of people have, most of them by adding extra graphics cards to their chassis. Its the appeal of "on the end of a cable", and USB2 cables are reasonable reliable up to about 10 metres, that makes the Plugable device attractive for 'at home with kids' or classroom or call-centre sutuations. -- 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 Wed, 26 Oct 2016 22:01:36 +0200, Koenraad Lelong wrote:
Hi,
Today I tried to watch a DVD on my OS 13.2 laptop.
....
As far as I can see, the difference is that ACL that does not work.
Any suggestions where to look to debug this ?
Yes, there was a regression regarding POSIX ACL handling in the last update openSUSE-13.2 kernel. It was already addressed and the fix was queued, waiting for publishing: https://bugzilla.opensuse.org/show_bug.cgi?id=1007035 Meanwhile, as a workaround, just keep using the previous kernel, or use a test kernel in http://download.opensuse.org/repositories/home:/tiwai:/bnc1007035/standard/ which is built from the same code as the next update kernel. We're sorry for inconvenience! thanks, Takashi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Anton Aylward -
Bob Rea -
Carlos E. R. -
Freek de Kruijf -
John Andersen -
Knurpht - Gertjan Lettink -
Koenraad Lelong -
Marcus Meissner -
Takashi Iwai