This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] New release of setup.exe (2.249.2.10)
Markus Schönhaber wrote:
Pierre A. Humblet wrote:
Here is another point of concern: assume a non privileged domain user
runs setup and answers "yes" to the "Run as Administrator" dialog.
It is likely that no entry will be made for the domain user in
/etc/passwd
To verify that it will be necessary to rename /etc/passwd before
running setup.
Thanks for trying when you have a chance.
Well, the account that is proposed by default by the Run As dialog ist
the local Administrator. Running under that account setup will alomost
certainly fail to create the domain relevant information in /etc/passwd
and /etc/group. But I will try and verify that next week.
OTOH: I wouldn't worry too much about that. Put that in the FAQ. This
should make things clear to the domain user who does an installation
with local administrative rights.
Any domain administrator logged on under a restricted account and
therefore using the Run As feature knows that it would be a gould idea
to switch to his domain admin account when doing things where domain
access is relevant or he shouldn't have been made domain administrator
in the first place.
I wish I had just one domain. To set this up in a mutidomain
environment, I'm finding
I install as an administrator of one of the domains DOMAIN1
create local passwd & group files
passwd.local & group.local
create domain passwd & group files:
passwd.DOMAIN1 & group.DOMAIN1
Then log in as an admin in domain DOMAIN2
create domain passwd & group files:
passwd.DOMAIN2 group.DOMAIN2
...
Then finally combine them all
cat passwd.* | sort | uniq > passwd
The sort & uniq is to remove the extra local accounts thoughtfully
provided when generating the domain password files.
The problem is when a user logs on who is more recent than when the
passwd file was initially created and so doesn't exist in /etc/passwd.
The user may not have admin privilege to regenerate the entire domain
file, but could extract their own info and append it via a craftily
written /etc/profile that performed the regeneration when the user
doesn't exist.
No, I'm not going into the overhead to associate the proper
uid offset.
(mkpasswd -u $USERNAME -d $USERDOMAIN; cat passwd.*)|sort|uniq >passwd
Then, I can periodically ship out an updated passwd.DOMAIN file to
be included by logon scripts, without having to have personalized
passwd files that reflect each machine's differing local accounts.
I just wanted to put it out there that seperately maintained
passwd files for the domain(s) & local accounts and a final
merge offer some real advantages.
Regards,
Doug VanLeuven
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/