Re: [lfs-support] Unable to login SOLVED

[hans kaper]

Op Fri, 04 Oct 2013 23:13:20 +0200 schreef Bruce Dubbs :


>>
>> Then: strace -olog.txt login
>>
>
>
> I looked at a trace for my system.  Do you have /etc/group?  These are
> my opens, disregarding library and files not found:
>
> open("/etc/login.defs", O_RDONLY)   = 3

> open("/root/.bash_history", O_RDONLY)   = 3
>
The last part of the list of files were not opened because login did not come 
that far.

> Check that login.defs, nsswitch.conf, passwd, login.access, and group
> all exist.  Note that shadow is not opened.

Because you use no password?

All the files are there.

I copied passwd, groups and shadow from my succesful build of LFS7_3 to LFS7_4, 
but no log-in, although a different error-message.

Then, in the end, I re-installed Shadow et voila: a successful login!

Analysing the logs, I saw no differences with the first install, apart from 
installs by libtool from /usr/bin/install instead of /tools/bin/install, but 
that shall originate from the fact that in the first build  libtool was build 
after Shadow.

That leaves the question why the failures occurred in the first place? Any 
suggestion were I should look in the strace-logfiles to get a clue? LFS is for 
learning, he?
The login-failure occurred after the password was given. In the successful 
login login.access was opened, but that was not the case in the failed login, 
although /etc/login.access existed. There was also no failure of opening that 
file.


But again, Bruce, I am, very grateful for your extensive help!!



Hans.



-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] Unable to login SOLVED

[Bruce Dubbs]

hans kaper wrote:
> Op Fri, 04 Oct 2013 23:13:20 +0200 schreef Bruce Dubbs 
> :
>
>
>>>
>>> Then: strace -olog.txt login
>>>
>>
>>
>> I looked at a trace for my system.  Do you have /etc/group?  These are
>> my opens, disregarding library and files not found:
>>
>> open("/etc/login.defs", O_RDONLY)   = 3
> 
>> open("/root/.bash_history", O_RDONLY)   = 3
>>
> The last part of the list of files were not opened because login did not come 
> that far.
>
>> Check that login.defs, nsswitch.conf, passwd, login.access, and group
>> all exist.  Note that shadow is not opened.
>
> Because you use no password?

Not normally.  I just did it to check things for you.

> All the files are there.
>
> I copied passwd, groups and shadow from my succesful build of
> LFS7_3 to LFS7_4,

Yes, I do that all the time. Also gshadow, bashrc, profile{,.d}, vimrc, 
dircolors, inputrc, and a few others.  But that's off topic.

but no log-in, although a different error-message.
>
> Then, in the end, I re-installed Shadow et voila: a successful login!

There you go.

> Analysing the logs, I saw no differences with the first install,
apart from installs by libtool from /usr/bin/install
instead of /tools/bin/install, but that shall originate
from the fact that in the first build  libtool was build after Shadow.

Yes, that's reasonable.

>
> That leaves the question why the failures occurred in the first place?
Any suggestion were I should look in the strace-logfiles to get a clue?
LFS is for learning, he?

Yes.

> The login-failure occurred after the password was given.
In the successful login login.access was opened, but that was
not the case in the failed login, although /etc/login.access existed.
There was also no failure of opening that file.

My only guess would be that something was either not installed or 
installed in the wrong place the first time around.

In the end, the only way to really analyze what was going on is to look 
at the source code.  Obviously the login program was executing.  Follow 
the source after you typed the username and see if you can correlate 
that to the strace logs.  That's about the only suggestion I can offer 
at this point.  Look at src/login_nopam.c and src/login.c

> But again, Bruce, I am, very grateful for your extensive help!!

No problem.

   -- Bruce


-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] More control and package management using package users

[Dan McGhee]

