Mailing List Archive

On Fri, 2004-10-08 at 00:20, Spider wrote:
> Also, what are suggested practices for shared media disks? Many
> people want something like /media/music (/media/video) partitions for
> the shared collection of music/media files between computer users. How
> should we setup permissions and recommendations for such?

There are a few options I can think of offhand:
1. Everything goes straight into /media or media-based subdirs,
read-only by some media group
2. Same, except also writable. This allows users to physically share
music rather than allowing the sysadmin to decide what's shared.
3. A combination of the two, something like /media/dropbox/ that's
writable.
4. Subdirs in /media per-user, each rw by user, ro by group. This sucks
to dig through looking for things but keeps permissions well.

Thoughts?
--
Donnie Berkholz
Gentoo Linux

begin quote
On Fri, 08 Oct 2004 08:11:27 -0700
Donnie Berkholz <spyderous@gentoo.org> wrote:

> On Fri, 2004-10-08 at 00:20, Spider wrote:
> > Also, what are suggested practices for shared media disks? Many
> > people want something like /media/music (/media/video) partitions
> > for the shared collection of music/media files between computer
> > users. How should we setup permissions and recommendations for
> > such?
>
> There are a few options I can think of offhand:

> 1. Everything goes straight into /media or media-based subdirs,
> read-only by some media group

/media is the common mount-point according to the standard, lets not
break it more than we already do.

ownership set to some media group is quite good, i use "audio" for my
music files, since people has to be in the audio-group to play them
anyhow, and it allows a single permission for both accessing the sound
and so on.


> 2. Same, except also writable. This allows users to physically share
> music rather than allowing the sysadmin to decide what's shared.

Thats pretty much the case we want, home-users probably -want- to share
music between accounts, rather than separating them. ok. ~/Music with
umode 022 can be used as well, if all users are in the same main group.



> 3. A combination of the two, something like /media/dropbox/ that's
> writable.

Thats like /tmp, sticky bit set, world writeable, (chmod 1777) where
only the owner can remove the files. Decent solution, but doesn't
really make sure that all the users have -read- access to all files.


> 4. Subdirs in /media per-user, each rw by user, ro by group. This
> sucks to dig through looking for things but keeps permissions well.

bad separation and sucky, its better to just use ~ in such a case.

>
> Thoughts?


Currently I'm using chmod 1777 /media/music, and run a script to
regularly set the permissions below it as this:
chgrp -R audio
chmod g+rw (for files)
chmod g+rxw (for directories)

however, this isn't really "optimal", but it works, and allows all users
to actually share the music. The whole idea is that the directory is
common storage, the same goes for other media. Things that are private
go into ~ anyhow.

the main argument for it is that I/we can export /media/music over
samba/nfs for other people, it separates user-data from "global commune"
data (at least where I live its perfectly ok to share music like this.
*waves to the RIAA* )

//Spider



--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

On Friday 08 October 2004 17:42, Spider wrote:
>
> Thats like /tmp, sticky bit set, world writeable, (chmod 1777) where
> only the owner can remove the files. Decent solution, but doesn't
> really make sure that all the users have -read- access to all files.

Well, we now have ACL support. You can easilly do this with acl in a
straightforward way. We might want to make a manual describing how to do it.
Together with the mostly undocumented mount options needed to enable acl's on
the filesystem.

> Currently I'm using chmod 1777 /media/music, and run a script to
> regularly set the permissions below it as this:
> chgrp -R audio
> chmod g+rw (for files)
> chmod g+rxw (for directories)

Acl's can set default permissions so your script shouldn't be needed anymore
(but you might want to run it once in a while to ensure that).

>
> however, this isn't really "optimal", but it works, and allows all users
> to actually share the music. The whole idea is that the directory is
> common storage, the same goes for other media. Things that are private
> go into ~ anyhow.

ACL's are great.

>
> the main argument for it is that I/we can export /media/music over
> samba/nfs for other people, it separates user-data from "global commune"
> data (at least where I live its perfectly ok to share music like this.
> *waves to the RIAA* )

And you know what? Samba supports ACL's too.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

begin quote
On Sat, 9 Oct 2004 11:25:30 +0200
Paul de Vrieze <pauldv@gentoo.org> wrote:


Okay, I'm short of temper today, so I'll try to not come across as
wanting to tear you apart. *grins*


> Well, we now have ACL support. You can easilly do this with acl in a
> straightforward way. We might want to make a manual describing how to
> do it.

Oops. guess that we don't have it supported then. We have the ability
to support it, however, I'm of the mind that a procedure that -isn't-
documented as avaiable for end-users isn't supported. Thats why we have
documentation.


