This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: man.conf missing after cygwin upgrade (Attn: User's Guide maintainer)


> > ~ $ getfacl /usr /usr/share /usr/share/misc
> > # file: /usr
> > # owner: Administrators
> > # group: mkpasswd
>     ^^^^^^^^^^^^^^^
> > user::rwx
> > group::---
>   ^^^^^^^^^^
> > group:SYSTEM:rwx
> > mask:rwx
> > other:---
> > default:user:Administrators:rwx
> > default:group:SYSTEM:rwx
> > default:mask:rwx
> >
> > # file: /usr/share
> > # owner: Administrators
> > # group: mkpasswd
>     ^^^^^^^^^^^^^^^
> > user::rwx
> > group::---
>   ^^^^^^^^^^
> > group:SYSTEM:rwx
> > mask:rwx
> > other:---
> > default:user:Administrators:rwx
> > default:group:SYSTEM:rwx
> > default:mask:rwx
> Well, the underlined lines above (those that say "group: mkpasswd") do
> look problematic -- your /etc/passwd and /etc/group aren't up-to-date.
> I'd investigate what the actual group of those files is, and 
> regenerate
> your mkpasswd (are you in a domain, by any chance?).

Yes, I am.

I have just recently (i.e. after the setup) re-created both /etc/group
and
/etc/passwd. With /etc/group, I did a

  mkgroup -l -d >/etc/group

not nowing that this would really scan all my domain, so after more than
half
an hour, I'm ending with a /etc/group file containing nearly 30000
lines.
With mkpasswd, I then made only a 

  mkpasswd >/etc/passwd

Incidentally, a group named "mkpasswd" does not exist. Do you think I
should
do a chgrp to all directories below / which now have group mkpasswd?
What
group would be suitable? Maybe Administrators?

$ mkgroup -l
SYSTEM:S-1-5-18:18:
None:S-1-5-21-602162358-162531612-725345543-513:513:
Administrators:S-1-5-32-544:544:
Backup Operators:S-1-5-32-551:551:
Guests:S-1-5-32-546:546:
Power Users:S-1-5-32-547:547:
Replicator:S-1-5-32-552:552:
Users:S-1-5-32-545:545:
Debugger Users:S-1-5-21-602162358-162531612-725345543-1001:1001:


> The other underlined lines ("group:---") may be a problem too, just
> because the directories are owned by a Windows *group*.  

OK, I have chmod'ed this to 0777.

> It's also
> possible that the ownership by a group confuses directory permission
> inheritance, so that you end up with 000 permissions plus a couple of
> ACLs (that aren't picked up by Unix tools like "stat"/"test").

This makes sense to me. I didn't know that permissions are inherited
from
the parent directory. Is this a Windoze feature?

> > Just to mention a few, the following postinstall files were 
> *not* run
> > according to the log file:
> >
> > cygfile:///etc/postinstall/base-files-mketc.sh
> 
> This one did, but didn't complete.

But shouldn't then in the logfile be an entry "running
postinstall/base-files-mketc.sh" ?

> > cygfile:///etc/postinstall/man.sh
> > cygfile:///etc/postinstall/pdksh.sh
> > cygfile:///etc/postinstall/wget.sh
> > cygfile:///etc/postinstall/update-info-dir.sh
> 
> Yep, these didn't run.  There are more in your postinstall directory
> below.

You mean: All where a sh file, but no corresponding "done" file is in
the 
postinstall directory?

> I noticed that your log has many "Scheduled reboot 
> replacement" lines --
> you had Cygwin processes running while installing.  

Yes, this is correct. I have always some bash shells open. But after the
setup
was finished (and I didn't get any error message from the setup script),
I
restarted the system.

One bash file is opened by Windows autostart. Could this interfere with
the 
post-install?

> I suspect 
> the problem
> with postinstall scripts is that the emacs one popped up some Windows
> message boxes (e.g., "Entrypoint... not found"), and thus 
> setup didn't run
> the others.
> 
> Did setup recommend that you reboot?  

Yes

> Did you?

Yes

> > Do you recommend that I run all the other postinstall 
> scripts manually,
> > like I did with man.sh?
> 
> After a reboot, yes, I'd suggest running the scripts (you may even try
> reinstalling the affected packages via setup).  See below for a list.

Yes, I think re-running setup is the cleanest solution.

I will do this next week and keep my experiences posted.

> > > That's even weirder.  What does "uname -a" show?  You 
> should not get
> > > that message on Win2k Pro (as your previously attached 
> cygcheck output
> > > indicates).
> >
> > CYGWIN_NT-5.0 mucw0291 1.5.18(0.132/4/2) 2005-07-02 20:30 
> i686 unknown
> > unknown Cygwin
> 
> Extremely weird.  

Why? According to the man page, the only "unknown" entries relate to
the parameters "processor" and "hardware-platform", and it is easy to
imagine that uname can't extract that information.

> Could it be the same problem (some utility exited
> producing no output because of the wrong current versions of files)?

I don't understand: How could this affect uname?

> Ok, so you need to run all the ones that end in .sh, and 
> rename them to
> .done (while overwriting the old versions).  If you make a 
> note of which
> scripts need running, and set those packages to "Reinstall" in setup,
> setup will do this for you.

OK, but wouldn't it be easier to simply have setup to update them
automatically?


> This is an interesting problem, thanks for helping debug this.

Thank you for helping me to get it running!

Ronald

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]