On 10/04/2013 01:57 PM, Rob Taylor wrote:
I have updated the wrapper scripts to handle some new chmod 
functionality. It now supports OCTAL-MODEs that are longer than 4 
digits or have preceding @ signs.
See: 
https://lists.gnu.org/archive/html/bug-coreutils/2012-03/txtWUJXdGwYNs.txt
Where it says: " chmod, mkdir, install now accept new style of octal 
mode specification. When octal mode is preceeded by @ or is 5+ digits 
long with leading zeros, it can clear the set user id and set group id 
bits on directories."


Get the latest "more_control_helpers.tar.xz" file from 
https://www.javacrypt.com/lfs/


Thanks,
Robert Taylor


On Mon, Sep 23, 2013 at 2:08 PM, Rob Taylor > wrote:


Thanks for the link Hans.


On Mon, Sep 23, 2013 at 12:51 PM, hans kaper mailto:spaky...@xs4all.nl>> wrote:

Op Mon, 23 Sep 2013 21:05:01 +0200 schreef Rob Taylor
mailto:rtaylor...@gmail.com>>:


I have been working through LFS 7.2, 7.3 and 7.4 testing
and revising scripts for this package management system.

I have added a number of scripts and in some cases almost
entirely rewritten the existing scripts. While I have
tested these scripts no one else has so, my version of
this package should be considered Alpha or Beta at best.

You can play with the revised project and see my notes here:
https://www.javacrypt.com/lfs/


Another interesting piece of work on this subject you can find
at https://github.com/ericherman/package-users.
There was also a discussion on this subject on this support
site about two years ago, initiated by Drew Ames.


Robert--
Great job on this hint!  I've used it since .the first time I ever built 
LFS.  After a hiatus, I'm gearing up to do another build and saw this 
e-mail.


I read your "new" hint, comparing it to the old one, and reviewed your 
scripts, build and build.conf. They are really, really elegant.  I'm 
impressed.


I have some questions and comments.

1.  My first comment is constructive criticism.  You have not taken 
credit for your work, either in becoming the maintainer nor in the 
improvements you've made.  I urge you to identify yourself as maintainer 
at the beginng of the hint and take credit for your improvements in the 
Change Log.


2.  Is it a personal preference to us AUFS? Or is there a technical 
motivation?


3.  Is there something other than making a "pretty prompt" in the 
terminal that you added INPUTRC to a user's environment?


4.  The last sentence of Section 5.10 "ldconfig.c" says, "Because it 
doesn't evaluate any user input and doesn't pass any user-provided data 
to ldconfig, it can safely be made setuid root. I'm assuming that the 
first "it" refers to ldconfig.c and the second "it" refers to ldconfig.  
Is that corrrect? If it is, I recommend changing the end of that 
sentence to read, "...ldconfig, which can, then, safely be made setuid 
root."


5. Do you install 'shadow' as the first package after chroot so that you 
could get "su?" If so, since the hint tells you to copy 'su' to 
/tools/bin in Ch. 5, I'm wondering what advantage there is, especially 
since it causes some "hiccups" down the road.  But, then, that may 
merely be an approach different to mine.


6. And that's a good segue to this comment. You designed your build 
script to continue through to completion regardless of errors--at least 
that's what I think I got from reading your build notes. I've found that 
unless I make a dumb mistake--copy and paste takes care of most of those 
:)--the only interrupts I had were about the lack of install_dirs or 
permissions like '-o root'  I've written a build script which is not 
nearly as elegant as yours, but recovers from failed "make" and "make 
install." That way, I can fix problems as they occur.  When the build 
completes, then, I'm done and don't have to do anything extra with 
errors.  Mine also "pauses" after running a test suite so that you can 
examine the results in a text window before proceeding. [interruption] 
Think I'll add that pause after 'configure' and 'make' so I can review 
*.err logs.[/interruption]


If you don't mind, I'm going to plagiarize some of your ideas to "spruce 
up" my script.  I will send youthe script as it exists now, while I'm 
plagiarizing :) , if you'd like to review it.


Lastly, Hans talked about a discussion on this list a few years ago.  I 
was part of that along with Drew.  We were exchanging many, many ideas.  
One of those was "version management" for upgrades.  If he's still 
around, I hope he jumps in here.