>
> > Currently I'm using chmod 1777 /media/music, and run a script to
> > regularly set the permissions below it as this:
> > chgrp -R audio
> > chmod g+rw (for files)
> > chmod g+rxw (for directories)
>
> Acl's can set default permissions so your script shouldn't be needed
> anymore
> (but you might want to run it once in a while to ensure that).

Yep, Thats good if they can, and thats a good step to supporting
something like this.

> > however, this isn't really "optimal", but it works, and allows all
> > users to actually share the music. The whole idea is that the
> > directory is common storage, the same goes for other media. Things
> > that are private go into ~ anyhow.
>
> ACL's are great.

*Cough*


> > the main argument for it is that I/we can export /media/music over
> > samba/nfs for other people, it separates user-data from "global
> > commune"
> > data (at least where I live its perfectly ok to share music like
> > this.
> > *waves to the RIAA* )
>
> And you know what? Samba supports ACL's too.
>

Have I ever even refuted ACL's? I didn't bring them up since they
aren't documented as a possibility. Neither are group rights, Merlin,
or any of the other rights based permission-sets avaiable for unix. I
didn't bring up clustered stores either, even if those can,
technically, be used.

Neither did I bring up things like R/W VFAT mounts, which would -also-
solve the problem of having a shared space for files... Simply by not
having rights management :-)


Frankly, my point wasn't about ACL, the point of wether ACL was great or
less good than the small rocks stuck in the soles of my boots, or for
that matter if we should simply discard all rights management or not.

The question I posed, along with a somewhat make-shift solution, was
that we ought to have such a thing documented as avaiable. (yes, that
means supported ;)


I've seen solutions based on WebDAV + mdns to discover it, by indexing
the local Music dir in users homedirs shared with apache to the other
users (rendezvous / zeroconf style) But, this again, isn't something
we support, nor would I really advocate it, as it isn't optimal in any
sense.


Sharp rant out.

//Spider



--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

On Saturday 09 October 2004 15:15, Spider wrote:
> Okay, I'm short of temper today, so I'll try to not come across as
> wanting to tear you apart. *grins*

Ok, I'll not react to flames (much).
>
> Have I ever even refuted ACL's? I didn't bring them up since they
> aren't documented as a possibility. Neither are group rights, Merlin,
> or any of the other rights based permission-sets avaiable for unix. I
> didn't bring up clustered stores either, even if those can,
> technically, be used.

No you didn't. Actually ACL's are quite new and indeed very poorly documented.
They are however a good, clean solution to these issues and I suggest that we
consider them as a solution for this (with documentation). ACL's are
basically available for allmost all users as the latest 2.4 series also
support them on at least ext{2,3}fs, reiserfs and xfs.

>
> Neither did I bring up things like R/W VFAT mounts, which would -also-
> solve the problem of having a shared space for files... Simply by not
> having rights management :-)

R/W vfat mounts have serious disadvantages and are a crude tool.

> The question I posed, along with a somewhat make-shift solution, was
> that we ought to have such a thing documented as avaiable. (yes, that
> means supported ;)

I agree.

> I've seen solutions based on WebDAV + mdns to discover it, by indexing
> the local Music dir in users homedirs shared with apache to the other
> users (rendezvous / zeroconf style) But, this again, isn't something
> we support, nor would I really advocate it, as it isn't optimal in any
> sense.

Acl support is bugfree, supported by modern kernels and most relevant
filesystems and comes at very little cost (mostly diskspace). It offers a
great flexibility over the standard posix rights and can be made to work on
solving these issues.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Thursday 07 October 2004 06:17, Lindsay Haisley wrote:

> When I do a batch-emerge, such as 'emerge uU world', a lot of important
> informaton on various packages scrolls up the screen. Some of this stuff
> is must-read info, or stuff that would save a lot of time and research if I
> could read it. In Debian, with the ncurses debconf UI, I can swipe the
> important info screens and paste them into a file for review later. They
> all have <OK> buttons so they stay until you dismiss them. In Gentoo

Having dabbled with Debian briefly recently, I was quite impressed with the
fact that an email is sent to the admin/root user which summarises the
"important info" that is displayed after a package is installed.

--
Jason Wong

--
gentoo-desktop@gentoo.org mailing list

Thus spake Jason Wong on Thu, Oct 14, 2004 at 09:30:37PM CDT
> On Thursday 07 October 2004 06:17, Lindsay Haisley wrote:
>
> > When I do a batch-emerge, such as 'emerge uU world', a lot of important
> > informaton on various packages scrolls up the screen. Some of this stuff
> > is must-read info, or stuff that would save a lot of time and research if I
> > could read it. In Debian, with the ncurses debconf UI, I can swipe the
> > important info screens and paste them into a file for review later. They
> > all have <OK> buttons so they stay until you dismiss them. In Gentoo
>
> Having dabbled with Debian briefly recently, I was quite impressed with the
> fact that an email is sent to the admin/root user which summarises the
> "important info" that is displayed after a package is installed.

