On 1/19/20 10:40 PM, Rich Freeman wrote:
> On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>>
>> This is retarded, stop wasting my time.
>>
>
> There is nothing retarded about shared /home directories. They're
> pretty common in the real world.
>
What's retarded is copy/pasting words
On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>
> This is retarded, stop wasting my time.
>
There is nothing retarded about shared /home directories. They're
pretty common in the real world.
> >> I've already got responses from two QA members. This thread is pretty
> >> hard to
On 1/19/20 9:52 PM, Rich Freeman wrote:
>>
>> Fantasy scenarios again. I'm not going to debunk a system that you just
>> thought up and that has never existed. Why don't you find one person who
>> actually does this, and see if it bothers him if we create a home
>> directory under /home where it
On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky wrote:
>
> On 1/19/20 8:20 PM, Rich Freeman wrote:
> > It would be far simpler for the sysadmin to simply ensure that no
> > unsynced user owns a file or appears in an ACL. That would be pretty
> > trivial to achieve. Whatever is hosting /home
On 1/19/20 8:20 PM, Rich Freeman wrote:
> It would be far simpler for the sysadmin to simply ensure that no
> unsynced user owns a file or appears in an ACL. That would be pretty
> trivial to achieve. Whatever is hosting /home could be designed to
> block such changes, or you could just scan for
On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky wrote:
>
> On 1/19/20 2:47 PM, Rich Freeman wrote:
> >
> > Obviously the UIDs associated with the shared /home need to be
> > identical. Simplest solution is to sync anything > 1000 in
> > /etc/passwd, and then not allow UIDs below 1000 in /home.
On 1/19/20 4:00 PM, Michael Orlitzky wrote:
>
> If I was willing to introduce a QA warning, this thread would have been
> a lot shorter =P
>
Just kidding, the eclass is rigged to die in src_install if you delete
the home directory, and if you wait until pkg_preinst, the warning gets
shown
On 1/19/20 2:47 PM, Rich Freeman wrote:
>
> Obviously the UIDs associated with the shared /home need to be
> identical. Simplest solution is to sync anything > 1000 in
> /etc/passwd, and then not allow UIDs below 1000 in /home. A cron job
> could easily handle both, and of course regular users
On 1/19/20 2:32 PM, Alec Warner wrote:
>
> Earlier you wrote:
>
> * The daemon DOES NOT need a home directory for its user.
> * I DO NOT want to install anything to anyone's home directory.
> * With respect to user.eclass, I'm proposing that /home be treated
> EXACTLY THE SAME as it
On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky wrote:
>
> On 1/19/20 2:02 PM, Rich Freeman wrote:
> >
> >> If you're sharing /home, you also have to be sharing user accounts,
> >> unless you want everyone to be assigned a random set of files.
> >
> > I imagine that most people setting up
On Sun, Jan 19, 2020 at 10:49:10AM -0500, Michael Orlitzky wrote:
> > That bug appears to be restricted. Perhaps it is embargoed? If not,
> > then it probably shouldn't be restricted, especially if already fixed
> > and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
> > this has
On Sun, Jan 19, 2020 at 11:28 AM Michael Orlitzky wrote:
> On 1/19/20 2:19 PM, Alec Warner wrote:
> >
> > All I want to do is *set* a user's home directory to /home/foo.
> >
> > Why wouldn't you set the homedirectory to /dev/null then?
> >
>
> Because /dev/null is not /home/foo? Is this a
On 1/19/20 2:19 PM, Alec Warner wrote:
>
> All I want to do is *set* a user's home directory to /home/foo.
>
> Why wouldn't you set the homedirectory to /dev/null then?
>
Because /dev/null is not /home/foo? Is this a trick question? =)
On 1/19/20 2:02 PM, Rich Freeman wrote:
>
>> If you're sharing /home, you also have to be sharing user accounts,
>> unless you want everyone to be assigned a random set of files.
>
> I imagine that most people setting up something like this would only
> be sharing high-value UIDs (>1000 in our
On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky wrote:
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really
On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky wrote:
>
> On 1/19/20 12:42 PM, Rich Freeman wrote:
> >
> > Typically you wouldn't share service accounts across multiple hosts.
> > I'd think that something like amavisd is going to go on a mail server.
> > You're not going to be logging into that
On 1/19/20 12:42 PM, Rich Freeman wrote:
>
> Typically you wouldn't share service accounts across multiple hosts.
> I'd think that something like amavisd is going to go on a mail server.
> You're not going to be logging into that account to do typical
> desktop-oriented functions.
>
> If you had
On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky wrote:
>
> On 1/19/20 6:29 AM, Rich Freeman wrote:
> >
> > Daemons are local users. There is no guarantee that /home is a local
> > filesystem. Heck, there is no guarantee that /home is even mounted
> > when portage is running. Portage
On 1/19/20 6:29 AM, Rich Freeman wrote:
>
> Daemons are local users. There is no guarantee that /home is a local
> filesystem. Heck, there is no guarantee that /home is even mounted
> when portage is running. Portage shouldn't be touching /home at all.
> With stuff like automounted or
On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky wrote:
>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really
On 1/18/20 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
>>
>> But now users have to follow one more step (create /home/amavis) when
>> setting up amavisd-new. Is the QA check really assuring a quality user
>> experience here?
>>
>
> Lots of daemons need
On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
>
> But now users have to follow one more step (create /home/amavis) when
> setting up amavisd-new. Is the QA check really assuring a quality user
> experience here?
>
Lots of daemons need a home directory for their users, and usually
they
On 1/18/20 1:10 PM, Ulrich Mueller wrote:
>
>> Should option (3) be viable, or do I go back to the drawing board?
>
> Chances are that /home is site specific, e.g. with a special backup
> policy, or shared between many hosts via NFS. So IMHO /home is off
> limits for the package manager.
>
We
On 1/18/20 2:03 PM, Alec Warner wrote:
>
> I tend to agree that in theory keeping the working directory and home
> directory the same is not ideal. However I'm not really aware of any
> practical problems. Haven't we basically run in this configuration for
> years? What kind of issues does it
On 1/18/20 2:08 PM, Michał Górny wrote:
>
> Sounds like you've created an arbitrary rule that prevents the two
> packages from using the same directory, and therefore you've created
> this problem yourself. Why not just go back and reconsider using
> the same directory instead of adding
On Sat, 2020-01-18 at 12:51 -0500, Michael Orlitzky wrote:
> We forbid packages from installing to /home for good reason: for most of
> history, users (and their home directories) were outside the purview of
> the package manager. But with GLEP81, that's changed: the package
> manager is now in
On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky wrote:
> We forbid packages from installing to /home for good reason: for most of
> history, users (and their home directories) were outside the purview of
> the package manager. But with GLEP81, that's changed: the package
> manager is now in
> On Sat, 18 Jan 2020, Michael Orlitzky wrote:
> Where do we put amavis's home directory?
> [...]
> 3 /home/amavis also seems fine to me, except for the fact that it's a
> QA violation to install there.
> Note that we could always set system users' home directories to
>
28 matches
Mail list logo
