Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On 12/31/2009 05:25 PM, stosss wrote: At the bottom of the page for shadow in the BLFS svn book latest and earlier versions. Is this note talking about a step that was done or needs to be done? Note ENV_SUPATH is no longer supported. You must create a valid /root/.bashrc file to provide a modified path for the super-user. I don't think it's in any way unclear, but I'll explain anyway... ENV_SUPATH is an option in /etc/login.defs, specifying the default PATH for the root user. However, the Shadow page in BLFS assumes you are rebuiding Shadow with PAM support, and if you are using PAM, ENV_SUPATH no longer does anything. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
At the bottom of the page for shadow in the BLFS svn book latest and earlier versions. Is this note talking about a step that was done or needs to be done? Note ENV_SUPATH is no longer supported. You must create a valid /root/.bashrc file to provide a modified path for the super-user. I don't think it's in any way unclear, but I'll explain anyway... ENV_SUPATH is an option in /etc/login.defs, specifying the default PATH for the root user. However, the Shadow page in BLFS assumes you are rebuiding Shadow with PAM support, and if you are using PAM, ENV_SUPATH no longer does anything. I got that. Is it telling about a process that was done in the steps above on the shadow page _or_ is it telling about something that still needs (or might need) to be done? -- I think the note means that the variable is defined in the file, but has no effect when using PAM. The note names one possible workaround to modify the super-user path when using shadow with PAM support. ENV_SUPATH exists in /etc/login.defs but does not do or cause any behavior. So the note mentions a step that has not yet been performed nor is described in detail. That is what I thought. If the authors thought it was necessary to make the note, then why not say if the undescribed step is important or what possible problems might be seen by not doing the step? Why not explain how to do the step? If not doing the step won't cause any problem then why mention it at all? -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On 01/05/2010 03:58 PM, stosss wrote: I don't think it's in any way unclear, but I'll explain anyway... ENV_SUPATH is an option in /etc/login.defs, specifying the default PATH for the root user. However, the Shadow page in BLFS assumes you are rebuiding Shadow with PAM support, and if you are using PAM, ENV_SUPATH no longer does anything. I got that. Is it telling about a process that was done in the steps above on the shadow page _or_ is it telling about something that still needs (or might need) to be done? It looks like you're overthinking things and reading more into what's on the page then what's there. It's referring to exactly what is done on that page - configuring Shadow to use PAM. In particular, it follows up on the previous note about the regular path now being handled by a PAM module and configured in a .conf file - it's just that there apparently isn't any PAM config for the superuser specifically, so the additional note was added about adding to root's .bashrc. Though I could also point out that if you look at that long sed command that modifies login.defs by commenting out a bunch of vars (see the command under the Configuring /etc/login.defs section), you'll see that ENV_SUPATH is on the list... Then there's the NOTE immediately after Shadow is installed: The rest of this page is devoted to configuring Shadow to work properly with Linux-PAM. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
It looks like you're overthinking things and reading more into what's on the page then what's there. It's referring to exactly what is done on that page - configuring Shadow to use PAM. In particular, it follows up on the previous note about the regular path now being handled by a PAM module and configured in a .conf file - it's just that there apparently isn't any PAM config for the superuser specifically, so the additional note was added about adding to root's .bashrc. Adding _what_ (and how) to root's .bashrc? -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On 01/05/2010 05:16 PM, stosss wrote: It looks like you're overthinking things and reading more into what's on the page then what's there. It's referring to exactly what is done on that page - configuring Shadow to use PAM. In particular, it follows up on the previous note about the regular path now being handled by a PAM module and configured in a .conf file - it's just that there apparently isn't any PAM config for the superuser specifically, so the additional note was added about adding to root's .bashrc. Adding _what_ (and how) to root's .bashrc? Pasted from the Note in question: You must create a valid /root/.bashrc file to provide a modified path for the super-user. Therefore, to your question of what to add to root's .bashrc - it's a modified path. You know, since root generally has additional dirs in its PATH (such as /sbin and /usr/sbin). -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
You must create a valid /root/.bashrc file to provide a modified path for the super-user. Therefore, to your question of what to add to root's .bashrc - it's a modified path. You know, since root generally has additional dirs in its PATH (such as /sbin and /usr/sbin). I understand that but you said the note was clear. It is not at all clear. You must(doesn't say why you must. Must is strong. Where is the cause and effect?) create a valid /root/.bashrc file to provide a modified path(what should that modified path look like?) for the super-user. The note has the appearance of something important without giving supporting detail as to why it is important. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
iptables-1.3.8 BLFS book svn-20100105 compile error
tar -xvf iptables-1.3.8.tar.bz2 cd iptables-1.3.8 sed -i 's/name=$node/name=node/' iptables.xslt make LIBDIR=/lib KERNEL_DIR=/usr 21 | tee ../iptables.log Making dependencies: please wait... Extensions found: IPv4:NFLOG IPv4:connbytes IPv4:dccp IPv4:quota IPv4:recent IPv4:string IPv6:NFLOG IPv6:REJECT IPv6:esp IPv6:hashlimit IPv6:mh IPv6:sctp cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c cc -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_addrtype_sh.o -c extensions/libipt_addrtype.c cc -shared -o extensions/libipt_addrtype.so extensions/libipt_addrtype_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_comment_sh.o -c extensions/libipt_comment.c cc -shared -o extensions/libipt_comment.so extensions/libipt_comment_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_connmark_sh.o -c extensions/libipt_connmark.c cc -shared -o extensions/libipt_connmark.so extensions/libipt_connmark_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_conntrack_sh.o -c extensions/libipt_conntrack.c cc -shared -o extensions/libipt_conntrack.so extensions/libipt_conntrack_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_dscp_sh.o -c extensions/libipt_dscp.c cc -shared -o extensions/libipt_dscp.so extensions/libipt_dscp_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_ecn_sh.o -c extensions/libipt_ecn.c cc -shared -o extensions/libipt_ecn.so extensions/libipt_ecn_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_esp_sh.o -c extensions/libipt_esp.c cc -shared -o extensions/libipt_esp.so extensions/libipt_esp_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_hashlimit_sh.o -c extensions/libipt_hashlimit.c cc -shared -o extensions/libipt_hashlimit.so extensions/libipt_hashlimit_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_helper_sh.o -c extensions/libipt_helper.c cc -shared -o extensions/libipt_helper.so extensions/libipt_helper_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_icmp_sh.o -c extensions/libipt_icmp.c cc -shared -o extensions/libipt_icmp.so extensions/libipt_icmp_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_iprange_sh.o -c extensions/libipt_iprange.c cc -shared -o extensions/libipt_iprange.so extensions/libipt_iprange_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_length_sh.o -c extensions/libipt_length.c cc -shared -o extensions/libipt_length.so extensions/libipt_length_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_limit_sh.o -c extensions/libipt_limit.c cc -shared -o extensions/libipt_limit.so extensions/libipt_limit_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_mac_sh.o -c extensions/libipt_mac.c extensions/libipt_mac.c: In function 'print': extensions/libipt_mac.c:107: warning: dereferencing type-punned pointer will break strict-aliasing rules extensions/libipt_mac.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules extensions/libipt_mac.c: In function 'save': extensions/libipt_mac.c:116: warning: dereferencing type-punned pointer will break strict-aliasing rules extensions/libipt_mac.c:120: warning: dereferencing type-punned pointer will break strict-aliasing rules cc -shared -o extensions/libipt_mac.so extensions/libipt_mac_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_mark_sh.o -c extensions/libipt_mark.c cc -shared -o extensions/libipt_mark.so extensions/libipt_mark_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_multiport_sh.o -c extensions/libipt_multiport.c cc -shared -o extensions/libipt_multiport.so extensions/libipt_multiport_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_owner_sh.o -c extensions/libipt_owner.c cc -shared -o extensions/libipt_owner.so extensions/libipt_owner_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.8\ -fPIC -o extensions/libipt_physdev_sh.o -c extensions/libipt_physdev.c cc -shared -o extensions/libipt_physdev.so extensions/libipt_physdev_sh.o cc -O2 -Wall
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
On 05/01/10 23:41, stosss wrote: tar -xvf iptables-1.3.8.tar.bz2 etc Have you tried using a more recent version of iptables? Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
tar -xvf iptables-1.3.8.tar.bz2 etc Have you tried using a more recent version of iptables? No, I will try that. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On Tue, 2010-01-05 at 17:16 -0500, stosss wrote: It looks like you're overthinking things and reading more into what's on the page then what's there. It's referring to exactly what is done on that page - configuring Shadow to use PAM. In particular, it follows up on the previous note about the regular path now being handled by a PAM module and configured in a .conf file - it's just that there apparently isn't any PAM config for the superuser specifically, so the additional note was added about adding to root's .bashrc. Adding _what_ (and how) to root's .bashrc? Adding whatever you were previously using ENV_SUPATH for. If you weren't previously using ENV_SUPATH, you've got nothing to worry about. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On Tue, 2010-01-05 at 17:21 -0500, Chris Staub wrote: Pasted from the Note in question: You must create a valid /root/.bashrc file to provide a modified path for the super-user. Therefore, to your question of what to add to root's .bashrc - it's a modified path. You know, since root generally has additional dirs in its PATH (such as /sbin and /usr/sbin). Reading that, I think he's actually got a fair point. The intended meaning is that if you were previously using ENV_SUPATH to give root a different PATH from ordinary users, you would now need to do so by modifying root's login scripts. But if you read that note, it starts by assuming the reader actually knows what ENV_SUPATH is, and why it being no longer supported means they have to create a suitable .bashrc file. If they don't know what ENV_SUPATH is, they're merely left with a cryptic instruction to create a .bashrc file with unspecified content. And consider, ENV_SUPATH isn't mentioned in the LFS shadow page, and only mentioned in this page in the context of saying it can't be used. A typical LFS builder is *not* going to know what that message means. A better wording would perhaps be something like: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. To me, that explains what it does, and makes it clear that if you don't use it, you don't need to do anything. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On 01/05/2010 09:47 PM, Simon Geard wrote: Reading that, I think he's actually got a fair point. The intended meaning is that if you were previously using ENV_SUPATH to give root a different PATH from ordinary users, you would now need to do so by modifying root's login scripts. But if you read that note, it starts by assuming the reader actually knows what ENV_SUPATH is, and why it being no longer supported means they have to create a suitable .bashrc file. If they don't know what ENV_SUPATH is, they're merely left with a cryptic instruction to create a .bashrc file with unspecified content. And consider, ENV_SUPATH isn't mentioned in the LFS shadow page, and only mentioned in this page in the context of saying it can't be used. A typical LFS builder is *not* going to know what that message means. A better wording would perhaps be something like: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. To me, that explains what it does, and makes it clear that if you don't use it, you don't need to do anything. Simon. Yeah, I suppose it's would be reasonable to specify what ENV_SUPATH does. I think I just let myself get carried away with emphasizing the when is it needed part and didn't see that yes, he does have a point about explaining what that var does. Although, If you are using this option would likely not be necessary, as it's part of the default login.defs, so it would pretty much be used by everyone. Otherwise, anyone who is using it would add it themselves, in which case they wouldn't need to be told what it's for. So...yeah, the fact that the user never even creates it themselves would be a valid reason to explain exactly what it's for. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On Tue, Jan 5, 2010 at 9:47 PM, Simon Geard delga...@ihug.co.nz wrote: On Tue, 2010-01-05 at 17:21 -0500, Chris Staub wrote: Pasted from the Note in question: You must create a valid /root/.bashrc file to provide a modified path for the super-user. Therefore, to your question of what to add to root's .bashrc - it's a modified path. You know, since root generally has additional dirs in its PATH (such as /sbin and /usr/sbin). Reading that, I think he's actually got a fair point. The intended meaning is that if you were previously using ENV_SUPATH to give root a different PATH from ordinary users, you would now need to do so by modifying root's login scripts. But if you read that note, it starts by assuming the reader actually knows what ENV_SUPATH is, and why it being no longer supported means they have to create a suitable .bashrc file. If they don't know what ENV_SUPATH is, they're merely left with a cryptic instruction to create a .bashrc file with unspecified content. And consider, ENV_SUPATH isn't mentioned in the LFS shadow page, and only mentioned in this page in the context of saying it can't be used. A typical LFS builder is *not* going to know what that message means. A better wording would perhaps be something like: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. To me, that explains what it does, and makes it clear that if you don't use it, you don't need to do anything. Thanks Simon for making this clear. It had no useful meaning to me the way it is currently written. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
Reading that, I think he's actually got a fair point. The intended meaning is that if you were previously using ENV_SUPATH to give root a different PATH from ordinary users, you would now need to do so by modifying root's login scripts. But if you read that note, it starts by assuming the reader actually knows what ENV_SUPATH is, and why it being no longer supported means they have to create a suitable .bashrc file. If they don't know what ENV_SUPATH is, they're merely left with a cryptic instruction to create a .bashrc file with unspecified content. And consider, ENV_SUPATH isn't mentioned in the LFS shadow page, and only mentioned in this page in the context of saying it can't be used. A typical LFS builder is *not* going to know what that message means. A better wording would perhaps be something like: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. To me, that explains what it does, and makes it clear that if you don't use it, you don't need to do anything. Simon. Yeah, I suppose it's would be reasonable to specify what ENV_SUPATH does. I think I just let myself get carried away with emphasizing the when is it needed part and didn't see that yes, he does have a point about explaining what that var does. Although, If you are using this option would likely not be necessary, as it's part of the default login.defs, so it would pretty much be used by everyone. Otherwise, anyone who is using it would add it themselves, in which case they wouldn't need to be told what it's for. So...yeah, the fact that the user never even creates it themselves would be a valid reason to explain exactly what it's for. Thank you! That is all I was trying to accomplish when I asked my original question. There are parts of the LFS and BLFS book written in a way that leaves less experienced users scratching their head wondering what they just read because it is written on the assumption the reader already knows the subject matter and that is not true 100% of the time. Then when authors or users defend the poorly written parts that just makes it worse. I will bet that is the reason most of the time for the conflict between new comers with less experience and those with more. The LFS project says the books are for learning. If something is written so less experienced users don't understand then change those parts. Don't get defensive and attack the person asking about them. It happens all the time on the LFS list and it happened to me the very first time I posted on this list. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On Tue, Jan 05, at 10:27 Chris Staub wrote: On 01/05/2010 09:47 PM, Simon Geard wrote: Reading that, I think he's actually got a fair point. The intended meaning is that if you were previously using ENV_SUPATH to give root a different PATH from ordinary users, you would now need to do so by modifying root's login scripts. But if you read that note, it starts by assuming the reader actually knows what ENV_SUPATH is, and why it being no longer supported means they have to create a suitable .bashrc file. If they don't know what ENV_SUPATH is, they're merely left with a cryptic instruction to create a .bashrc file with unspecified content. And consider, ENV_SUPATH isn't mentioned in the LFS shadow page, and only mentioned in this page in the context of saying it can't be used. A typical LFS builder is *not* going to know what that message means. A better wording would perhaps be something like: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. To me, that explains what it does, and makes it clear that if you don't use it, you don't need to do anything. Simon. Yeah, I suppose it's would be reasonable to specify what ENV_SUPATH does. I think I just let myself get carried away with emphasizing the when is it needed part and didn't see that yes, he does have a point about explaining what that var does. Although, If you are using this option would likely not be necessary, as it's part of the default login.defs, so it would pretty much be used by everyone. Otherwise, anyone who is using it would add it themselves, in which case they wouldn't need to be told what it's for. So...yeah, the fact that the user never even creates it themselves would be a valid reason to explain exactly what it's for. I think that the following note is more than enough and it looks quite clear. Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. You have to set the path in root's login scripts instead. I will commit it in a second. Thanks. Regards, Agathoklis. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. This one is clear. Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. You have to set the path in root's login scripts instead. This one is not clear. If you are using this option, Is what makes it clear. If a user does not understand or use ENV_SUPATH they won't be concerned with the note if it has the part in it that you pulled out. If a user is using and understands ENV_SUPATH they will know they need to make adjustments. Why complicate things for the less experienced readers when it is not necessary? This note won't bother me again because I have been educated thanks to Simon. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On 01/05/2010 11:34 PM, stosss wrote: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. This one is clear. Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. You have to set the path in root's login scripts instead. This one is not clear. If you are using this option, Is what makes it clear. If a user does not understand or use ENV_SUPATH they won't be concerned with the note if it has the part in it that you pulled out. I already pointed this out. Basically, I believe the opposite - adding if you are using makes it *less* clear, as *everyone* uses it by default, even if they don't know it. If a user is using and understands ENV_SUPATH they will know they need to make adjustments. And as I already pointed out, if the if you are using part were there, that would imply that ENV_SUPATH is something added by the user (which it is NOT) and therefore anyone who did use it wouldn't need it explained anyway. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
The configuration for iptables-1.4.6 is a lot different then iptables-1.3.8
I tried iptables-1.3.8 three times with the same error result each time.
I am going to try iptables-1.4.6 unless someone has a good reason why
I should not just yet.
I am going to do it like this.
./configure --prefix=/usr
make
make install
Can any one see a problem with using this newer one in a LFS6.5/BLFS svn build?
Will this one cause a problem with the current boot scripts?
below is the install file for iptables-1.4.6
Installation instructions for iptables
==
iptables uses the well-known configure(autotools) infrastructure.
$ ./configure
$ make
# make install
Prerequisites
=
* no kernel-source required
* but obviously a compiler, glibc-devel and linux-kernel-headers
(/usr/include/linux)
Configuring and compiling
=
./configure [options]
--prefix=
The prefix to put all installed files under. It defaults to
/usr/local, so the binaries will go into /usr/local/bin, sbin,
manpages into /usr/local/share/man, etc.
--with-xtlibdir=
The path to where Xtables extensions should be installed to. It
defaults to ${prefix}/libexec/xtables.
--enable-devel (or --disable-devel)
This option causes development files to be installed to
${includedir}, which is needed for building additional packages,
such as Xtables-addons or other 3rd-party extensions.
It is enabled by default.
--enable-static
Produce additional binaries, iptables-static/ip6tables-static,
which have all shipped extensions compiled in.
--disable-shared
Produce binaries that have dynamic loading of extensions disabled.
This implies --enable-static.
(See some details below.)
--enable-libipq
This option causes libipq to be installed into ${libdir} and
${includedir}.
--with-ksource=
Xtables does not depend on kernel headers anymore, but you can
optionally specify a search path to include anyway. This is
probably only useful for development.
If you want to enable debugging, use
./configure CFLAGS=-ggdb3 -O0
(-O0 is used to turn off instruction reordering, which makes debugging
much easier.)
Other notes
===
The make process will automatically build multipurpose binaries.
These have the core (iptables), -save, -restore and -xml code
compiled into one binary, but extensions remain as modules.
Static and shared
=
Basically there are three configuration modes defined:
--disable-static --enable-shared (this is the default)
Build a binary that relies upon dynamic loading of extensions.
--enable-static --enable-shared
Build a binary that has the shipped extensions built-in, but
is still capable of loading additional extensions.
--enable-static --disable-shared
Shipped extensions are built-in, and dynamic loading is
deactivated.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
On 01/06/2010 12:11 AM, stosss wrote: The configuration for iptables-1.4.6 is a lot different then iptables-1.3.8 I tried iptables-1.3.8 three times with the same error result each time. I am going to try iptables-1.4.6 unless someone has a good reason why I should not just yet. I am going to do it like this. ./configure --prefix=/usr make make install Can any one see a problem with using this newer one in a LFS6.5/BLFS svn build? Will this one cause a problem with the current boot scripts? See suggested instructions for current iptables here - http://wiki.linuxfromscratch.org/blfs/ticket/2714 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
The configuration for iptables-1.4.6 is a lot different then iptables-1.3.8 I tried iptables-1.3.8 three times with the same error result each time. I am going to try iptables-1.4.6 unless someone has a good reason why I should not just yet. I am going to do it like this. ./configure --prefix=/usr make make install Can any one see a problem with using this newer one in a LFS6.5/BLFS svn build? Will this one cause a problem with the current boot scripts? See suggested instructions for current iptables here - http://wiki.linuxfromscratch.org/blfs/ticket/2714 Thank you -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: iptables-1.3.8 BLFS book svn-20100105 compile error
If the following modprobes are built into the kernel and not modules, should I comment out the modprobes below as in my sample below? cat /etc/rc.d/rc.iptables EOF #!/bin/sh # Begin $rc_base/rc.iptables # Insert connection-tracking modules # (not needed if built into the kernel) # modprobe ip_tables # modprobe iptable_filter # modprobe ip_conntrack # modprobe ip_conntrack_ftp # modprobe ipt_state # modprobe ipt_LOG Is this correct or can it just be left alone like this? cat /etc/rc.d/rc.iptables EOF #!/bin/sh # Begin $rc_base/rc.iptables # Insert connection-tracking modules # (not needed if built into the kernel) modprobe ip_tables modprobe iptable_filter modprobe ip_conntrack modprobe ip_conntrack_ftp modprobe ipt_state modprobe ipt_LOG -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS svn book Shadow-4.1.4.2 question about a page note
On Tue, Jan 05, at 11:34 stosss wrote: Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. If you are using this option, you'll need to set the path in root's login scripts instead. This one is clear. Note: The ENV_SUPATH option used to modify root's default path does not work with PAM. You have to set the path in root's login scripts instead. This one is not clear. If you are using this option, Is what makes it clear. By that it looks to me, that we are some kind of a project, that we are caring about our customers (an already established audience). It sounds like the note to be intended for *experienced* users, which is quite the opposite from what you say a little bit bellow to your email. If a user does not understand or use ENV_SUPATH they won't be concerned with the note if it has the part in it that you pulled out. But we expect from the readers (which is a little bit different than to say users), to understand and to be concerned with everything it is written in the books. That is our purpose. As far the ENV_SUPATH, we want from the reader to understand its importance, otherwise we wouldn't sacrifice a valuable space in the page with a note that will (probably) make the page more complicated and bloated, and you know what: somehow this page it is already complicated. But the shadow suite is really important, because it concerns security. If a user is using and understands ENV_SUPATH they will know they need to make adjustments. Why complicate things for the less experienced readers when it is not necessary? Honestly, we are not trying to complicated things on purpose, as a matter of fact, we are trying to clarify and improve the wording when it is possible, and anyway that is the meaning of this discussion, and let me say that: I could be wrong and you could be right and perhaps later on, I can understand the difference in the small details and change the note accordingly. This note won't bother me again because I have been educated thanks to Simon. Seriously: then our mission is complete and we are very happy for that. Regards, Agathoklis. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