Hmmm. This is a new one on me :-) I track Debian testing on a couple of
boxes and haven't seen this yet. This is very much the way it ought to be
done.

There have been patches for portage going back close to 2 years, that
supposedly work well and save output einfo, ewarn and friends to special
logs if the proper magic is done in make.conf, but for some reason they've
never made it into production Gentoo, and there's no indication if and when
they will. I hacked functions.sh and emerge to output this information to
file descriptor 3 and this works OK for me for the time being, but I'll have
to patch these files again when the hacked files get upgraded. It's about
the same, I guess, since the patches published on bugs.gentoo.org have to be
reapplied to each upgrade also.

--
Lindsay Haisley | "Everything works | PGP public key
FMP Computer Services | if you let it" | available at
512-259-1190 | (Travis W. Redfish) | <http://www.fmp.com/pubkeys>
http://www.fmp.com | ("The Roadie") |

--
gentoo-desktop@gentoo.org mailing list

I'd like to add a point here with regard to documentation. The Gentoo
Documentation Project Team is pretty good about this in general, but it's
not in the Documentation Policy page, and there's just enough documentation
around (most of it non-Gentoo) that falls down on this point that it's worth
a mention.

There is absolutely no substitute for examples in documenting a facility,
especially with regard to config file syntax. I've seen some config file
man pages (e.g. devfsd.conf(5)) that are very long on formal syntax
definitions and very short on examples which are much more labor intensive
to understand than they would be if the author(s) included half a dozen
lines or so for a good example or two. The man page for sudoers(5) is a
good example of something that's very helpful in this regard. Not only is
the formal syntax definition very logical and complete, but the man page
closes with some really fine examples.

Gentoo docs are, by and large, very good not only with examples, but also
with specific instructions for config setups which 'just work' and which
also serve as examples for understanding the how/why of the setup. I can't
say the same for some other distributions.

--
Lindsay Haisley | "Everything works | PGP public key
FMP Computer Services | if you let it" | available at
512-259-1190 | (Travis W. Redfish) | <http://www.fmp.com/pubkeys>
http://www.fmp.com | ("The Roadie") |

--
gentoo-desktop@gentoo.org mailing list

Lindsay Haisley <fmouse-gentoo@fmp.com> wrote:

> Printers are an Issue in Linux, and it's not just Gentoo. Eric
> Raymond sent
> a flame letter to the CUPS people a while back detailing his horror
> story of
> setting up a CUPS printer. His story was chillingly similar to my own
> experience. It was a nightmare! Maybe the Gentoo devs could pick up
> the
> ball and make CUPS a little easier to use.

For what it's worth, I think that some band-aid could lessen the problem
ESR ran into a bit.

The problem is that everyone assumes that they have to do some
configuration work on the client, especially if the thing refuses to
print.

Warn them! The default install is actually perfectly able to find any
correctly set up CUPS print server. If it doesn't print, it's the server
that's incorrectly set up. I've tried several distros and they have all
found my server without me touching any config. I recently installed
Macos X on my Mac, and the first time I hit Command-P, the Oki 4w on my
cups server came up as the default printer and it printed without a
hitch.

Warn them! Add some text to the ebuild postinst bit that says that one
should generally not have to touch the config to set Cups up as a
client. Do the same in the admin web interface so they don't start
tinkering with setting up queues on their clients and so on. Tell them
that problems tend to be caused by incorrectly set up servers. And do it
in less geeky words than mine.

This, of course, does not solve the other problem: That setting up the
server is a nightmare, and that the docs on how to do it also is.

I'm treating cancer with aspirin, but hopefully it's a good start.

/Rasmus Wiman

--
gentoo-desktop@gentoo.org mailing list

Luke-Jr <luke-jr@utopios.org> wrote:

> > * printers
>
> Can be fixed by emerging the drivers w/ cups automatically. Perhaps a
> USE=extra-drivers adding RDEPENDs

This fixes local printing. But network printing is broken by docs. The
docs say that cups servers broadcast info about their printers, but in
the default config they do not and they don't listen for other boxes
wanting to print.

Of course, this is the sane way. Services should be locked down unless
explicitly opened, but the docs don't mention this at all and there's
AFAIK no task-based piece of documentation explaining how to do it.

/Rasmus Wiman

--
gentoo-desktop@gentoo.org mailing list