Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Sunday 23 September 2007, John R. Graham wrote: On Thursday 20 September 2007, Mike Frysinger wrote: no, this cannot live in baselayout (the package that creates /root/), because it cannot be run everytime a user upgrades the baselayout package. no, it cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to make stage2) as the only time the /etc/skel/ - /root/ sync can sanely happen is in the final steps of creating a stage3 ... and there is nothing to differentiate the creation of a stage3 from a normal build, nor is there a sane way to make sure baselayout is the very last package in the stage3 build step Mike, for my own education (well, mostly), could you clarify why putting the copy of the appropriate files from /etc/skel - /root into the ebuild that creates them but tying that special action to USE=build isn't an acceptable solution? You've said that it would mean a special case for each ebuild that puts things into /etc/skel, but I believe we're talking about one or two ebuilds here, and, besides, isn't the ebuild the appropriate place for that sort of expertise to reside, or at least, not an inappropriate place? the /etc/skel - /root sync needs to happen at the very end of stage3 as that is the only place where you can state all packages relevant to a default install have been merged USE=build is for building a stage1 and generally speaking, there is no reason why baselayout cant be merged before any other package ... pretty much any depend listed in the baselayout ebuild are there to force a specific minimal version of a package and over time get dropped -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Friday 21 September 2007, Chris Gianelloni wrote: On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote: the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. I've already stated my preference for not doing *anything* outside of merging packages in the stages. Were this stage3, I wouldn't care. Anyway, I'd much rather leave everything as it is now than add the emerge --config stuff. You're free to add it to the ebuilds, of course, which would satisfy the people that want it, but I would prefer not add it to the stages, even if it is documented in the Handbook, as it isn't required. Basically, I'd rather we either throw it into the earlier stages, or not do it at all. You've given good reason on why, while technically feasible since we're only caring about bash at this time, it is still a bad idea as it opens us up to yet another slippery slope. I completely see your point, which is why I'm taking the stance that things are best left as they are now. defaults are never a requirement, but they provide a nice initial/sane environment we should really rename build to stage1, bootstrap to stage2, and then have catalyst add USE=stage3 during the stage3 step ... that would allow packages to automatically key off of the environment -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Mike Frysinger wrote: we should really rename build to stage1, bootstrap to stage2, and then have catalyst add USE=stage3 during the stage3 step ... that would allow packages to automatically key off of the environment I like this idea (hurray clarity!), but it would add an extra possibly undocumented step for a user to build a system from stage1 (since we don't support stage[12]-stage3 anymore). It would also cause whichever packages that use the 'stage3' flag to be needlessly rebuilt with the first 'emerge -uDN world'. Personally, I don't see either of these relatively minor issues as show stoppers. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thursday 20 September 2007, Mike Frysinger wrote: no, this cannot live in baselayout (the package that creates /root/), because it cannot be run everytime a user upgrades the baselayout package. no, it cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to make stage2) as the only time the /etc/skel/ - /root/ sync can sanely happen is in the final steps of creating a stage3 ... and there is nothing to differentiate the creation of a stage3 from a normal build, nor is there a sane way to make sure baselayout is the very last package in the stage3 build step -mike Mike, for my own education (well, mostly), could you clarify why putting the copy of the appropriate files from /etc/skel - /root into the ebuild that creates them but tying that special action to USE=build isn't an acceptable solution? You've said that it would mean a special case for each ebuild that puts things into /etc/skel, but I believe we're talking about one or two ebuilds here, and, besides, isn't the ebuild the appropriate place for that sort of expertise to reside, or at least, not an inappropriate place? - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote: On Thursday 20 September 2007, Chris Gianelloni wrote: Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? no, bash is not a special case why not add an `emerge --config baselayout` to the end of stage3 and i'll do the /root/ default setup in the baselayout ebuild I'd rather not do anything that isn't accomplished automatically by the ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 11:37 -0700, Chris Gianelloni wrote: ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. +1 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Friday 21 September 2007, Chris Gianelloni wrote: On Thu, 2007-09-20 at 20:52 -0400, Mike Frysinger wrote: On Thursday 20 September 2007, Chris Gianelloni wrote: Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? no, bash is not a special case why not add an `emerge --config baselayout` to the end of stage3 and i'll do the /root/ default setup in the baselayout ebuild I'd rather not do anything that isn't accomplished automatically by the ebuild when it is being merged. If this really is so objectionable, I'd just assume WONTFIX the request and move on with it. as outlined already, it's objectionable in the sense that once a user has entered the system, nothing can be assumed in the automatic case. by the user running `emerge --config baselayout`, we can assume that the behavior it exhibits (for example, setting up files in /root that dont exist from /etc/skel/) is expected. as also explained, tying into USE=bootstrap and USE=build is not correct as that does not represent everything in stage3 and there is no way to detect the stage2-stage3 state vs a normal emerge. the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote: the compromise is simple: catalyst runs --config at the end of stage3 for appropriate packages, but as to what those things actually do is left in the ebuilds. I've already stated my preference for not doing *anything* outside of merging packages in the stages. Were this stage3, I wouldn't care. Anyway, I'd much rather leave everything as it is now than add the emerge --config stuff. You're free to add it to the ebuilds, of course, which would satisfy the people that want it, but I would prefer not add it to the stages, even if it is documented in the Handbook, as it isn't required. Basically, I'd rather we either throw it into the earlier stages, or not do it at all. You've given good reason on why, while technically feasible since we're only caring about bash at this time, it is still a bad idea as it opens us up to yet another slippery slope. I completely see your point, which is why I'm taking the stance that things are best left as they are now. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote: Why can't the simple little default .bash_profile from /etc/skel be put into /root as well? $HOME directories shouldn't be touched by emerge. This is the user's turf. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wednesday 19 September 2007, Andrew Gaffney wrote:
John R. Graham wrote:
On the forums, I've seen the question, Why isn't my .bashrc being
executed when I log in as root but is being executed when I log in as a
normal user?, asked half a dozen times on the forums. Heck, I even
asked it myself a few years ago. Now, two years later, from a slightly
more mature level of domain knowledge, I have to ask why the root cause
shouldn't be addressed. Why can't the simple little default
.bash_profile from /etc/skel be put into /root as well?
When catalyst builds a stage tarball, it doesn't add any additional files.
All files in any stage tarball are created by one of the packages contained
within. In order to do this, a package such as baselayout would have to
install the file.
Looking at my local install, it's actually bash that creates
/etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s)
of the bash ebuild (should be the base-system herd) to add that
functionality, but I really doubt you'll convince them.
the issue is hardly limited to bash ... by this argument, you propose to have
every package which could possibly install into /etc/skel/ have special case
code to also install into /root/
what catalyst should do is just before cleaning up the stage3 root and packing
it up is run `rsync -a /etc/skel/ /root/`
no, this cannot live in baselayout (the package that creates /root/), because
it cannot be run everytime a user upgrades the baselayout package. no, it
cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to
make stage2) as the only time the /etc/skel/ - /root/ sync can sanely happen
is in the final steps of creating a stage3 ... and there is nothing to
differentiate the creation of a stage3 from a normal build, nor is there a
sane way to make sure baselayout is the very last package in the stage3 build
step
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wednesday 19 September 2007, Mike Doty wrote: John R. Graham wrote: like sys-apps/miscfiles. But where it should or shouldn't come from doesn't answer the fundamental question, Shouldn't it be there, from *some* source? Easy answer: no. Do you really want any script to automatically run when you login as root? think of exploits and the ability to do /bin/echo rm -rf / /root/.bash_profile coreutils will not `rm -rf /`: rm: cannot remove root directory `/' that said, anyone who has write access to /root owns the system ... whether the file exists by default is irrelevant -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Am Donnerstag, 20. September 2007 schrieb ext Alin Năstac: John R. Graham wrote: Why can't the simple little default .bash_profile from /etc/skel be put into /root as well? $HOME directories shouldn't be touched by emerge. And especially not root's $HOME. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Wanheimerstraße 68 | Web: http://www.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
I didn't say anything about emerge; I was talking about the Stage tarballs. I know, I know: Catalyst uses emerge. But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. Is that really the intention here? To break upstream-defined behavior? - John Alin Năstac wrote: John R. Graham wrote: Why can't the simple little default .bash_profile from /etc/skel be put into /root as well? $HOME directories shouldn't be touched by emerge. This is the user's turf. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote: I didn't say anything about emerge; I was talking about the Stage tarballs. I know, I know: Catalyst uses emerge. But, hasn't anyone realized that bash is _broken_ if this file doesn't exist? Quoting from the upstream-provided man page, When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. Is that really the intention here? To break upstream-defined behavior? First, please don't top-post. Second, you have an odd definition of broken. You seem to have complete glossed over the last part of the sentence that you pasted: if that file exists. Bash will *not* freak out and rape your dog if the file doesn't exist. All it means is that you get nothing more in your env than what's defined by /etc/profile. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Mike, I agree. But, the file that _must_ exist isn't ~/.bashrc but ~/.bash_profile. That's where the that particular bit of man-page-defined behavior is implemented. If ~/.bash_profile doesn't exist, then ~/.bashrc won't be sourced whether it exists or not. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Andrew. Sorry 'bout the top posting; won't do it again. For the rest, please see my reply to Mike Auty on the same topic. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R. Graham wrote:
Mike, I agree. But, the file that _must_ exist isn't ~/.bashrc but
~/.bash_profile. That's where the that particular bit of
man-page-defined behavior is implemented. If ~/.bash_profile doesn't
exist, then ~/.bashrc won't be sourced whether it exists or not.
Well, bash can't install a .bash_profile file into every user's home
directory for obvious reasons. That means they shouldn't rely on the
existence of one to source .bashrc, otherwise they could never guarantee
that functionality...
It appears as though you're looking for a location that is guaranteed to
be installed by bash and always executed when there's a non-login shell
start, from where you can source ${HOME}/.bashrc. I'm not familiar
enough with bash or Gentoo's setup of bash to comment on this I'm afraid
(possibly /etc/bash/bashrc?), but relying on .bash_profile so that you
can or can't source ${HOME}/.bashrc seems a little odd.
Moreover, however ${HOME}/.bashrc got into ${HOME}, presumably
.bash_profile could be put there at the same time if it doesn't already
exist?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8mcFu7rWomwgFXoRAnIIAKCUC1ShfOYvKKt5SN4oGV1uYz8HkACfVkVU
72TtoVvFFI/RXR4WGy5ya4o=
=dxNr
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Wed, 2007-09-19 at 21:57 -0400, John R. Graham wrote: Why can't the simple little default .bash_profile from /etc/skel be put into /root as well /etc/skel is for users created by the add user commands. root is inherently added *before* bash is installed, thus doesn't get anything from skel. Also, don't assume that the root user uses the bash shell. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 20 Sep 2007 08:09:08 -0400 John R. Graham [EMAIL PROTECTED] wrote: Mike, I agree. But, the file that _must_ exist isn't ~/.bashrc but ~/.bash_profile. That's wrong. Quote: When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. Notice the first one that exists and is readable. If ~/.bash_profile doesn't exist, then ~/.bashrc won't be sourced whether it exists or not. Wrong again. Two paragraphs down in the man page: When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. In this case ~/.bashrc is sourced directly. Cheers, Renat -- Probleme kann man niemals mit derselben Denkweise loesen, durch die sie entstanden sind. (Einstein) signature.asc Description: PGP signature
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You could add '[ -n ${BASH} -a -f ~/.bashrc ] . ~/.bashrc' to
/etc/profile.d/bash.sh. This file could be installed by app-shells/bash.
- --
Arfrever Frehtes Taifersar Arahesis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8mo1/axNJ4Xo/ZERAlTaAJ9KBBMZ5iC54va2Ajco/ezyRVipXwCgkneB
IGDioZ83MCaASlWxO9JdnnI=
=psDE
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote: what catalyst should do is just before cleaning up the stage3 root and packing it up is run `rsync -a /etc/skel/ /root/` It definitely should not. One of my primary motivations with catalyst is to ensure that the users get *exactly* what would be provided by the profiles/packages. We don't add extra files into the stages and likely never will. Doing something like this in catalyst would create an inconsistency between doing a stage3 install and any previous stage installs. Yes, we don't support stage1 anymore, but we still support stage1 users once their systems are up and running. Having them inconsistent only causes one more area where we have to do extra troubleshooting to determine the cause. no, this cannot live in baselayout (the package that creates /root/), because it cannot be run everytime a user upgrades the baselayout package. no, it cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to make stage2) as the only time the /etc/skel/ - /root/ sync can sanely happen is in the final steps of creating a stage3 ... and there is nothing to differentiate the creation of a stage3 from a normal build, nor is there a sane way to make sure baselayout is the very last package in the stage3 build step Well, it depends on whether we're interested in getting all of /etc/skel or just the .bash* files. About the only thing I would see useful as defaults is the .bash* stuff and a .ssh directory. I do agree that everything else should be left up to the user. If we decided what to include and limited it, it shouldn't be a problem to do it via USE=build at all. Of course, that doesn't answer the question, Do we want to? I have no clue. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 13:29 +0100, Roy Marples wrote: Also, don't assume that the root user uses the bash shell. The root user does *default* to the bash shell on Linux, at least. Of course, we could do whatever is appropriate for other targets. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thursday 20 September 2007, Chris Gianelloni wrote: On Thu, 2007-09-20 at 03:03 -0400, Mike Frysinger wrote: what catalyst should do is just before cleaning up the stage3 root and packing it up is run `rsync -a /etc/skel/ /root/` It definitely should not. One of my primary motivations with catalyst is to ensure that the users get *exactly* what would be provided by the profiles/packages. We don't add extra files into the stages and likely never will. Doing something like this in catalyst would create an inconsistency between doing a stage3 install and any previous stage installs. Yes, we don't support stage1 anymore, but we still support stage1 users once their systems are up and running. Having them inconsistent only causes one more area where we have to do extra troubleshooting to determine the cause. not really ... someone installing by hand and someone taking a default setup are different things. we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. we have no idea what people have done when they run emerge themselves. that is why only putting this into catalyst makes sense. no, this cannot live in baselayout (the package that creates /root/), because it cannot be run everytime a user upgrades the baselayout package. no, it cannot be tied to USE=build (used to make stage1) or USE=bootstrap (use to make stage2) as the only time the /etc/skel/ - /root/ sync can sanely happen is in the final steps of creating a stage3 ... and there is nothing to differentiate the creation of a stage3 from a normal build, nor is there a sane way to make sure baselayout is the very last package in the stage3 build step Well, it depends on whether we're interested in getting all of /etc/skel or just the .bash* files. About the only thing I would see useful as defaults is the .bash* stuff and a .ssh directory. I do agree that everything else should be left up to the user. If we decided what to include and limited it, it shouldn't be a problem to do it via USE=build at all. anything that is part of the system /etc/skel/ makes sense (iow, anything that is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir are the only things that go into /etc/skel/ right now for the default system. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote: what catalyst should do is just before cleaning up the stage3 root and packing it up is run `rsync -a /etc/skel/ /root/` It definitely should not. One of my primary motivations with catalyst is to ensure that the users get *exactly* what would be provided by the profiles/packages. We don't add extra files into the stages and likely never will. Doing something like this in catalyst would create an inconsistency between doing a stage3 install and any previous stage installs. Yes, we don't support stage1 anymore, but we still support stage1 users once their systems are up and running. Having them inconsistent only causes one more area where we have to do extra troubleshooting to determine the cause. not really ... someone installing by hand and someone taking a default setup are different things. we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. we have no idea what people have done when they run emerge themselves. that is why only putting this into catalyst makes sense. I'll respectfully disagree and say again that I won't add anything like this to catalyst for the reasons mentioned above. I see no reason why we cannot provide sensible defaults in stages lower than three, especially since I want to see everything in ebuild code. Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? Well, it depends on whether we're interested in getting all of /etc/skel or just the .bash* files. About the only thing I would see useful as defaults is the .bash* stuff and a .ssh directory. I do agree that everything else should be left up to the user. If we decided what to include and limited it, it shouldn't be a problem to do it via USE=build at all. anything that is part of the system /etc/skel/ makes sense (iow, anything that is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir are the only things that go into /etc/skel/ right now for the default system. OK. So we now know that only bash/openssh would be really important here, and the .ssh directory really isn't much of a show-stopper, since it isn't populated. I mention this only because we don't install openssh until stage3, so there's no special USE flags in use at that time. If we limited it to bash (and tcsh, etc. for non-Linux) using USE=build, it would satisfy this request, one which I personally would like to see done, and still not have to change a single line of code in catalyst, which also respects my wishes. It doesn't stomp on user's files. All in all, it seems like a safe enough solution to me. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Renat Golubchyk wrote: That's wrong. Quote: When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. Notice the first one that exists and is readable. If ~/.bash_profile doesn't exist, then ~/.bashrc won't be sourced whether it exists or not. Wrong again. Two paragraphs down in the man page: When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. In this case ~/.bashrc is sourced directly. Cheers, Renat Rats. I checked the source and you're right. My problem domain is smaller than I thought but still valid, I think. Basically the problem is only with interactive login shells and /root. Not *broken*, per se: just contrary to recommended practice. The Bash documentation *recommends* that a ~/.bash_profile exists so that ~/.bashrc can be made to be sourced for login shells and codifies its recommendation by putting a template .bash_profile in /etc/skel. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thursday 20 September 2007, Chris Gianelloni wrote: On Thu, 2007-09-20 at 12:34 -0400, Mike Frysinger wrote: what catalyst should do is just before cleaning up the stage3 root and packing it up is run `rsync -a /etc/skel/ /root/` It definitely should not. One of my primary motivations with catalyst is to ensure that the users get *exactly* what would be provided by the profiles/packages. We don't add extra files into the stages and likely never will. Doing something like this in catalyst would create an inconsistency between doing a stage3 install and any previous stage installs. Yes, we don't support stage1 anymore, but we still support stage1 users once their systems are up and running. Having them inconsistent only causes one more area where we have to do extra troubleshooting to determine the cause. not really ... someone installing by hand and someone taking a default setup are different things. we know that someone taking a stage3 has never configured anything before and so we can safely put defaults into /root/. we have no idea what people have done when they run emerge themselves. that is why only putting this into catalyst makes sense. I'll respectfully disagree and say again that I won't add anything like this to catalyst for the reasons mentioned above. I see no reason why we cannot provide sensible defaults in stages lower than three, especially since I want to see everything in ebuild code. Also, my plan for this would be add the copying of the .bash* files from /etc/skel if and only if USE=build *and* the files do not already exist, done during pkg_preinst/pkg_postinst somewhere. This will pull it into the stage1 tarball, making it available to everyone on all further stages, it keeps it from being done every time someone emerges bash, it doesn't stomp on existing files, and it doesn't show up in VDB linked to the bash package. Is this acceptable? no, bash is not a special case why not add an `emerge --config baselayout` to the end of stage3 and i'll do the /root/ default setup in the baselayout ebuild Well, it depends on whether we're interested in getting all of /etc/skel or just the .bash* files. About the only thing I would see useful as defaults is the .bash* stuff and a .ssh directory. I do agree that everything else should be left up to the user. If we decided what to include and limited it, it shouldn't be a problem to do it via USE=build at all. anything that is part of the system /etc/skel/ makes sense (iow, anything that is in /etc/skel/ at the end of stage3). the files from bash and the .ssh dir are the only things that go into /etc/skel/ right now for the default system. OK. So we now know that only bash/openssh would be really important here, and the .ssh directory really isn't much of a show-stopper, since it isn't populated. I mention this only because we don't install openssh until stage3, so there's no special USE flags in use at that time. If we limited it to bash (and tcsh, etc. for non-Linux) using USE=build, it would satisfy this request, one which I personally would like to see done, and still not have to change a single line of code in catalyst, which also respects my wishes. It doesn't stomp on user's files. All in all, it seems like a safe enough solution to me. no ... the fact that *today* we have just bash/openssh and *today* openssh is installing an empty dir (not exactly empty, the permissions are set much stricter than default `mkdir`) is irrelevant ... i want to fix this once and only once and not see another request about XYZ package installs FOO and now we decided we also want special code to handle FOO -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Roy Marples wrote: Looking over the bash man page, I cannot see the word recommended anywhere near .bash_profile. Could you clarify where you think bash recommends this? Thanks Roy Why, sure. It's my interpretation, but a reasonable one, I think. It recommends it in its implementation, by creating .bash_profile in /etc/skel with content that implements a particular behavior. The documentation also states, So, typically, your `~/.bash_profile' contains the line `if [ -f ~/.bashrc ]; then . ~/.bashrc; fi' after (or before) any login-specific initializations. And, lo, the .bash_profile file in /etc/skel has a functionally identical line in it. Doubly recommended, in a manner of speaking. - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 19:17 -0400, John R. Graham wrote: Rats. I checked the source and you're right. My problem domain is smaller than I thought but still valid, I think. Basically the problem is only with interactive login shells and /root. Not *broken*, per se: just contrary to recommended practice. The Bash documentation *recommends* that a ~/.bash_profile exists so that ~/.bashrc can be made to be sourced for login shells and codifies its recommendation by putting a template .bash_profile in /etc/skel. Looking over the bash man page, I cannot see the word recommended anywhere near .bash_profile. Could you clarify where you think bash recommends this? Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On Thu, 2007-09-20 at 21:22 -0400, John R. Graham wrote: Roy Marples wrote: Looking over the bash man page, I cannot see the word recommended anywhere near .bash_profile. Could you clarify where you think bash recommends this? Why, sure. It's my interpretation, but a reasonable one, I think. No it's not. bash does not recommend anything of the sort. It just states what files are optionally used during initialisation. What I'm driving at is that you're making claims that things are broken or recommended when in fact they are not. Try reading some RFC's and then you'll have a clearer (hopefully!!) understanding of the words MUST and SHOULD. Also you'll understand that if those words are not present then it's entirely optional. I fully recommend reading RFC 2131 [1] as I'm very well acquainted with it and it also provides lots of good examples of these words :) Thanks Roy [1] http://www.rfc-archive.org/getrfc.php?rfc=2131 PS - This does not necessarily mean I think /etc/skel files in /root is a bad thing, I just think you're going completely the wrong way about getting this done. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Roy Marples wrote: No it's not. bash does not recommend anything of the sort. It just states what files are optionally used during initialisation. What I'm driving at is that you're making claims that things are broken or recommended when in fact they are not. Try reading some RFC's and then you'll have a clearer (hopefully!!) understanding of the words MUST and SHOULD. Also you'll understand that if those words are not present then it's entirely optional. I fully recommend reading RFC 2131 [1] as I'm very well acquainted with it and it also provides lots of good examples of these words :) Thanks Roy [1] http://www.rfc-archive.org/getrfc.php?rfc=2131 PS - This does not necessarily mean I think /etc/skel files in /root is a bad thing, I just think you're going completely the wrong way about getting this done. Roy, thanks for the advice. Obviously I misstated some things. However, man pages and info docs are written in more colloquial language than formal specifications. Anyway, I promise not to beat the dead horse. - John -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
On the forums, I've seen the question, Why isn't my .bashrc being executed when I log in as root but is being executed when I log in as a normal user?, asked half a dozen times on the forums. Heck, I even asked it myself a few years ago. Now, two years later, from a slightly more mature level of domain knowledge, I have to ask why the root cause shouldn't be addressed. Why can't the simple little default .bash_profile from /etc/skel be put into /root as well? - John -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote:
On the forums, I've seen the question, Why isn't my .bashrc being
executed when I log in as root but is being executed when I log in as a
normal user?, asked half a dozen times on the forums. Heck, I even
asked it myself a few years ago. Now, two years later, from a slightly
more mature level of domain knowledge, I have to ask why the root cause
shouldn't be addressed. Why can't the simple little default
.bash_profile from /etc/skel be put into /root as well?
When catalyst builds a stage tarball, it doesn't add any additional files. All
files in any stage tarball are created by one of the packages contained within.
In order to do this, a package such as baselayout would have to install the file.
Looking at my local install, it's actually bash that creates
/etc/skel/.bash{rc,_logout,_profile}. You can appeal to the maintainer(s) of the
bash ebuild (should be the base-system herd) to add that functionality, but I
really doubt you'll convince them.
--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Andrew Gaffney wrote:
When catalyst builds a stage tarball, it doesn't add any additional
files. All files in any stage tarball are created by one of the
packages contained within. In order to do this, a package such as
baselayout would have to install the file.
Looking at my local install, it's actually bash that creates
/etc/skel/.bash{rc,_logout,_profile}. You can appeal to the
maintainer(s) of the bash ebuild (should be the base-system herd) to
add that functionality, but I really doubt you'll convince them.
I understand. Philosophically, it probably fits better in something
like sys-apps/miscfiles. But where it should or shouldn't come from
doesn't answer the fundamental question, Shouldn't it be there, from
*some* source?
- John
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
John R. Graham wrote:
like sys-apps/miscfiles. But where it should or shouldn't come from
doesn't answer the fundamental question, Shouldn't it be there, from
*some* source?
Easy answer: no. Do you really want any script to automatically run
when you login as root? think of exploits and the ability to do
/bin/echo rm -rf / /root/.bash_profile
It would be nice if one could tell bash to not run any ~/.bash* when
{e,}uid==0.
--
===
Mike Doty kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05
===
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
Mike, that exploit is neither easier nor harder if a default
.bash_profile exists. Or, am I missing something?
- John
Mike Doty wrote:
John R. Graham wrote:
like sys-apps/miscfiles. But where it should or shouldn't come from
doesn't answer the fundamental question, Shouldn't it be there, from
*some* source?
Easy answer: no. Do you really want any script to automatically run
when you login as root? think of exploits and the ability to do
/bin/echo rm -rf / /root/.bash_profile
It would be nice if one could tell bash to not run any ~/.bash* when
{e,}uid==0.
--
[EMAIL PROTECTED] mailing list
