Justin R. Knierim wrote these words on 08/05/05 01:53 CST:
> I am not sure if even a hint is needed, since it would be the worlds
> shortest hint! ;) It would say "install cracklib from BLFS, install
> shadow from LFS".
Actually, not. The BLFS shadow instructions disable CrackLib because
it i
On Fri, Aug 05, 2005 at 01:50:16AM -0500, Randy McMurchy wrote:
>
> At this point is seems 5 people have agreed that adding CrackLib
> is a good idea. Best as I can recall now, 3 have not.
As an optional, yes. I also concur. However, the point that you just
don't seem to be accepting is that a hi
Randy McMurchy wrote:
Actually, not. The BLFS shadow instructions disable CrackLib because
it is expected that Linux-PAM is installed.
I didn't say anything about disabling cracklib. I said to "install
cracklib from BLFS". If one only installs cracklib, and returns to LFS
to continue with
Justin R. Knierim wrote these words on 08/05/05 02:04 CST:
> I didn't say anything about disabling cracklib. I said to "install
> cracklib from BLFS". If one only installs cracklib, and returns to LFS
> to continue with shadow, all is good, right?
No, you must explicitly use --with-libcrack f
Archaic wrote these words on 08/05/05 02:01 CST:
> As an optional, yes. I also concur. However, the point that you just
> don't seem to be accepting is that a hint serves exactly that purpose.
No, Archiac, a hint doesn't serve the same purpose. I am proposing
that CrackLib be added to the Chapter
On Fri, Aug 05, 2005 at 07:59:43AM +0100, Richard A Downing wrote:
>
> I assume ( note ;-) that you use 'book' here to refer to the BLFS Book.
You assume correctly. ;)
> My point is that BLFS-Support is NOT a 'BLFS Book' support list but a
> Beyond 'LFS Book' Support list. I have NEVER seen it
On Fri, Aug 05, 2005 at 02:10:43AM -0500, Randy McMurchy wrote:
>
> No, Archiac, a hint doesn't serve the same purpose.
Then perhaps your purpose was flawed in that it didn't account for
people who don't want/need cracklib or for the package not being needed
for a basic development system (which
Randy McMurchy wrote:
No, you must explicitly use --with-libcrack for Shadow to link against
the installed libraries.
After checking this, you are correct sir. I do believe the "./configure
--help" output is misleading, since I assumed "default if found" would
enable it if found.
Sorry,
Archaic wrote:
But back to the original pariah
> comment, when dealing with a dependency, it can cause a less than
> friendly response when, after several attempts at finding a solution, it
> is finally realized (or mentioned) that a necessary portion of LFS was
> excluded which would have solved
Randy McMurchy wrote:
Hi all,
Something I've thought about for a long time, and now that CrackLib
is a maintained and stable package, I would like to propose that the
community consider adding this package to Chapter 6 in the LFS build.
-1.
Technical reason:
It doesn't stop international use
I am not a developer but,
> 6) Currently, CrackLib cannot be integrated into LFS using BLFS
> instructions without adding Linux-PAM also.
Surely that is a reason for modifying a section of BLFS.
> Even if you simply install the CrackLib package, Shadow would have
> to be recompiled to use the
Kev Buckley wrote:
If LFS is going to be *secure*, then personally I hope you guys get
rid of most of the inetutils clients
Well, we already remove the servers, so by removing the clients we may
as well just remove the entire package :) Seriously though, secure
versions for most of those cl
Hi,
During the recent thread on whether or not Cracklib should be introduced
to LFS, the lack of an official policy on what criteria a package has to
meet in order to be included in the book was highlighted. So, to
correct that, I'm going to get the ball rolling (after first donning my
flame
>Installing CrackLib in LFS just makes more sense to me now than when
>I came up with the idea 8 hours ago. There so far has not been one
>technical reason why we shouldn't do it.
If you consider this a technical answer then great. I think we need to look at
what level of security LFS should offe
Matthew Burgess wrote on a possible "securing" of LFS by moving away
from the inetutils binaries and concluded:
> Whilst researching this was quite enlightening, I think that such system
> hardening really does fall into "your distro, your rules". Clients such
> as ftp and telnet are still lar
Matthew Burgess wrote:
Thoughts, comments, suggestions?
I like it. It's essentially all the questions we've been asking already,
but it's nice to have it listed as such. Does this mean we go back and
run all our current packages through the ringer now? :P
Which reminds me, we might want to
Hello,
The first semi-official LFS Live CD that supports UTF-8 (for European
languages only) is now available.
You can download the image without sources from:
http://ums.usu.ru/~patrakov/lfslivecd/lfslivecd-x86-6.x-utf8-r0-nosrc.iso
The image with (non-UTF-8) LFS-6.1 sources included is:
h
On 8/5/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
>
> 1) Are the utilities and/or interfaces the package provides mandated by
> any of the following standards?
> * Filesystem Hierarchy Standard (FHS-2.3)
> * Linux Standard Base (LSB-3.0)
> * POSIX Single Unix System V3 (IEEE Std 10
Tushar Teredesai wrote:
FHS is good, not so sure about LSB since it mandates lot more packages
like PAM which are not in LFS.
I didn't read this as "let's go to each of these lists and match
precisely what is good in them". I read it as saying, "we have a package
under consideration for inclu
On 8/5/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Tushar Teredesai wrote:
> > FHS is good, not so sure about LSB since it mandates lot more packages
> > like PAM which are not in LFS.
>
> I didn't read this as "let's go to each of these lists and match
> precisely what is good in them". I re
Tushar Teredesai wrote:
I know, but if the policy states LSB and if the package is mandated by
LSB, it would be hard to say when someone asks PAM to be included in
LFS-core.
Maybe we can extend our policy to read that anyone asking to include PAM
in LFS will be tarred and feathered. :)
--
JH
Matthew Burgess wrote:
1) Are the utilities and/or interfaces the package provides mandated by
any of the following standards?
* Linux Standard Base (LSB-3.0)
I'd rather not mention this (very strict) standard without reading it.
It requires both other mentioned standards and also UTF-8, P
Jeremy Huntwork wrote:
Matthew Burgess wrote:
Thoughts, comments, suggestions?
I like it. It's essentially all the questions we've been asking already,
but it's nice to have it listed as such. Does this mean we go back and
run all our current packages through the ringer now? :P
Which rem
Matthew Burgess wrote:
> Hi,
>
> During the recent thread on whether or not Cracklib should be introduced
> to LFS, the lack of an official policy on what criteria a package has to
> meet in order to be included in the book was highlighted. So, to
> correct that, I'm going to get the ball rolling
Tushar Teredesai wrote:
On 8/5/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Tushar Teredesai wrote:
FHS is good, not so sure about LSB since it mandates lot more packages
like PAM which are not in LFS.
I didn't read this as "let's go to each of these lists and match
precisely what is good
On 8/5/05, Chris Staub <[EMAIL PROTECTED]> wrote:
> Randy McMurchy wrote:
> > Archaic wrote these words on 08/05/05 00:18 CST:
> >
> >>BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
> >>on exactly one of them. That box also uses PAM, so even it would be
> >>moot.
> >
> >
>
On 8/4/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Something I've thought about for a long time, and now that CrackLib
> is a maintained and stable package, I would like to propose that the
> community consider adding this package to Chapter 6 in the LFS build.
>
I say go ahead a
Robert Russell wrote:
On 8/5/05, Chris Staub <[EMAIL PROTECTED]> wrote:
Randy McMurchy wrote:
Archaic wrote these words on 08/05/05 00:18 CST:
BTW, out of the 70-odd boxes I manage, I would use (and do use) cracklib
on exactly one of them. That box also uses PAM, so even it would be
moot.
Robert Russell wrote:
you finish building LFS on your computer, and decide to celebrate by
going out to eat, a thief breaks into your house and steals your
computer.
True. If the thief wants to get the data though, a strong root password
won't stop him. All he needs to do is boot knoppix or
I have decided to start a weekly status report on the Cross-LFS
development. This report will happen on Fridays.
Current Working Status
All 32 bit builds and Multilib builds are working. Need volunteers to
test and report any issues during the build
All builds need wordsmithing, so anyone who'
Alexander E. Patrakov wrote:
Mirrors for the ISO images are more than welcome.
Great work!
The no-source image is already copied and the full source one is almost
done. So these mirrors also available (full source iso in about 30
minutes):
Montreal, Canada:
ftp://ftp.lfs-matrix.net/pub/l
Justin R. Knierim wrote:
However the users of the LFS system are varying. A user who built LFS
for the educational value or who wants a different password library or
who uses it on a stand-alone system, shouldn't have to install a
password library if it isn't needed/wanted/required.
I agre
i'm usually just a lurker here, but as someone who remembers the first
time using the book, i would have to vote against it being added
directly, though i do strongly agree with the hint idea. to me, it
seems that it belongs more in BLFS where it already exists, but either
with a without pam note
Randy McMurchy wrote:
Hi all,
Hi Randy and All. First, I want to thank all participants to this
thread for keeping it civil. I am so glad we could do that.
My opinion/vote is -1. I feel that technically speaking, Randy, your
idea is fine. It is good to have a more secure system. I also f
34 matches
Mail list logo