I hope you have not reacted negatively to anything I've said here.  You 
have done a great job.  Thanks.


Dan

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Re: [lfs-support] More control and package management using package users

[Rob Taylor]

Hi Dan,
Thanks for the feedback. I'm just on vacation for a couple of weeks to
Hawaii, the big island. So I may not seem very responsive to emails for a
bit.

Feel free to change or use anything I have created. I didn't really take
over the hint, partially because I am not sure how much time I will have to
put into supporting it. But I did work on the wrapper scripts because I
tried out this user package management idea and I could see room for
improvement. Anything you or anyone else can add to improve this project is
welcome.

re: 1 and 5...  I didn't alter the text of the hint itself (supplied on the
http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txtpage),
I believe that there are lots of changes required now, including
installing shadow before section "6.7. Linux-3.11 API Headers" in order to
get the su command. Su no longer exists in coreutils so copying it in
section 5 can not occur. I see from the other effort mentioned here
https://github.com/ericherman/package-users that he suggests installing
shadow into the /tools area instead of /usr. That would make sense to avoid
any collision of files later when the normal shadow install occurs. I
thought about changing
my_lfs_7_4_notes.txtto
use that approach but then decided that the example of how to deal
with
file overwrite issues is a useful demonstration of the scripts handling of
these issues.

2. I installed AUFS in my project because I have fantasies of creating a
Puppy like project using LFS. AUFS is used by Puppy Linux along with squash
fs in order to load the operating system, optional software packages and a
personal files layer as separate layers of the file system. So changes to
personal files or installing of programs by an end user can be entirely
undone because it does not overwrite the OS layer, which is loaded as a
read only AUFS layer.

3. It may only be on my hardware, but I had to add some other code to the
INPUTRC to support my home and end key codes:

# for my box
"\e[8~": end-of-line
"\e[7~": beginning-of-line

4. I didn't create that text so, if it makes sence to change the
wording that sounds good :)

6. The build script will still quit after a section such as the "check"
fails. What I was referring to is that rather than a command such as

install -c -m04755 -o root -g root ../../sourcefilename /sbin

failing and causing the entire "make install" to fail because the
package user does not have permissions to run it,

my wrapper scripts will filter out the -o root -g root and will alter
the -m04755 to be -m755 and will create a log
of the command as it was before and after modification, present
working directory when the command ran, any errors returned from
the command if it was run and in doing so the "make install" will
continue to run through to completion installing any and all
files that would have been run after the failure. So when you are all
done with a successful install, all you need to do is
examine the logs to see the list of files that you may or may not want
to make SetUID or SetGID root etc..

My wrapper scripts will also examine any issues of ownership of files,
log those issues and skip the specfic command that would
have generated a permission error so that the "make install" will
continue as far as possible generating a complete list of these
files with ownership issues so that a single chown command can be run
to fix all these permissions issues before rerunning
"make install" again without issue. You really would have to
experience the process to appreaciate what I mean. Also, suppose you
don't
want this package to have replaced those specific files where there
was an overwrite situation? In this case if the overwrites
(which are logged for reveiew) are the only issue with an install and
the install completed with a result of success, you can simply move
on.


This is much more seamless than having to edit "Makefile.in" files
removing or fixing offending entries and running
"make install" over and over again until it finally succeeds. Or
moving files you want to "save" so that a "make install" can succeed
just
to have to move those saved files back again as root overwritting the
newly installed files with the ones you wanted to keep etc..

You can always run the build script with a list of phases as options
to step through the install at your own pace. But then the ./build
script itself is open to change as well if you like.

Version control is a good idea. I see git is being used by ericherman
 which is fine. I have exprience with
SVN personally.

Thanks again for your feedback, I hope I didn't miss addressing any of
your points.

Take Care,
Robert Taylor

P.S. my spell checker seems to be broke sorry for any errors etc.








On Sat, Oct 5, 2013 at 2:09 PM, Dan McGhee  wrote:

>  On 10/04/2013 01:57 PM, Rob Taylor wrote:
>
>   I have updated the wrapper scripts to handle some new chmod
> func