Re: Groups, permisions, work flow
On Wed, 2012-01-25 at 17:52 -0800, Len Ovens wrote: On Tue, January 24, 2012 8:37 pm, David Henningsson wrote: One of the advantages of Linux is that the line between single user system and multi user system is blurry. E g, I could run a web server or other service on the same machine as I use for audio production. This is great, it saves hardware. If a malicious user breaks in to the web server, I don't want him to be able to use RT prio to lock down the entire machine. I would think that running a server of any kind (other than something like netjack) on an audio machine would remove the need for RT anything... In the radio stations I have worked in, when the mic goes live, lots of things get turned off. From monitor audio to telephones... some even lock the door though most just light an on air lamp. Recording studios do the same. I am thinking a DAW should be able to do the same with extraneous software. Almost like having a recording runlevel. I really would not want someone to log in remotely while I was recording the 5th take of something and find out they did something that ruined the best take of the day. Yet, there are times it is handy to sftp in to look at files (from behind the the FW). Turning the network off might help, unless netjack (or other similar application) is using it. I think most people want to also be able to use their computer as a general computer sometimes too. However, the audio/video use is the priority use for the ubuntustudio distro. One of the reasons US moved to xfce was something with less overhead, but there is still two screens worth of process running just for the session (ps x). Top shows 125 process running overall. Top says 80% mem use while taskmanager says 26% (which is still a lot). I have 1g ram which is not a lot by todays standards but I think we could use less anyway. It would be nice if workflows could turn off some of the extra junk. Hmm, just thinking out loud. An analogy If you lock the door, you could run into trouble, if the studio catches fire and btw. it's a safe bet that somebody will knock at the door. The only safe solution is to ban people from the radio station who have no business in the radio station and ask all people who are needed for the production, to come to work. Accidents will happen easily to everybody of us. For Linux you should ban every piece of software, resp. all settings that could cause issues and start all software with correct settings that are needed. I suspect OOTB no distro will be perfect, but a lot of optimization can be done by scripts to start a session. On another list there's somebody who call people idiots that are unable to follow his work flow, e.g. if people won't add a user to the group audio manually, OTOH he blames a software for killing his speakers, just because he was careless. Taking care does mean to expect something that shouldn't happen. In Linuxland we have a situation where a group of experts will blame users if they just want to use a tool. The approach of Linux is that we need to be toolmakers too. Btw. a lot of stuff that should make live for users easier, made the usage harder instead. A balancing act regarding to the realtime group issue isn't worse the effort. Newbies should use a pre-build audio distro where the first user already is member of the group audio and for a radio station where the DAW has got several user accounts, there should be an audio engineer being able to be admin. 2 Cents, Ralf -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Thu, January 26, 2012 2:52 am, Ralf Madorf wrote: If you lock the door, you could run into trouble, if the studio catches fire and btw. it's a safe bet that somebody will knock at the door. The I thought of that after. A balancing act regarding to the realtime group issue isn't worse the effort. Newbies should use a pre-build audio distro where the first user already is member of the group audio and for a radio station where the DAW has got several user accounts, there should be an audio engineer being able to be admin. I agree. If it wouldn't confuse a new user too much, it would almost be best to install with two accounts, one that starts a session bare of almost everything for multi-media work and one for desktop use with bells and eye candy. Trouble is, I'm lazy, I don't want to have to log out and in and if I do it would be too tempting to leave both sessions running so I can switch between them (which would be worse). A button (menu selection) that turned a bunch of stuff off would be nice, but just using a stark desktop to begin with would probably be better. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Tue, January 24, 2012 8:37 pm, David Henningsson wrote: One of the advantages of Linux is that the line between single user system and multi user system is blurry. E g, I could run a web server or other service on the same machine as I use for audio production. This is great, it saves hardware. If a malicious user breaks in to the web server, I don't want him to be able to use RT prio to lock down the entire machine. I would think that running a server of any kind (other than something like netjack) on an audio machine would remove the need for RT anything... In the radio stations I have worked in, when the mic goes live, lots of things get turned off. From monitor audio to telephones... some even lock the door though most just light an on air lamp. Recording studios do the same. I am thinking a DAW should be able to do the same with extraneous software. Almost like having a recording runlevel. I really would not want someone to log in remotely while I was recording the 5th take of something and find out they did something that ruined the best take of the day. Yet, there are times it is handy to sftp in to look at files (from behind the the FW). Turning the network off might help, unless netjack (or other similar application) is using it. I think most people want to also be able to use their computer as a general computer sometimes too. However, the audio/video use is the priority use for the ubuntustudio distro. One of the reasons US moved to xfce was something with less overhead, but there is still two screens worth of process running just for the session (ps x). Top shows 125 process running overall. Top says 80% mem use while taskmanager says 26% (which is still a lot). I have 1g ram which is not a lot by todays standards but I think we could use less anyway. It would be nice if workflows could turn off some of the extra junk. Hmm, just thinking out loud. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 01/23/2012 09:12 AM, Kaj Ailomaa wrote: On 2012-01-22 21:08, David Henningsson wrote: On 01/21/2012 06:41 PM, Len Ovens wrote: There was some discussion on the IRC channel that got me thinking about this. Ubuntu's standard position on use of the audio group is here: https://wiki.ubuntu.com/Audio/TheAudioGroup After having cleaned that page up a bit (something strange was recently added to it), I'd just clarify my wishlist: 1) I would like users to be able to get stable real-time audio without having to violate system security. 2) If that is not possible, I'd like the audio group - as used by jackd2 - to be renamed in order not to clash with the problems outlined in the above article. The second solution seems quite simple to implement, so I've just filed a bug for this in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656910 Let's see what happens. I brought up this on the jack devel list. Both the problem with using audio group, as well as how to administer it. A suggestion was made to create a new group called preempt. Ideally, I would like it to end up as a default group for users on Debian based systems, but I'm not sure with whom to speak, and what reason is against it etc, but I'm asking around anyway. Would be gold to get this solved. Is there an Ubuntu Studio Controls application still around? If so, that might be the right place to aid with this. Or possibly one could add some kind of script that would give RT prio to the current logged in user (and remove it if the user logs out)? I wonder if that is possible, but if so, that might be a useful solution for the Live DVD as well. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 2012-01-24 10:51, Kaj Ailomaa wrote: On 2012-01-24 09:48, David Henningsson wrote: Is there an Ubuntu Studio Controls application still around? If so, that might be the right place to aid with this. Or possibly one could add some kind of script that would give RT prio to the current logged in user (and remove it if the user logs out)? I wonder if that is possible, but if so, that might be a useful solution for the Live DVD as well. No -controls application at this point, but a script may be the way to go. I'll investigate how that would work. I suspect adding the user to audio group is no problem, but removing is another story. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 01/24/2012 04:15 PM, Ralf Madorf wrote: On Tue, 2012-01-24 at 09:48 +0100, David Henningsson wrote: Or possibly one could add some kind of script that would give RT prio to the current logged in user (and remove it if the user logs out)? So you assume that there never will be more than one user be logged in? I guess having more than one user being logged in *at the same time* is fairly uncommon. Just as ConsoleKit would remove ACL file permissions on logging out, maybe it could remove RT prio stuff as well. I don't know how possible this is though. There's no need to remove a user from the group audio. There's no need to handle this by a script. If for a multi-user-system there shouldn't be an admin with knowledge, it soon or later will cause issues. One of the advantages of Linux is that the line between single user system and multi user system is blurry. E g, I could run a web server or other service on the same machine as I use for audio production. This is great, it saves hardware. If a malicious user breaks in to the web server, I don't want him to be able to use RT prio to lock down the entire machine. If Ubuntu Studio wants to be insecure in that sense, I guess that would be okay (to me personally, I can't speak for Ubuntu's security team), but I would definitely not have it in the Ubuntu by default. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 2012-01-25 05:37, David Henningsson wrote: If Ubuntu Studio wants to be insecure in that sense, I guess that would be okay (to me personally, I can't speak for Ubuntu's security team), but I would definitely not have it in the Ubuntu by default. It is not audio group (or whatever it may be called in the future - the one jack will use) in itself that gives you realtime prio, so the group in itself does nothing at all until a certain file is in place in the file system, right? It is only upon installing jackd when you are left with the choice of doing that. And if you do want realtime priv, then you will have to make this choice nevertheless. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 2012-01-22 21:08, David Henningsson wrote: On 01/21/2012 06:41 PM, Len Ovens wrote: There was some discussion on the IRC channel that got me thinking about this. Ubuntu's standard position on use of the audio group is here: https://wiki.ubuntu.com/Audio/TheAudioGroup After having cleaned that page up a bit (something strange was recently added to it), I'd just clarify my wishlist: 1) I would like users to be able to get stable real-time audio without having to violate system security. 2) If that is not possible, I'd like the audio group - as used by jackd2 - to be renamed in order not to clash with the problems outlined in the above article. The second solution seems quite simple to implement, so I've just filed a bug for this in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656910 Let's see what happens. I brought up this on the jack devel list. Both the problem with using audio group, as well as how to administer it. A suggestion was made to create a new group called preempt. Ideally, I would like it to end up as a default group for users on Debian based systems, but I'm not sure with whom to speak, and what reason is against it etc, but I'm asking around anyway. Would be gold to get this solved. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sun, 2012-01-22 at 03:58 +0100, Kaj Ailomaa wrote: My point in bringing up this problem with audio group was that new users (who wouldn't know about audio group) shouldn't have to create a new user and find that the new user cannot use audio applications in realtime. Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. But, in case you don't install from DVD... When installing ubuntustudio-packages separately from another Ubuntu based distro you will not get user to belong to audio group, and there is no direct explanation to why realtime won't work in this situation. While it is possible to find this out, isn't it much preferable for the user not having to know? [snip] You can't handle permissions that slipshod if it's for a repository used by several Sub-Ubuntus. Note that I installed Edubuntu and then added the Ubuntu Studio repository. Now imagine that this Edubuntu is used by very young children (btw. it isn't used by children on my machine). It's better the admin needs to google for an issue such as a group audio, than automatically add users to groups. If you want your children being able to run http://www.tuxpaint.org, you might not want them to be able to run your audio work to sync a raunchy video too ;). This of cause isn't a good example, since we would disable permissions to open such a project folder, because a group audio anyway wouldn't protect against access. As long as your Linux is for a single user only and it e.g. might only be a DAW, perhaps without an Internet connection, you can set SUID for all folders, you can run audio sessions as root etc., but as soon as it's a multi-user machine, there's the need to have an admin with knowledge. Regarding to the group audio there might be no security issue, dunno, I just want to warn that there might be a risk we all miss. 2 Cents, Ralf -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
Only an admin is allowed to install programs, and if the admin would be given a choice to include users to audio group during installation of a package (you can always answer no), than what is the problem? You'll have to do it anyway if you are intending to get realtime privilege (though many won't know they need to, and there's no telling when they realize the do). This audio group problem is one of those things that make it endlessly frustrating for people who only wish to install audio apps and start using them. As for Ubuntu Studio itself, it is intended for audio production, (amongst other things), and for Ubuntu Studio it makes no sense at all to leave users without realtime privilege when creating new users. It is of course different when installing packages, but this one problem could so easily be clarified to any user (they would at least become aware of it) if it would be included in the install process of jackd. On 2012-01-22 12:46, Ralf Madorf wrote: On Sun, 2012-01-22 at 03:58 +0100, Kaj Ailomaa wrote: My point in bringing up this problem with audio group was that new users (who wouldn't know about audio group) shouldn't have to create a new user and find that the new user cannot use audio applications in realtime. Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. But, in case you don't install from DVD... When installing ubuntustudio-packages separately from another Ubuntu based distro you will not get user to belong to audio group, and there is no direct explanation to why realtime won't work in this situation. While it is possible to find this out, isn't it much preferable for the user not having to know? [snip] You can't handle permissions that slipshod if it's for a repository used by several Sub-Ubuntus. Note that I installed Edubuntu and then added the Ubuntu Studio repository. Now imagine that this Edubuntu is used by very young children (btw. it isn't used by children on my machine). It's better the admin needs to google for an issue such as a group audio, than automatically add users to groups. If you want your children being able to run http://www.tuxpaint.org, you might not want them to be able to run your audio work to sync a raunchy video too ;). This of cause isn't a good example, since we would disable permissions to open such a project folder, because a group audio anyway wouldn't protect against access. As long as your Linux is for a single user only and it e.g. might only be a DAW, perhaps without an Internet connection, you can set SUID for all folders, you can run audio sessions as root etc., but as soon as it's a multi-user machine, there's the need to have an admin with knowledge. Regarding to the group audio there might be no security issue, dunno, I just want to warn that there might be a risk we all miss. 2 Cents, Ralf -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
Hi Kaj :) I'll continue top posting ;). To be honest, I can't see any disadvantage to set every user to the group audio, but I might have miss something. Why do we have a group audio? Perhaps there's a valid reason not to set every user to the group audio. I don't know. Regards, Ralf On Sun, 2012-01-22 at 14:09 +0100, Kaj Ailomaa wrote: Only an admin is allowed to install programs, and if the admin would be given a choice to include users to audio group during installation of a package (you can always answer no), than what is the problem? You'll have to do it anyway if you are intending to get realtime privilege (though many won't know they need to, and there's no telling when they realize the do). This audio group problem is one of those things that make it endlessly frustrating for people who only wish to install audio apps and start using them. As for Ubuntu Studio itself, it is intended for audio production, (amongst other things), and for Ubuntu Studio it makes no sense at all to leave users without realtime privilege when creating new users. It is of course different when installing packages, but this one problem could so easily be clarified to any user (they would at least become aware of it) if it would be included in the install process of jackd. On 2012-01-22 12:46, Ralf Madorf wrote: On Sun, 2012-01-22 at 03:58 +0100, Kaj Ailomaa wrote: My point in bringing up this problem with audio group was that new users (who wouldn't know about audio group) shouldn't have to create a new user and find that the new user cannot use audio applications in realtime. Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. But, in case you don't install from DVD... When installing ubuntustudio-packages separately from another Ubuntu based distro you will not get user to belong to audio group, and there is no direct explanation to why realtime won't work in this situation. While it is possible to find this out, isn't it much preferable for the user not having to know? [snip] You can't handle permissions that slipshod if it's for a repository used by several Sub-Ubuntus. Note that I installed Edubuntu and then added the Ubuntu Studio repository. Now imagine that this Edubuntu is used by very young children (btw. it isn't used by children on my machine). It's better the admin needs to google for an issue such as a group audio, than automatically add users to groups. If you want your children being able to run http://www.tuxpaint.org, you might not want them to be able to run your audio work to sync a raunchy video too ;). This of cause isn't a good example, since we would disable permissions to open such a project folder, because a group audio anyway wouldn't protect against access. As long as your Linux is for a single user only and it e.g. might only be a DAW, perhaps without an Internet connection, you can set SUID for all folders, you can run audio sessions as root etc., but as soon as it's a multi-user machine, there's the need to have an admin with knowledge. Regarding to the group audio there might be no security issue, dunno, I just want to warn that there might be a risk we all miss. 2 Cents, Ralf -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sat, January 21, 2012 7:04 pm, Kaj Ailomaa wrote: Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. Ok, that makes sense. Also this below: The GUI user creator allows creating more admin accounts. It in fact has three kinds of users: Custom (seems to be the default on US 12.04) Administrator Desktop However Custom appears to have almost no priv at all. Desktop gives a lot more. is a bug too. Custom should not be the default unless we can make custom user default to something reasonable. The desktop user defaults should be changed to include audio and should be the default choice when creating a new user. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sun, January 22, 2012 5:17 am, Ralf Madorf wrote: Hi Kaj :) I'll continue top posting ;). To be honest, I can't see any disadvantage to set every user to the group audio, but I might have miss something. Why do we have a group audio? Perhaps there's a valid reason not to set every user to the group audio. I don't know. It's actually kind of funny. because anyone else that uses this computer would not notice, would never start jack, would always use pulse anyway. I might cause them problems as I often leave my session running in back, but they would not cause me problems Maybe as they get older. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On 01/21/2012 06:41 PM, Len Ovens wrote: There was some discussion on the IRC channel that got me thinking about this. Ubuntu's standard position on use of the audio group is here: https://wiki.ubuntu.com/Audio/TheAudioGroup After having cleaned that page up a bit (something strange was recently added to it), I'd just clarify my wishlist: 1) I would like users to be able to get stable real-time audio without having to violate system security. 2) If that is not possible, I'd like the audio group - as used by jackd2 - to be renamed in order not to clash with the problems outlined in the above article. The second solution seems quite simple to implement, so I've just filed a bug for this in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656910 Let's see what happens. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: Does any of this make sense? Or am I crazy? Hahaha, neither or nor. You aren't an idiot, but it anyway isn't ideal. Sessions should be usable on different distros, since I'm switching between distros, I prefer to have distros as similar/equal as possible. So for me the ideal solution is the lowest common denominator ;). IMO a group audio managed by pam is the best solution. I don't care about sudo vs su etc.. A group audio IMO is a good idea, even and especially if different users should use the same files. IIUC, if the higher level folder is set to user Xyz and group audio, there shouldn't be an issue. The group audio at least is needed to set rt-priorities ;), hence any user usually should be member of the group audio. - Ralf -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sat, 2012-01-21 at 19:31 +0100, Ralf Madorf wrote: On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: Does any of this make sense? Or am I crazy? Hahaha, neither or nor. You aren't an idiot, but it anyway isn't ideal. Sessions should be usable on different distros, since I'm switching between distros, I prefer to have distros as similar/equal as possible. So for me the ideal solution is the lowest common denominator ;). IMO a group audio managed by pam is the best solution. I don't care about sudo vs su etc.. A group audio IMO is a good idea, even and especially if different users should use the same files. IIUC, if the higher level folder is set to user Xyz and group audio, there shouldn't be an issue. The group audio at least is needed to set rt-priorities ;), hence any user usually should be member of the group audio. - Ralf PS: What number on different distros is for the group audio, could be an issue. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: The installing user is both admin and sound engineer IIRC only the first user is admin, any additional user isn't! -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
On Sat, January 21, 2012 10:41 am, Ralf Madorf wrote: On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: The installing user is both admin and sound engineer IIRC only the first user is admin, any additional user isn't! The GUI user creator allows creating more admin accounts. It in fact has three kinds of users: Custom (seems to be the default on US 12.04) Administrator Desktop However Custom appears to have almost no priv at all. Desktop gives a lot more. Really, for the amount of time it takes to change the user type, it is just as easy to add them to the audio group maybe easier. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
My point in bringing up this problem with audio group was that new users (who wouldn't know about audio group) shouldn't have to create a new user and find that the new user cannot use audio applications in realtime. Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. But, in case you don't install from DVD... When installing ubuntustudio-packages separately from another Ubuntu based distro you will not get user to belong to audio group, and there is no direct explanation to why realtime won't work in this situation. While it is possible to find this out, isn't it much preferable for the user not having to know? If ubuntustudio-settings would add users to audio group, it might be appropriate to have a checklist show during installation, where the user decides which desktop/admin users should belong to audio group. Either that, or a simple yes/no to realtime operation and add all normal users to audio group, as well as change the template for creating new users. Further... It would make sense to let the installation of jackd make at least the current user belong to audio group. Right now, during the installation procedure, the user is asked if realtime operation should be permitted. When answering yes, /etc/security/limits.d/audio.conf is installed, but that's only half of what we need. So, in a way, you could say the installation of jackd suffers from a bug. If by installing jackd all normal users would be added to audio group, and the template for creating new users would now let new users belong to audio group, we don't actually need any UbuntuStudio specific editing at all in this area. This would probably make the most amount of sense, since we are in a situation where we absolutely do require audio group, may it be for pro, or semi pro needs, or even just letting a kid play on a soft synth in realtime without having audio dropouts. On 2012-01-21 20:20, Len Ovens wrote: On Sat, January 21, 2012 10:41 am, Ralf Madorf wrote: On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: The installing user is both admin and sound engineer IIRC only the first user is admin, any additional user isn't! The GUI user creator allows creating more admin accounts. It in fact has three kinds of users: Custom (seems to be the default on US 12.04) Administrator Desktop However Custom appears to have almost no priv at all. Desktop gives a lot more. Really, for the amount of time it takes to change the user type, it is just as easy to add them to the audio group maybe easier. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Groups, permisions, work flow
And sorry for not bringing up the problem with what implications audio group presents to the system. But, it seems to me whatever problems it presents, those are totally unavoidable for audio users. If adding the user to audio group is checked during installation of some package it should be enough to inform the person installing of what happens to the system by doing that. On 2012-01-22 03:58, Kaj Ailomaa wrote: My point in bringing up this problem with audio group was that new users (who wouldn't know about audio group) shouldn't have to create a new user and find that the new user cannot use audio applications in realtime. Having the option of administrating groups will of course always remain, but from my point of view, a distro like UbuntuStudio should have audio group as a default group for both the desktop and administrator users. Not having that is in my view a bug. As pointed out, the user who installs the system from DVD will belong to audio group, but not in any other other case. But, in case you don't install from DVD... When installing ubuntustudio-packages separately from another Ubuntu based distro you will not get user to belong to audio group, and there is no direct explanation to why realtime won't work in this situation. While it is possible to find this out, isn't it much preferable for the user not having to know? If ubuntustudio-settings would add users to audio group, it might be appropriate to have a checklist show during installation, where the user decides which desktop/admin users should belong to audio group. Either that, or a simple yes/no to realtime operation and add all normal users to audio group, as well as change the template for creating new users. Further... It would make sense to let the installation of jackd make at least the current user belong to audio group. Right now, during the installation procedure, the user is asked if realtime operation should be permitted. When answering yes, /etc/security/limits.d/audio.conf is installed, but that's only half of what we need. So, in a way, you could say the installation of jackd suffers from a bug. If by installing jackd all normal users would be added to audio group, and the template for creating new users would now let new users belong to audio group, we don't actually need any UbuntuStudio specific editing at all in this area. This would probably make the most amount of sense, since we are in a situation where we absolutely do require audio group, may it be for pro, or semi pro needs, or even just letting a kid play on a soft synth in realtime without having audio dropouts. On 2012-01-21 20:20, Len Ovens wrote: On Sat, January 21, 2012 10:41 am, Ralf Madorf wrote: On Sat, 2012-01-21 at 09:41 -0800, Len Ovens wrote: The installing user is both admin and sound engineer IIRC only the first user is admin, any additional user isn't! The GUI user creator allows creating more admin accounts. It in fact has three kinds of users: Custom (seems to be the default on US 12.04) Administrator Desktop However Custom appears to have almost no priv at all. Desktop gives a lot more. Really, for the amount of time it takes to change the user type, it is just as easy to add them to the audio group maybe easier. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
