Gerard Beekmans wrote:
Are any of the project leads (blfs, clfs, hlfs) opposed to maintaining a
shared file like this, and possible more such files down the road if
they become needed? I'll speak on behalf of the LFS project itself and
say that I don't see a problem here. In fact, I think
Guys,
There seems to be some issues relating UIDs and GIDs especially between
BLFS and CLFS.
I'm not going to point the finger whose fault this is and I don't care
about personal issues as I have noticed things don't get done because
people don't care for other people for whatever reason.
Bruce Dubbs wrote:
An alternative way to maintain a master list might be to but it in an
.ent file as entities (similar to general.ent) and have each project
include that in the files where groups and users are needed. For BLFS,
we add explicit useradd and group add instructions in most
Gerard Beekmans wrote:
I think we can easily have a file on the website somewhere we refer to.
If an update is required, that'll be an easy task.
I am offering to update the blfs page I mentioned earlier to incorporate
all the values. That automatically puts it on the website.
-- Bruce
--
Gerard Beekmans wrote:
Bruce Dubbs wrote:
An alternative way to maintain a master list might be to but it in an
.ent file as entities (similar to general.ent) and have each project
include that in the files where groups and users are needed. For BLFS,
we add explicit useradd and group add
Bruce Dubbs wrote:
I am offering to update the blfs page I mentioned earlier to incorporate
all the values. That automatically puts it on the website.
I don't think this information should be in one of the *LFS books as
it's not project specific data.
--
Gerard Beekmans
/* If Linux
Jeremy Huntwork wrote:
You could just have each repo use svn externals and link to that master
.ent file. When you check out the repo (whether in CLFS, BLFS or HLFS)
you check out that external .ent file as well. The difficulty would be
deciding where to keep it and who has commit privs on it.
Jeremy Huntwork wrote:
You could just have each repo use svn externals and link to that master
.ent file. When you check out the repo (whether in CLFS, BLFS or HLFS)
you check out that external .ent file as well.
Last I heard, externals can only point to a directory, not a particular
file
El Martes, 22 de Noviembre de 2005 20:32, Gerard Beekmans escribió:
If what you said can easily be done--a shared file across all
repositories--then that's how we should go about it.
svn:externals have several limitations, see the last two paras in this page:
On 11/22/05, Gerard Beekmans [EMAIL PROTECTED] wrote:
To address this UID and GID issue, a possible solution seems pretty
straight-forward: we'll maintain a UID and GID list that every LFS
project refers to if they need to use a service or ID or whatever. And
if they introduce a new one, add
M.Canales.es wrote these words on 11/22/05 13:48 CST:
I would prefer an html page on the web server. And I'm voluntary to update
all
books to that new set of standard user and group IDs if needed.
Why on earth would we need new standards? We already have a
standard. The only thing that
Randy McMurchy wrote:
Though I personally think taking it out of the book is wrong. There
could be folks that use PDF versions and asking them to visit the
web to see the recommended values it not right.
The impression I got behind the suggestion would be that the books used
the webpage to
Tushar Teredesai wrote these words on 11/22/05 13:58 CST:
Instead of assigning a fixed ID number, why not define a range. For example:
* 1-20: Core users and groups (must have on every system). These are
created manually using the cat command in
Randy McMurchy wrote:
Tushar Teredesai wrote these words on 11/22/05 13:58 CST:
Instead of assigning a fixed ID number, why not define a range. For example:
* 1-20: Core users and groups (must have on every system). These are
created manually using the cat command in
On 11/22/05, Randy McMurchy [EMAIL PROTECTED] wrote:
Tushar Teredesai wrote these words on 11/22/05 13:58 CST:
Instead of assigning a fixed ID number, why not define a range. For example:
* 1-20: Core users and groups (must have on every system). These are
created manually using the cat
Matthew Burgess wrote:
Last I heard, externals can only point to a directory, not a particular
file (and http://svnbook.red-bean.com/en/1.1/ch07s04.html appears to
support that too).
So we would put the entity file in its own dedicated directory?
If I understand it correctly, there is no
Randy McMurchy wrote:
Though I personally think taking it out of the book is wrong. There
could be folks that use PDF versions and asking them to visit the
web to see the recommended values it not right.
There's a misunderstanding there. This document is for our use only --
the developers of
Jeremy Huntwork wrote these words on 11/22/05 14:09 CST:
I didn't really follow that original discussion. What was the reason for
that decision?
http://linuxfromscratch.org/pipermail/blfs-dev/2005-April/009761.html
--
Randy
rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3]
Randy McMurchy wrote:
This is not a bad idea. However, Bruce's plan was to group the
UID/GIDs by the type of package it is.
Mail = 21-30
Security = 31-40
And so on. The values you see above are not what is in the book.
I was just trying to show what Bruce's plan was.
That's fine. The scheme
On Tue, Nov 22, 2005 at 02:20:06PM -0600, Tushar Teredesai wrote:
There is no advantage of hard-coding the UID/GID.
Sure there is: less support questions. :)
I guess most folks do follow the recommended values.
I actually went *to* using the book's values because of having admin
access on
On Tue, Nov 22, 2005 at 02:07:25PM -0600, Randy McMurchy wrote:
Tushar Teredesai wrote these words on 11/22/05 13:58 CST:
Instead of assigning a fixed ID number, why not define a range. For example:
* 1-20: Core users and groups (must have on every system). These are
created manually
Gerard Beekmans wrote these words on 11/22/05 14:31 CST:
That's fine. The scheme is not of importance -- it's the coordination.
If in BLFS book Postfix ends up with UID 21, then Postfix in the CLFS
and/or HLFS books also has to use ID 21.
When we're all adding new components, we should
On 11/22/05, Archaic [EMAIL PROTECTED] wrote:
On Tue, Nov 22, 2005 at 02:20:06PM -0600, Tushar Teredesai wrote:
There is no advantage of hard-coding the UID/GID.
Sure there is: less support questions. :)
But that savings is offset by the discussions on which UID/GID to
assign to a
On Tue, Nov 22, 2005 at 02:39:06PM -0600, Tushar Teredesai wrote:
But that savings is offset by the discussions on which UID/GID to
assign to a user/group :)
Random number generation. :D
--
Archaic
Want control, education, and security from your operating system?
Hardened Linux From
Now we need to re-evaluate the UID/GID's. We are going to need some
changes for the GID's for udev. I'm working on some changes, that will
benefit all projects, it will give LFS/HLFS/CLFS the basic devices, and
be able to useful for BLFS. I'm going to have the necessary changes in
CLFS in a
Jim Gifford wrote:
Now we need to re-evaluate the UID/GID's. We are going to need some
changes for the GID's for udev.
Why?
I'm basing this off of Kay Sievers work, with Debian and OpenSuse. This
will elminate and change bootscripts also.
How have you gotten around the fact that these
Jim Gifford wrote:
Matt,
I've been working with Kay on this, let me get the changes out, it's
been working really well for me.
I'm not stopping you from getting the changes out, Jim (CLFS is your
baby!). I'm merely asking how you are installing a later version of the
kernel, without the
Matthew Burgess wrote:
Jim Gifford wrote:
Matt,
I've been working with Kay on this, let me get the changes out,
it's been working really well for me.
I'm not stopping you from getting the changes out, Jim (CLFS is your
baby!). I'm merely asking how you are installing a later version
On 11/22/05, Matthew Burgess [EMAIL PROTECTED] wrote:
Well, there's one really good reason to mandate $LFS being /tools -
that's the gcc-4.0.2-specs-1.patch which hardcodes /tools in there. If
we were to relax that /tools assumption, we'd have to explain what folks
would have to do in order
Jeremy Huntwork wrote:
1) Are those specific headers for that version necessary? Wouldn't the
current ones work?
Well, they work for me (I've been running 2.6.14 for a while now).
However, I'd imagine that if the kernel gets a new feature (e.g.
iNotify) but we don't install the userspace
Matt,
I should also mention Ryan is working on a way for us to santize our
own headers.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
On 11/22/05, Gerard Beekmans [EMAIL PROTECTED] wrote:
Randy McMurchy wrote:
http://linuxfromscratch.org/pipermail/blfs-dev/2005-April/009761.html
I agree with that idea also for other reasons: it makes things more
uniform across everybody's LFS system if people don't care about coming
up
On Tue, 22 Nov 2005, Matthew Burgess wrote:
Jeremy Huntwork wrote:
1) Are those specific headers for that version necessary? Wouldn't the
current ones work?
Well, they work for me (I've been running 2.6.14 for a while now). However,
I'd imagine that if the kernel gets a new feature (e.g.
Jim Gifford wrote:
Matt,
I should also mention Ryan is working on a way for us to santize our
own headers.
Why is this the first we've heard of this on the list? The subject
briefly came up not too long ago, an ideal point at which someone could
have told us what Ryan was up to.
You
I'm running into problems with the src/su dummy -c make
RUN_EXPENSIVE_TESTS=yes check tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first time I've tried
Ken Moffat wrote:
I'm running into problems with the src/su dummy -c make
RUN_EXPENSIVE_TESTS=yes check tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first
Gerard Beekmans wrote:
UID 25 should be assigned to, for example, the Postifx service, and you
can choose to install it from CLFS or BLFS depending on what your needs
are. Maybe Postfix is a poor example, but the idea is clear I hope.
Different books can install the same program in different
On Tue, Nov 22, 2005 at 04:52:22PM -0500, Jeremy Huntwork wrote:
Less redundancy, less maintenance, less worry about conflicts. I guess
there is the various arch issues and packages specific to those, but
CLFS could give general notes for each arch and instruct users to return
when done
On Tue, Nov 22, 2005 at 02:46:01PM -0700, Gerard Beekmans wrote:
What we need is all projects give a list of all the IDs they use (I have
BLFS' already from a post by Bruce earlier this afternoon) and see if
ther are issues, then reassign a new ID to use.
We follow LFS conventions. As for
Archaic wrote:
On Tue, Nov 22, 2005 at 04:52:22PM -0500, Jeremy Huntwork wrote:
Less redundancy, less maintenance, less worry about conflicts. I guess
there is the various arch issues and packages specific to those, but
CLFS could give general notes for each arch and instruct users to return
On Tue, 22 Nov 2005, Matthew Burgess wrote:
Yep, I ran into the same issue. Testing suggested that the /etc/passwd entry
for users you want to `su' to need a home dir. I therefore changed the
creation of the dummy user to:
echo dummy:x:1000:1000::/root:/bin/bash /etc/passwd
Have you
Jeremy Huntwork wrote:
Well, I was thinking of non-BLFS arch-specific programs, ie.,
bootloaders.
Now that's got a simple solution (simple == Just Needs Code TM). Rather
than getting it to play music and have it be Turing-complete, maybe
Grub2 could get support for other architectures?
In some circumstanaces yes, we have some different architectures that
require different programs. So merging the two books would not be an
ideal scenario. Not to mention the loads of patches needed for some of
the programs to work under MIPS. Unless the LFS book is going to have
those in
On Tue, 22 Nov 2005, Jeremy Huntwork wrote:
This is a bit off-topic, but this discussion has triggered another thought.
With CLFS at some point (whether you decide to chroot or boot) you're going
to be building the remainder of the book natively. At that point does CLFS
really need to
Jeremy Huntwork wrote:
Gerard Beekmans wrote:
--snip--
This is a bit off-topic, but this discussion has triggered another
thought. With CLFS at some point (whether you decide to chroot or
boot) you're going to be building the remainder of the book natively.
At that point does CLFS
(I'm not subscribed to lfs-dev, so I'd be grateful if you could Cc
me on followups)
I'd strongly advise against trying to mandate fixed assignments of
any application userids. Build procedures should include a dynamic
useradd-type account creation that automatically finds a free
numeric uid, and
On 11/22/05, Gerard Beekmans [EMAIL PROTECTED] wrote:
You work through the CLFS book and you install a service using those
instructions and that book suggest UID 25 and GID 25.
Now you move on to BLFS and the BLFS has you install another service.
But becuase our IDs are out of sync, the BLFS
Bruce (et al),
I no longer wish to be an editor of the BLFS book.
Richard.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Tushar Teredesai wrote:
With the scheme I mentioned, they would not be hard coding the UID/GID at all.
That one comes down to a preference I suppose. I don't like these
dynamics IDs where things are different every time I install a system,
depending on which order things happen to be
On Tue, 22 Nov 2005 11:34:45 -0700
Gerard Beekmans [EMAIL PROTECTED] wrote:
Guys,
There seems to be some issues relating UIDs and GIDs especially between
BLFS and CLFS.
I'm not going to point the finger whose fault this is and I don't care
about personal issues as I have noticed things
Richard A Downing wrote:
Gerard suddenly discovered that, in his long absence, the LFS
projects have got away from him and went looking for an 'issue' so as
to re-establish his authorty.
Richard, I am not looking for an issue, nor have I a need to
re-establish my authority. There is a problem
On 11/22/05, Gerard Beekmans [EMAIL PROTECTED] wrote:
Tushar Teredesai wrote:
With the scheme I mentioned, they would not be hard coding the UID/GID at
all.
That one comes down to a preference I suppose. I don't like these
dynamics IDs where things are different every time I install a
Tushar Teredesai wrote:
Agreed. But for the *LFS books, it is good to have instructions that
work for most users irrespective of their setup. Hard coding the
UID/GID would break in more scenarios than the scheme I mentioned.
I can agree with that point of view, technically speaking. Personally
On Tue, 22 Nov 2005 16:09:45 -0700
Gerard Beekmans [EMAIL PROTECTED] wrote:
Richard A Downing wrote:
Gerard suddenly discovered that, in his long absence, the LFS
projects have got away from him and went looking for an 'issue' so as
to re-establish his authorty.
Richard, I am not
I read all the lists (I think, I didn't check for new ones recently).
I have not seen this on lfs-dev or blfs-dev. Which lists?
cross-lfs
Gerard, you just burst back on the scene after months (or was it
eons?) of inactivity with a 'I'm The Boss, listen to me' kind of
mailing. What do you
On Tue, 22 Nov 2005 16:26:02 -0700
Gerard Beekmans [EMAIL PROTECTED] wrote:
I read all the lists (I think, I didn't check for new ones recently).
I have not seen this on lfs-dev or blfs-dev. Which lists?
cross-lfs
Damn it, there would be one! I didn't notice that cross-lfs had it's own
Ken Moffat wrote:
My experience with the pure64 hint (which was pretty close to LFS-6.1,
no biarch or triarch considerations, and the same toolchain) suggests
that it's pretty awkward to produce a meaningful precis like this.
Certainly, multilib variants are not going to fit nicely into
Archaic wrote:
Then the argument stays, but the terms change. Instead of arguing
specific uid/gid, it will be how best to arrange it. It is a policy
decision. As such, I like an arbitrary system with an emphasis in each
book that they are merely suggestions and not set in stone (though I'm
Richard A Downing wrote:
Bruce (et al),
I no longer wish to be an editor of the BLFS book.
I'm sorry that you cannot continue. Thank you for what you have done.
If you change your mind, let me know.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ:
For what it's worth on a build of today's SVN Chapter 5:
[EMAIL PROTECTED]: /mnt/rmlnew1/build/Installed for DIR in `ls -rt`; do echo
$DIR; cat
$DIR/diskspace.used; cat $DIR/sbu.time; echo; done
binutils-2.16.1-Pass1
190668 KB
1.00 SBU
gcc-4.0.2-Pass1
336696 KB
8.64 SBU
On Tue, 2005-11-22 at 20:47 +, Matthew Burgess wrote:
Tushar Teredesai wrote:
There is no advantage of hard-coding the UID/GID. (Just as there is no
advantage to hard-coding /tools into the LFS book but allowing users
to change $LFS but that is another topic).
Well, there's one
On Tue, 2005-11-22 at 20:54 +, Matthew Burgess wrote:
Jim Gifford wrote:
Now we need to re-evaluate the UID/GID's. We are going to need some
changes for the GID's for udev.
Why?
I'm basing this off of Kay Sievers work, with Debian and OpenSuse. This
will elminate and change
On Tue, 2005-11-22 at 13:15 -0800, Jim Gifford wrote:
Matt,
I should also mention Ryan is working on a way for us to santize our
own headers.
Don't dob me in yet ;-)
It can be done but man its a fair amount of work...
If worst comes to worst and llh doesn't release in a timely fashion
On Tue, 2005-11-22 at 21:14 +, Matthew Burgess wrote:
Jeremy Huntwork wrote:
1) Are those specific headers for that version necessary? Wouldn't
the
current ones work?
Well, they work for me (I've been running 2.6.14 for a while now).
However, I'd imagine that if the kernel gets a
Matthew Burgess wrote:
DJ Lucas wrote:
Sorry it's so last minute with release scheduled in 6 days, but I'd
suggest testing this patch for inclusion in 6.1.1. I have tested and
verified only on 2.3.5.
I don't have time to test this myself, so I'm going to have to ask
someone else to do a
65 matches
Mail list logo
