Re: RFC: 1.7.33 problem with user's home directory
On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote: Greetings, Corinna Vinschen! I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the /snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. You could just parse the setup.hint file from your favorite mirror. test: cygwin-1.7.34-002 -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, cyg Simple! On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote: Greetings, Corinna Vinschen! I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the /snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. You could just parse the setup.hint file from your favorite mirror. test: cygwin-1.7.34-002 Thanks for suggestion, but test release =/= snapshot[1]. [1] http://cygwin.com/snapshots/ -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.12.2014, 01:41 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On 10/12/14 20:52, cyg Simple wrote: On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote: Greetings, Corinna Vinschen! I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the/snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. You could just parse the setup.hint file from your favorite mirror. This doesn't work in the general case, as not all snapshots are uploaded as test packages. Plus you'd have to wait while your favourite mirror picked up the new package. Sadly, parsing the HTML is the only way to go right now. This is very error-prone, as any assumption you make about the structure of the HTML could change with no notice. The following works (as the snapshots page stands) by extracting the date from one of the filenames: wget -q -O - http://cygwin.com/snapshots/ | egrep cygwin1-[0-9]*.dll.xz | head -n 1 | sed 's/^.*cygwin1-\([0-9]*\)\.dll\.xz.*$/\1/g' This is about as fool-proof as I can make it. It assumes nothing about the HTML, so it should survive a fairly substantial change to the web page. Provided we don't change the format of the filenames, the above stands a chance of working. YMMV. Cheers, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Dec 6 00:05, Andrey Repin wrote: Greetings, Corinna Vinschen! I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the /snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. http://cygwin.com/acronyms/#SHTDI http://cygwin.com/acronyms/#PGA Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpndseXutTa1.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Dec 5 08:28, Andrey Repin wrote: On Nov 11 12:14, Corinna Vinschen wrote: The new stuff is still missing documentation, [...] If you're wondering why I didn't create a test release yet, it's all about this dreaded documentation. Did I mention already how much I hate writing documentation? Yes? Whatever. I really hate writing documentation! It's infinitely worse than writing the code. Every 10 lines of documentation I write for my projects make me want to rewrite at least one line of the code. Because it feels stupid now, that I've explained, how it works. Unfortunately you *have* to explain configuration. I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp10HogRgcak.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the /snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, 23:12 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. Try it the other way around. You'll get the same result. It has nothing to do with cygwin opening it first. It has to do with cmd not handling a \\network\share style address. MS was too lazy to deal with command.com's 1-CurDir / drive scenario that is embedded in the Win32 interface. If you cd to //host/currentdir, //host isn't a drive letter. So what happens when the user uses an absolute path? /tmp... where is that /tmp? Ends up at the root of each drive, but on a UNC-based-net-connection? Undefined. So cmd.exe can't be used on a UNC-based path, only on DOS compatible (drive letter assummed) based-path. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Dec 4 04:20, Linda Walsh wrote: Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. Try it the other way around. You'll get the same result. It has nothing to do with cygwin opening it first. It has to do with cmd not handling a \\network\share style address. MS was too lazy to deal with command.com's 1-CurDir / drive scenario that is embedded in the Win32 interface. If you cd to //host/currentdir, //host isn't a drive letter. It will get interesting with the new CMD from Windows 10. MSFT has a whole team now working on pulling CMD into the 21st century of CLIs. Allowing UNC paths as CWD is apparently on their radar, though the current latest CMD in the W10 preview is still missing this feature. So what happens when the user uses an absolute path? /tmp... where is that /tmp? Ends up at the root of each drive, but on a UNC-based-net-connection? Undefined. So cmd.exe can't be used on a UNC-based path, only on DOS compatible (drive letter assummed) based-path. Allowing CMD as shell wouldn't change how Cygwin tools see the world. Yes, with current CMDs you won't be able to utilize network paths as CWD, among other restrictions. Still, evaluating db_shell: windows as using CMD, rather than being a no-op might hvae some value. I would never use it myself, but there may be some people, or, let's assume, special maintainance accounts, for which this might come in handy. Would it hurt to implement it, even only for symmetry with the other options? I'm not sure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaBNGOAmU47.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 26 21:56, Corinna Vinschen wrote: On Nov 11 12:14, Corinna Vinschen wrote: On Nov 11 11:05, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I just created a patch and a matching snapshot on https://cygwin.com/snapshots/ The new stuff is still missing documentation, [...] If you're wondering why I didn't create a test release yet, it's all about this dreaded documentation. Did I mention already how much I hate writing documentation? Yes? Whatever. I really hate writing documentation! It's infinitely worse than writing the code. I'm just working on the documentation and it's going forward really tenaciously, so I felt the need to vent^Wkeep you informed. When I have a more or less working piece of documentation, I'll create a new Cygwin test release again, for installation via setup. I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. Also, if you don't understand the settings, or some of the settings, feel free to ask. The developer (that's me, I guess) sometimes just doesn't know if the description makes sense or not. It will very likely help to make the documentation better. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3EaFZunbc2.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! On Nov 11 12:14, Corinna Vinschen wrote: On Nov 11 11:05, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I just created a patch and a matching snapshot on https://cygwin.com/snapshots/ The new stuff is still missing documentation, [...] If you're wondering why I didn't create a test release yet, it's all about this dreaded documentation. Did I mention already how much I hate writing documentation? Yes? Whatever. I really hate writing documentation! It's infinitely worse than writing the code. Every 10 lines of documentation I write for my projects make me want to rewrite at least one line of the code. Because it feels stupid now, that I've explained, how it works. I'm just working on the documentation and it's going forward really tenaciously, so I felt the need to vent^Wkeep you informed. When I have a more or less working piece of documentation, I'll create a new Cygwin test release again, for installation via setup. I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? I'm not very fond of HTML parsing. Also, if you don't understand the settings, or some of the settings, feel free to ask. The developer (that's me, I guess) sometimes just doesn't know if the description makes sense or not. It will very likely help to make the documentation better. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, 08:16 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Tue, Dec 2, 2014 at 12:29 AM, Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, cyg Simple! On Tue, Dec 2, 2014 at 12:29 AM, Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. That's why Windows mount homedir to a disk letter in first place. But even if you choose the hard way, you can tell cmd to stop being ridiculous. -- WBR, Andrey Repin (anrdae...@yandex.ru) 03.12.2014, 23:09 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 28 13:48, Corinna Vinschen wrote: On Nov 28 15:08, Andrey Repin wrote: Greetings, Corinna Vinschen! The meaning of the schemata depend on the setting: db_home: windows AD and SAM: Utilizes the setting of the homeDrive or homeDirectory attributes, or their SAM Home folder counterparts. The Windows path is converted to a POSIX path. I'm not really happy with this. It requires to write some value to the homeDrive/homeDirectory attributes, because it doesn't fall back to the Windows default values. So, another question is this: Shall db_home: windows fall back to the default Windows home dir if homeDrive/homeDirectory are empty? Yes, if you mean it. I mean, if you intend to use the same directory OS using for user's home directory, you gotta use something that resembles the OS behavior. Good point. It's just a bit lengthy to implement. Implemented in the latest snapshot at https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPMypMQXu6p.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Fri, Nov 28, 2014 at 5:21 PM, Andrey Repin wrote:
Greetings, Corinna Vinschen!
On Nov 28 19:08, Andrey Repin wrote:
If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:
$ cat /bin/cmd
#!/bin/dash
PATH=/bin:$PATH
cd $HOME
# Don't rely on COMSPEC!
cmd=$(cygpath -ua ${SYSTEMROOT}\\System32\\CMD.EXE)
exec ${cmd}
I hope you don't expect it to work inside mintty.
Oh, it does. CMD itself isn't the biggest problem, many other native
tools are.
Yes, CMD itself do output... something. As long as encoding isn't an issue.
But I have PROMPT=%USERNAME%%COMPUTERNAME%. Imagine if one of them turned out
to contain non-ASCII characters.
Cygwin tools may function
properly in this case, but the shell itself - I have my doubts. And other
native tools would certainly have issues with encoding, if not with any
output
at all.
Said that, it would need to be a simple .cmd file, so that it'd run in
native
console.
Something like
@ECHO OFF
PATH=%~dp0;%PATH%
START /B %SystemRoot%\System32\cmd.exe /K
EXIT
Fine with me, but it also has to cd to %HOME%, which is given in
POSIX syntax...
That may be an issue, unless %HOME% is set somewhere else.
If you have ideas, where to look, I may be able to provide the code to do it.
Don't forget that CMD will not create a second connection to a
\\host\share if Cygwin already has one open.
--
cyg Simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.12.2014, 08:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! The meaning of the schemata depend on the setting: db_home: windows AD and SAM: Utilizes the setting of the homeDrive or homeDirectory attributes, or their SAM Home folder counterparts. The Windows path is converted to a POSIX path. I'm not really happy with this. It requires to write some value to the homeDrive/homeDirectory attributes, because it doesn't fall back to the Windows default values. So, another question is this: Shall db_home: windows fall back to the default Windows home dir if homeDrive/homeDirectory are empty? Yes, if you mean it. I mean, if you intend to use the same directory OS using for user's home directory, you gotta use something that resembles the OS behavior. @ad_attribute AD-only: Read AD attribute ad_attribute as POSIX path. However, I'm contemplating to allow a Windows path here, too. Does this make sense to you? I implemented this now. It doesn't hurt. Windows path here makes more sense. The translation to POSIX path depends on the fstab settings, and may vary across different systems, and even different users, given your aim to make fstab configurable per-user. (Am I reading it right?) /path POSIX path. Remember the wildcards. fallbackIf nothing works, the fallback is /home/$USERNAME (Windows username). db_shell: windows Ignored. Do you want CMD instead? Would be interesting for symmetry only, I guess... With bogus quoting rules of CMD? It would just not work straight, I'm afraid. May be better with PS, but I'm not familiar with it, and I don't know anyone, who's familiar or even considering it's use as a shell interpreter. -- WBR, Andrey Repin (anrdae...@yandex.ru) 28.11.2014, 14:52 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! db_shell: windows Ignored. Do you want CMD instead? Would be interesting for symmetry only, I guess... Adding to that: Cygwin shell is supposed to have access to Cygwin commands. Running foreign shell may just get the user stuck in the middle of nowhere. -- WBR, Andrey Repin (anrdae...@yandex.ru) 28.11.2014, 15:23 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 28 15:08, Andrey Repin wrote:
Greetings, Corinna Vinschen!
The meaning of the schemata depend on the setting:
db_home:
windows AD and SAM: Utilizes the setting of the homeDrive or
homeDirectory attributes, or their SAM Home folder
counterparts. The Windows path is converted to a
POSIX path.
I'm not really happy with this. It requires to write some value to the
homeDrive/homeDirectory attributes, because it doesn't fall back to the
Windows default values.
So, another question is this: Shall db_home: windows fall back
to the default Windows home dir if homeDrive/homeDirectory are empty?
Yes, if you mean it.
I mean, if you intend to use the same directory OS using for user's home
directory, you gotta use something that resembles the OS behavior.
Good point. It's just a bit lengthy to implement.
@ad_attribute AD-only: Read AD attribute ad_attribute as POSIX
path.
However, I'm contemplating to allow a Windows path
here, too. Does this make sense to you?
I implemented this now. It doesn't hurt.
Windows path here makes more sense. The translation to POSIX path depends
on the fstab settings, and may vary across different systems, and even
different users, given your aim to make fstab configurable per-user. (Am I
reading it right?)
We already have user mount points in /etc/fstab.d. Reading them from AD
only changes the point of administration. In many organizations the
client machines use a standarized layout anyway. Allowing a DOS path
here just adds convenience for admins feeling uncomfortable with POSIX
paths.
db_shell:
windows Ignored. Do you want CMD instead?
Would be interesting for symmetry only, I guess...
With bogus quoting rules of CMD? It would just not work straight, I'm
afraid. May be better with PS, but I'm not familiar with it, and I don't know
anyone, who's familiar or even considering it's use as a shell interpreter.
Lots of people do. You won't believe in how many scenarios the
users use Cygwin tools from CMD. If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:
$ cat /bin/cmd
#!/bin/dash
PATH=/bin:$PATH
cd $HOME
# Don't rely on COMSPEC!
cmd=$(cygpath -ua ${SYSTEMROOT}\\System32\\CMD.EXE)
exec ${cmd}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp_kcoQ4aArj.pgp
Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen!
The meaning of the schemata depend on the setting:
db_home:
windows AD and SAM: Utilizes the setting of the homeDrive or
homeDirectory attributes, or their SAM Home folder
counterparts. The Windows path is converted to a
POSIX path.
I'm not really happy with this. It requires to write some value to the
homeDrive/homeDirectory attributes, because it doesn't fall back to the
Windows default values.
So, another question is this: Shall db_home: windows fall back
to the default Windows home dir if homeDrive/homeDirectory are empty?
Yes, if you mean it.
I mean, if you intend to use the same directory OS using for user's home
directory, you gotta use something that resembles the OS behavior.
Good point. It's just a bit lengthy to implement.
I can imagine.
db_shell:
windows Ignored. Do you want CMD instead?
Would be interesting for symmetry only, I guess...
With bogus quoting rules of CMD? It would just not work straight, I'm
afraid. May be better with PS, but I'm not familiar with it, and I don't know
anyone, who's familiar or even considering it's use as a shell interpreter.
Lots of people do. You won't believe in how many scenarios the
users use Cygwin tools from CMD.
I trust you. For I'm one of those people, is not for any other reason.
However, I know exactly what I'm doing, and what to expect from it all.
If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:
$ cat /bin/cmd
#!/bin/dash
PATH=/bin:$PATH
cd $HOME
# Don't rely on COMSPEC!
cmd=$(cygpath -ua ${SYSTEMROOT}\\System32\\CMD.EXE)
exec ${cmd}
I hope you don't expect it to work inside mintty. Cygwin tools may function
properly in this case, but the shell itself - I have my doubts. And other
native tools would certainly have issues with encoding, if not with any output
at all.
Said that, it would need to be a simple .cmd file, so that it'd run in native
console.
Something like
@ECHO OFF
PATH=%~dp0;%PATH%
START /B %SystemRoot%\System32\cmd.exe /K
EXIT
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 28.11.2014, 18:17
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 28 19:08, Andrey Repin wrote:
If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:
$ cat /bin/cmd
#!/bin/dash
PATH=/bin:$PATH
cd $HOME
# Don't rely on COMSPEC!
cmd=$(cygpath -ua ${SYSTEMROOT}\\System32\\CMD.EXE)
exec ${cmd}
I hope you don't expect it to work inside mintty.
Oh, it does. CMD itself isn't the biggest problem, many other native
tools are.
Cygwin tools may function
properly in this case, but the shell itself - I have my doubts. And other
native tools would certainly have issues with encoding, if not with any output
at all.
Said that, it would need to be a simple .cmd file, so that it'd run in native
console.
Something like
@ECHO OFF
PATH=%~dp0;%PATH%
START /B %SystemRoot%\System32\cmd.exe /K
EXIT
Fine with me, but it also has to cd to %HOME%, which is given in
POSIX syntax...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpSnKKkTRgtu.pgp
Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen!
On Nov 28 19:08, Andrey Repin wrote:
If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:
$ cat /bin/cmd
#!/bin/dash
PATH=/bin:$PATH
cd $HOME
# Don't rely on COMSPEC!
cmd=$(cygpath -ua ${SYSTEMROOT}\\System32\\CMD.EXE)
exec ${cmd}
I hope you don't expect it to work inside mintty.
Oh, it does. CMD itself isn't the biggest problem, many other native
tools are.
Yes, CMD itself do output... something. As long as encoding isn't an issue.
But I have PROMPT=%USERNAME%%COMPUTERNAME%. Imagine if one of them turned out
to contain non-ASCII characters.
Cygwin tools may function
properly in this case, but the shell itself - I have my doubts. And other
native tools would certainly have issues with encoding, if not with any
output
at all.
Said that, it would need to be a simple .cmd file, so that it'd run in native
console.
Something like
@ECHO OFF
PATH=%~dp0;%PATH%
START /B %SystemRoot%\System32\cmd.exe /K
EXIT
Fine with me, but it also has to cd to %HOME%, which is given in
POSIX syntax...
That may be an issue, unless %HOME% is set somewhere else.
If you have ideas, where to look, I may be able to provide the code to do it.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 29.11.2014, 01:17
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
On Nov 26 22:58, Corinna Vinschen wrote: On Nov 26 22:28, Achim Gratz wrote: Corinna Vinschen writes: Ok, so we have a cygwin schema extension now. The file is called cygwin.ldif and is in the Cygwin CVS repo. It gets installed to /usr/share/cygwin. The schema extension consists of two auxiliary classes: […] Do you think this makes sense? Would you actually use these AD extensions, or do you see your admins using them if available? This is _very_ interesting and I hope to have some discussion with our AD admins about this. It will be some time though, there is just too many other things going on right now. But if they allow this to be used, I think it would indeed be possible to get rid of all local configuration for a new install on a client machine. It would be possible for sure. The question is, would it be actually used? In some environments, schema and configuration extensions are avoided like the plague. Oh, btw. since you're mentioning this will take time... it will take time from my side as well. I'm not planning to implement reading fstab and nsswitch contents from AD in 2014. That's something for 2015, and it depends on you guys, either in helping defining the layout of the AD configuration, or even helping coding: Ideally, such a configuration extension requires a new tool for Admins. It's not exactly feasible for an Admin to install and maintain the configuration extension in ADSI Edit. At least a CLI tool to install and maintain the settings would be needed. A GUI tool would be the hit. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnykGBmGAIH.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 26 21:56, Corinna Vinschen wrote: db_gecos: windows AD and SAM: displayName attribute, or Full Name setting in SAM. cygwin AD-only: cygwinGecos attribute from cygwinUser class. unixAD-only: gecos attribute from posixAccount class. I forgot desc' here: descAD and SAM: Fetch the gecos= setting from the user's description attribute. POSIX path. @ad_attribute Read AD attribute ad_attribute and prepend to pw_gecos. /path Skip the slash, prepend the reminder of the string to pw_gecos. Note that the wildcards are still evaluated. fallbackIf nothing works, the fallback is no fallback. Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcCDWYb_Tag.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 26 21:56, Corinna Vinschen wrote: The meaning of the schemata depend on the setting: db_home: windows AD and SAM: Utilizes the setting of the homeDrive or homeDirectory attributes, or their SAM Home folder counterparts. The Windows path is converted to a POSIX path. I'm not really happy with this. It requires to write some value to the homeDrive/homeDirectory attributes, because it doesn't fall back to the Windows default values. So, another question is this: Shall db_home: windows fall back to the default Windows home dir if homeDrive/homeDirectory are empty? cygwin AD only: Shortcut for the cygwinHome attribute from the predefined cygwinUser auxiliary class. POSIX path expected. unixAD only: Shortcut for the unixHomeDirectory attribute from the posixAccount auxiliary class. POSIX path expected. descAD and SAM: Fetch the home=... setting from the user's description attribute. POSIX path expected. @ad_attribute AD-only: Read AD attribute ad_attribute as POSIX path. However, I'm contemplating to allow a Windows path here, too. Does this make sense to you? I implemented this now. It doesn't hurt. /path POSIX path. Remember the wildcards. fallbackIf nothing works, the fallback is /home/$USERNAME (Windows username). db_shell: windows Ignored. Do you want CMD instead? Would be interesting for symmetry only, I guess... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9G2lhZVPMe.pgp Description: PGP signature
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
Corinna Vinschen writes: Ideally, such a configuration extension requires a new tool for Admins. It's not exactly feasible for an Admin to install and maintain the configuration extension in ADSI Edit. In practise IT would do these edits via a dedicated web interface that takes most of its data from the install order form. As long as they don't have to install any extra interface libraries or server components they likely don't have a problem once they know the names and layout. At least a CLI tool to install and maintain the settings would be needed. A GUI tool would be the hit. I'm not sure how large the user base of this might be. Around here even the AD administrators are pretty much restricted from using any edit functionality such tools might provide since all changes must have a documentation trail. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
On Nov 27 18:47, Achim Gratz wrote: Corinna Vinschen writes: Ideally, such a configuration extension requires a new tool for Admins. It's not exactly feasible for an Admin to install and maintain the configuration extension in ADSI Edit. In practise IT would do these edits via a dedicated web interface that takes most of its data from the install order form. -v please? Is there something available out of the box? Please keep in mind that I'm not an admin. ADSI Edit is perfectly fine for my limited usage of AD. As long as they don't have to install any extra interface libraries or server components they likely don't have a problem once they know the names and layout. At least a CLI tool to install and maintain the settings would be needed. A GUI tool would be the hit. I'm not sure how large the user base of this might be. Around here even the AD administrators are pretty much restricted from using any edit functionality such tools might provide since all changes must have a documentation trail. Maybe I'm too far off, but to me documentation requirements don't exclude the use of certain tools... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAKydZvPis2.pgp Description: PGP signature
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
Corinna Vinschen writes: In practise IT would do these edits via a dedicated web interface that takes most of its data from the install order form. -v please? Is there something available out of the box? Please keep in mind that I'm not an admin. ADSI Edit is perfectly fine for my limited usage of AD. I don't really know, but that's how they (have to) do all the other stuff, see below. Maybe I'm too far off, but to me documentation requirements don't exclude the use of certain tools... Technically not, but the associated compliance regulations and policies do. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 12:14, Corinna Vinschen wrote: On Nov 11 11:05, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I just created a patch and a matching snapshot on https://cygwin.com/snapshots/ The new stuff is still missing documentation, so I'm explaining it here for now. For the attentive, there are two questions in the text... Here's what you get: /etc/nsswitch.conf now supports specifying three new settings which allow to configure the pw_dir, pw_shell, and pw_gecos content: db_home: schema... db_shell: schema... db_gecos: schema... schema... is a list of up to four space-separated schemata: db_home: schema1 schema2 ... If the first schema returns an empty string, skip to the second, and so on. Schemata only supported on AD are silently skipped for SAM accounts and on non-AD machines. The default for all three settings is: db_foo: cygwin desc Four predefined schemata are supported: windows Utilizes typical Windows settings. Supported for AD and SAM accounts. cygwinUtilizes predefined cygwinUser/cygwinGroup AD schema extensions. These are available via a schema extension file /usr/share/cygwin/cygwin.ldif. unix Utilizes the RFC2307 posixAccount/posixGroup schema extensions. These are available when installing the Server for NIS AD feature. desc Utilizes XML-style attributes in the description attribute. Supported for AD and SAM accounts. This way to fetch extended user and group info from the description field is already documented (albeit only for SAM accounts) in https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo: Two variable schemata are supported: @ad_attribute ad_attribute is any arbitrary AD attribute name which should be available in the User class or in any attached auxiliary class. /path An arbitrary string, typically a path. The leading slash is required. The /path schema supports a few wildcards: %u Cygwin username %U Windows username %D Windows domain in NetBIOS style %_ A space %% A percent sign. The meaning of the schemata depend on the setting: db_home: windows AD and SAM: Utilizes the setting of the homeDrive or homeDirectory attributes, or their SAM Home folder counterparts. The Windows path is converted to a POSIX path. cygwin AD only: Shortcut for the cygwinHome attribute from the predefined cygwinUser auxiliary class. POSIX path expected. unixAD only: Shortcut for the unixHomeDirectory attribute from the posixAccount auxiliary class. POSIX path expected. descAD and SAM: Fetch the home=... setting from the user's description attribute. POSIX path expected. @ad_attribute AD-only: Read AD attribute ad_attribute as POSIX path. However, I'm contemplating to allow a Windows path here, too. Does this make sense to you? /path POSIX path. Remember the wildcards. fallbackIf nothing works, the fallback is /home/$USERNAME (Windows username). db_shell: windows Ignored. Do you want CMD instead? cygwin AD-only: Shortcut for the cygwinShell attribute from the cygwinUser class. POSIX path. unixAD-only: Shortcut for the loginShell attribute from the posixAccount class. POSIX path. descAD and SAM: Fetch the shell= setting from the user's description attribute. POSIX path. @ad_attribute See above. /path See above. fallbackIf nothing works, the fallback is /bin/bash. db_gecos: windows AD and SAM: displayName attribute, or Full Name setting in SAM. cygwin
Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
On Nov 26 21:56, Corinna Vinschen wrote: Cygwin schema extension? :) I just created a patch and a matching snapshot on https://cygwin.com/snapshots/ Ok, so we have a cygwin schema extension now. The file is called cygwin.ldif and is in the Cygwin CVS repo. It gets installed to /usr/share/cygwin. The schema extension consists of two auxiliary classes: CN=cygwinUser, gets attached to CN=User and adds the attributes: cygwinHome cygwinShell cygwinGecos as well as the as of yet unused cygwinUnixUid cywinFstab CN=cygwinGroup, gets attached to CN=Group and adds the attribute: cygwinUinxGid The cygwinHome, cygwinShell and cygwinGecos attributes are described in my previous mail. cygwinUnixUid and cygwinUinxGid are supposed to be used for NFS and Samba uid/gid account mapping, same as the posixAccount:uidNumber, and posixGroup:gidNumber fields. See https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nfs https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-samba cygwinFstab, a multi-string attribute, is supposed to be used as user fstab, along the lines, but replacing the /etc/fstab.d/$USER file. This way an administrator can predefine per-user mount points. In the long run I'm also planning to allow replacing /etc/fstab and /etc/nsswitch.conf with a Cygwin-specific AD configuration extension. The idea of this, including the cygwinFstab attribute, is to allow admins to get rid of any local system setting, to control the Cygwin system settings entirely from AD, and to drop the requirement for /etc being always alongside of Cygwin's /bin dir. Do you think this makes sense? Would you actually use these AD extensions, or do you see your admins using them if available? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2D7qwcoT54.pgp Description: PGP signature
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
Corinna Vinschen writes: Ok, so we have a cygwin schema extension now. The file is called cygwin.ldif and is in the Cygwin CVS repo. It gets installed to /usr/share/cygwin. The schema extension consists of two auxiliary classes: […] Do you think this makes sense? Would you actually use these AD extensions, or do you see your admins using them if available? This is _very_ interesting and I hope to have some discussion with our AD admins about this. It will be some time though, there is just too many other things going on right now. But if they allow this to be used, I think it would indeed be possible to get rid of all local configuration for a new install on a client machine. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
In the long run I'm also planning to allow replacing /etc/fstab and /etc/nsswitch.conf with a Cygwin-specific AD configuration extension. While I can see how this might be attractive for some, I see it as something that must be an optional replacement of the /etc/fstab and /etc/nsswitch.conf files, as in my case the AD is totally outside of my control and these additions will never be implemented. Dave
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
On Nov 26 21:44, Habermann, David (D) wrote: In the long run I'm also planning to allow replacing /etc/fstab and /etc/nsswitch.conf with a Cygwin-specific AD configuration extension. While I can see how this might be attractive for some, I see it as something that must be an optional replacement of the /etc/fstab and /etc/nsswitch.conf files, as in my case the AD is totally outside of my control and these additions will never be implemented. Sure, no worries. I wasn't talking about removing support for the /etc/fstab and /etc/nsswitch.conf files, but to add another technique for admins. The files are absolutely required for non-AD machines anyway. The idea was going along these lines. At Cygwin startup: - On a domain machine, request the configuration extension for nsswitch.conf from AD. If it exists use it. - If it doesn't exist, or if the machine is a non-AD machine, check the file. Same for /etc/fstab. After creating the passwd entry for the current user, check for the user's cygwinFstab attribute. If it's not empty, use it, otherwise, or on a non-AD machine, use the /etc/fstab.d/$USER file. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsE__MIqGOf.pgp Description: PGP signature
Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)
On Nov 26 22:28, Achim Gratz wrote: Corinna Vinschen writes: Ok, so we have a cygwin schema extension now. The file is called cygwin.ldif and is in the Cygwin CVS repo. It gets installed to /usr/share/cygwin. The schema extension consists of two auxiliary classes: […] Do you think this makes sense? Would you actually use these AD extensions, or do you see your admins using them if available? This is _very_ interesting and I hope to have some discussion with our AD admins about this. It will be some time though, there is just too many other things going on right now. But if they allow this to be used, I think it would indeed be possible to get rid of all local configuration for a new install on a client machine. It would be possible for sure. The question is, would it be actually used? In some environments, schema and configuration extensions are avoided like the plague. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3VbCA17wbi.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, Which is covered by system setting. Which will either read the location from AD or use %HOMEPATH%, if all else fails. not %HOMEPATH%/AppData/Roaming/CMD. I don't see, why not. Forget for a moment about its true location. Does it matter, where the files are located, when cygwin is running? Not when it's running, but a homedir does *not* belong under AppData, especially not under Roaming. Perhaps, I'm missing something. What meaning exactly you put into homedir, which seems to preclude any possibility of discussion? You apparently didn't read what I wrote in this thread. AppData is the wrong spot. Applications are not supposed to use AppData directly, rather just the subfolders. I didn't suggest to use AppData directly . And the Roaming subfolder is the worst of all, given that it contains the roaming profile, which is copied over to the client at login time. This is not at all the place for any kind of home directory. Well, now, this is an argument I won't be arguing about. Any expectations of size of a file or directory have a tendency to be wrong. (Proved by passwd/group files...) -- WBR, Andrey Repin (anrdae...@yandex.ru) 17.11.2014, 06:49 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 14 00:49, Andrey Repin wrote: Greetings, Corinna Vinschen! On Nov 12 23:23, Andrey Repin wrote: So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, Which is covered by system setting. Which will either read the location from AD or use %HOMEPATH%, if all else fails. not %HOMEPATH%/AppData/Roaming/CMD. I don't see, why not. Forget for a moment about its true location. Does it matter, where the files are located, when cygwin is running? Not when it's running, but a homedir does *not* belong under AppData, especially not under Roaming. Perhaps, I'm missing something. What meaning exactly you put into homedir, which seems to preclude any possibility of discussion? You apparently didn't read what I wrote in this thread. AppData is the wrong spot. Applications are not supposed to use AppData directly, rather just the subfolders. And the Roaming subfolder is the worst of all, given that it contains the roaming profile, which is copied over to the client at login time. This is not at all the place for any kind of home directory. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpr6fWVNOR0o.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 14 01:04, Andrey Repin wrote: Greetings, Corinna Vinschen! 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. This is just a subset of what I suggested, so I’m in favor of it. (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.) This would be most easily implemented as well. The beauty here is that probably 99% of the home users don't set HOMEDRIVE/HOMEPATH in their SAM. They are always set by default. Are you kidding me? We're talking about creating passwd entries from user DBs, right? We're certainly not talking about fetching the environment variables of the current user to create arbitrary user's passwd entry. Ever tried the NetUserGetInfo function? So they get /home/$USER as fallback, No. which is what they got with /etc/passwd as well. And SAM users have the XML-like description field entry as well. For AD environments HOMEDRIVE/HOMEPATH are typically set, though. HOMEDRIVE/HOMEPATH always set. Funny. I think I skip the rest of your mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKUriMQsWHM.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 21:51, Habermann, David (D) wrote: current scenario. Besides, it is nice to have the Cygwin HOME directory isolated to the Cygwin installation for a portable install that can be used on a USB thumb drive. I hadn't even thought about thumb drive/portable use since I hadn't used mine for a while. I, too, will have to work around any change to the current home directory location in order to continue use. For the moment at least we can always fall back onto specifying these things in the passwd file, although I already like the new AD system and hope I don't have to abandon it. The idea of this discussion is to find a solution which works for everybody. In theory, the default should work for all or at least most home users. For AD environments I expect that admins already know that a bit of tweaking is required, here I'm looking for something which doesn't make the job too hard. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQkUQZ2Z0dp.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 23:23, Andrey Repin wrote: So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, Which is covered by system setting. Which will either read the location from AD or use %HOMEPATH%, if all else fails. not %HOMEPATH%/AppData/Roaming/CMD. I don't see, why not. Forget for a moment about its true location. Does it matter, where the files are located, when cygwin is running? Not when it's running, but a homedir does *not* belong under AppData, especially not under Roaming. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpT3ihn8CE_W.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 12 09:45, Warren Young wrote: On Nov 11, 2014, at 3:18 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. This is just a subset of what I suggested, so I’m in favor of it. (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.) This would be most easily implemented as well. The beauty here is that probably 99% of the home users don't set HOMEDRIVE/HOMEPATH in their SAM. So they get /home/$USER as fallback, which is what they got with /etc/passwd as well. And SAM users have the XML-like description field entry as well. For AD environments HOMEDRIVE/HOMEPATH are typically set, though. Here the users get what they have to use as homedir anyway. It's simple, but it should work OOTB for most people. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. That’s neglecting your responsibility as BDFL to set a sensible Heh. I didn't see myself as BDFL yet. Not sure if that's an honor. default. The consequence is that everyone will do it differently, and then you’ll have to support everything on an equal basis, because you chose not to endorse anything. When you choose a sensible default, you get the option to criticize and even deprecate wild alternative schemes. This is a philosophical argument. You'd have to argue in how far always using /home/$USER is NOT a sensible default. 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. I see that as orthogonal. It has the advantage of providing not only a sensible default but also a list of endorsed alternatives. Whether you *want* to endorse some or all of these alternatives by codifying them is a separate question. I guess I end up doing this anyway. How complex it becomes is another question, which I can answer probably only after starting to code it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpP3UFaFqJ96.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! On Nov 12 23:23, Andrey Repin wrote: So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, Which is covered by system setting. Which will either read the location from AD or use %HOMEPATH%, if all else fails. not %HOMEPATH%/AppData/Roaming/CMD. I don't see, why not. Forget for a moment about its true location. Does it matter, where the files are located, when cygwin is running? Not when it's running, but a homedir does *not* belong under AppData, especially not under Roaming. Perhaps, I'm missing something. What meaning exactly you put into homedir, which seems to preclude any possibility of discussion? -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, 00:47 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. This is just a subset of what I suggested, so I’m in favor of it. (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.) This would be most easily implemented as well. The beauty here is that probably 99% of the home users don't set HOMEDRIVE/HOMEPATH in their SAM. They are always set by default. So they get /home/$USER as fallback, No. which is what they got with /etc/passwd as well. And SAM users have the XML-like description field entry as well. For AD environments HOMEDRIVE/HOMEPATH are typically set, though. HOMEDRIVE/HOMEPATH always set. Here the users get what they have to use as homedir anyway. It's simple, but it should work OOTB for most people. Yes, it'll work. Just not as you expect it. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. That’s neglecting your responsibility as BDFL to set a sensible Heh. I didn't see myself as BDFL yet. Not sure if that's an honor. That's a chore. But someone has to pull it. default. The consequence is that everyone will do it differently, and then you’ll have to support everything on an equal basis, because you chose not to endorse anything. When you choose a sensible default, you get the option to criticize and even deprecate wild alternative schemes. This is a philosophical argument. You'd have to argue in how far always using /home/$USER is NOT a sensible default. I can give you a whole list of reason, including quotes from Cygwin documentation, why this is not a good idea. And cygwin is not an operating system will be a red canvas through them. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.11.2014, 00:49 Sorry for my terrible english...
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 23:19, Andrey Repin wrote: nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. I'm just summing up suggestions that have been raised in the list for last day. :) Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Not home directory. User profile directory. https://cygwin.com/ml/cygwin/2014-11/msg00201.html I was talking about the Cygwin home dir. The home dir is a home dir. It doesn't contain only stuff which is application dependent. It may also contain arbitrary user-specific stuff. So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, not %HOMEPATH%/AppData/Roaming/CMD. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAa3ogFcFym.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11, 2014, at 5:47 AM, Habermann, David (D) dahaberm...@dow.com wrote: I also like having everything stored under one main directory (c:\cygwin) for ease of backup Why would you back up all of c:\cygwin? Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download. (I’m assuming you keep setup.exe and its download tree on a network drive somewhere.) My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local. Then maybe add a few choice things under /var. Everything else can be reinstalled. Since I’m already cherry-picking what to back up, it doesn’t matter to me that /home might be somewhere physically different than /usr. c:\Users should be part of your backups anyway. and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems. Do you really have executables in $HOME/bin that won’t run unless whitelisted? Does your security software actually ban programs in %HOMEPATH%? I can see the need to smack the AV with a clue-bat occasionally for some things under /usr, if only to address false positives. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11, 2014, at 5:47 AM, Habermann, David (D) dahaberm...@dow.com wrote: I also like having everything stored under one main directory (c:\cygwin) for ease of backup Why would you back up all of c:\cygwin? Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download. (I’m assuming you keep setup.exe and its download tree on a network drive somewhere.) My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local. Then maybe add a few choice things under /var. Everything else can be reinstalled. Since I’m already cherry-picking what to back up, it doesn’t matter to me that /home might be somewhere physically different than /usr. c:\Users should be part of your backups anyway. and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems. Do you really have executables in $HOME/bin that won’t run unless whitelisted? Does your security software actually ban programs in %HOMEPATH%? I can see the need to smack the AV with a clue-bat occasionally for some things under /usr, if only to address false positives. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11, 2014, at 3:18 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. This is just a subset of what I suggested, so I’m in favor of it. (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.) 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. That’s neglecting your responsibility as BDFL to set a sensible default. The consequence is that everyone will do it differently, and then you’ll have to support everything on an equal basis, because you chose not to endorse anything. When you choose a sensible default, you get the option to criticize and even deprecate wild alternative schemes. 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. I see that as orthogonal. It has the advantage of providing not only a sensible default but also a list of endorsed alternatives. Whether you *want* to endorse some or all of these alternatives by codifying them is a separate question. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: RFC: 1.7.33 problem with user's home directory
I also like having everything stored under one main directory (c:\cygwin) for ease of backup Why would you back up all of c:\cygwin? Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download. (I'm assuming you keep setup.exe and its download tree on a network drive somewhere.) I do something similar to you, and the backup isn't the big issue (although I do have MANY locally compiled programs here). C:\Users is backed up by the corporation, so I either have to duplicate the backup or do multiple recoveries from different backup systems to get it all back...that is why I prefer c:\cygwin\home My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local. Then maybe add a few choice things under /var. Everything else can be reinstalled. and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems. Do you really have executables in $HOME/bin that won't run unless whitelisted? Does your security software actually ban programs in %HOMEPATH%? In our corporate environment, ALL programs (exe, dll, bat, shells and numerous others) on ALL PATHS must be on a corporate-enforced whitelist before they will run at all. Typically even new versions must be whitelisted, although I've been able to negotiate a folder-and-workstation-specific blanket approval. I'd like to suggest that we be sensitive to application whitelisting systems, as many corporations are moving in that direction (as it nearly eliminates virus problems altogether)and yes, working in such an environment is a true PITA. Also, in general I simply don't like mixing my corporate files (Office software, etc.) with my cygwin files. They are unrelated and so I like to keep them separate. Perhaps it is a personal preference, but it is an option I wouldn't want to loseit would probably force me back to using the passwd file instead of the db. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. I'm just summing up suggestions that have been raised in the list for last day. :) Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Not home directory. User profile directory. https://cygwin.com/ml/cygwin/2014-11/msg00201.html I was talking about the Cygwin home dir. The home dir is a home dir. It doesn't contain only stuff which is application dependent. We know that much. But it isn't easy to convince whole world in this truth. It may also contain arbitrary user-specific stuff. Cygwin-user specific, I'd say. At least, that seems to be common expectation among the users and developers here. So the Cygwin home dir is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%, Which is covered by system setting. Which will either read the location from AD or use %HOMEPATH%, if all else fails. not %HOMEPATH%/AppData/Roaming/CMD. I don't see, why not. Forget for a moment about its true location. Does it matter, where the files are located, when cygwin is running? -- WBR, Andrey Repin (anrdae...@yandex.ru) 12.11.2014, 23:18 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Wed, Nov 12, 2014 at 12:55 PM, Habermann, David (D) wrote: I also like having everything stored under one main directory (c:\cygwin) for ease of backup Why would you back up all of c:\cygwin? Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download. (I'm assuming you keep setup.exe and its download tree on a network drive somewhere.) I do something similar to you, and the backup isn't the big issue (although I do have MANY locally compiled programs here). C:\Users is backed up by the corporation, so I either have to duplicate the backup or do multiple recoveries from different backup systems to get it all back...that is why I prefer c:\cygwin\home I would have to stop using Cygwin if what is being proposed is put into action unless I can thwart it by specifying that it uses the current scenario. Besides, it is nice to have the Cygwin HOME directory isolated to the Cygwin installation for a portable install that can be used on a USB thumb drive. Thumb drive use requires mkpasswd/mkgroup -c /etc/passwd/group with careful security management but it can be done! -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: RFC: 1.7.33 problem with user's home directory
current scenario. Besides, it is nice to have the Cygwin HOME directory isolated to the Cygwin installation for a portable install that can be used on a USB thumb drive. I hadn't even thought about thumb drive/portable use since I hadn't used mine for a while. I, too, will have to work around any change to the current home directory location in order to continue use. For the moment at least we can always fall back onto specifying these things in the passwd file, although I already like the new AD system and hope I don't have to abandon it. Dave
Re: RFC: 1.7.33 problem with user's home directory
Greetings, cyg Simple! On Wed, Nov 12, 2014 at 12:55 PM, Habermann, David (D) wrote: I also like having everything stored under one main directory (c:\cygwin) for ease of backup Why would you back up all of c:\cygwin? Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download. (I'm assuming you keep setup.exe and its download tree on a network drive somewhere.) I do something similar to you, and the backup isn't the big issue (although I do have MANY locally compiled programs here). C:\Users is backed up by the corporation, so I either have to duplicate the backup or do multiple recoveries from different backup systems to get it all back...that is why I prefer c:\cygwin\home I would have to stop using Cygwin if what is being proposed is put into action unless I can thwart it by specifying that it uses the current scenario. Besides, it is nice to have the Cygwin HOME directory isolated to the Cygwin installation for a portable install that can be used on a USB thumb drive. Thumb drive use requires mkpasswd/mkgroup -c /etc/passwd/group with careful security management but it can be done! Can you, perhaps, stop exalting and start reading? Noone said you won't be able to use current scheme, one way or another. Read Corinna's question and understand it, before replying. We need to decide on a sensible DEFAULT behavior, AND a set of ALTERNATIVES, because, obviously, default setting will never suit every use case. -- WBR, Andrey Repin (anrdae...@yandex.ru) 13.11.2014, 01:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On 11/11/2014 7:40 AM, Andrey Repin wrote: Greetings, Yaakov Selkowitz! In short, elusive benefits of having a separate cygwin-specific clean homes versus confusing disjoint of multiple places to look for single user's files, settings, and other stuff when it comes to backups and migrating profiles. This an extremely personal point of view. For me, I strongly hate mixing my cygwin home with standard windows one. I prefer to have separate cygwin home also between 32 and 64 bit WBR, Andrey Repin Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
2014-11-11 1:45 GMT+01:00 Andrey Repin: I see literally zero reason to maintain separate, cygwin-specific home directory. I think I have to disagree with you. When mixing MSYS, msysGit and Cygwin in the same home directory the dot-files can become a problem. Especially when it comes to line ending in those files and the line ending setting in .gitconfig. Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 23:19, Warren Young wrote: On Nov 10, 2014, at 6:38 PM, Jeffrey Altman jalt...@secure-endpoints.com wrote: My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That’s certainly the way you’re *supposed* to do it on Windows. There’s some value in using %USERPROFILE% for this, however: 1. c:\Users\ShortName is directly analogous to /home/shortname on Linux or /Users/ShortName on OS X. 2. Recent versions of Windows have given up on the “My” prefix for the main directories within your user profile directory which happens to make them match the scheme used on Ubuntu, Fedora, OS X, etc. Finger memory like “cd ~/Desktop” will serve you better if Cygwin doesn’t bury the user directory underneath AppData somewhere. You can paper over #2 with symlinks, of course, as I already do while using the current c:\cygwin\home scheme. It would just be nice to avoid the need to create those symlinks. Symlinks don’t always behave exactly the same as real directories, for one thing. Use mount points in /etc/fstab or /etc/fstab.d. Mount points usually behave like real directories. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpD3Lq9B74QI.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 20:38, Jeffrey Altman wrote: On 11/10/2014 3:52 PM, Corinna Vinschen wrote: Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That way the home directory is isolated from native windows applications that might use the same file names but with different line endings directly in %HOMEPATH%. And, the data is within the user profile so that when accessed via redirection or otherwise, the data is accessible on every machine the user logs into. I don't think that works as expected in all environments. What you refer to above is not, in fact, %HOMEPATH%\AppData\Roaming\Cygwin, but %USERPROFILE%\AppData\Roaming\Cygwin. %USERPROFILE% and %HOMEPATH% are two different things, maintained separately in AD. The roaming user profile is often not the same path as the homedir, it's just the lazy default. The roaming user profile is loaded from the profile server every time you log on to a machine. If you have a big Cygwin home dir, you don't want that to be part of your roaming profile and being loaded over the net at login time. The homedir is typically on a fileserver which just gets connected to your drive Z:. Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_oky6fEWJ7.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Marco Atzeri wrote: On 11/11/2014 7:40 AM, Andrey Repin wrote: In short, elusive benefits of having a separate cygwin-specific clean homes versus confusing disjoint of multiple places to look for single user's files, settings, and other stuff when it comes to backups and migrating profiles. This an extremely personal point of view. For me, I strongly hate mixing my cygwin home with standard windows one. I prefer to have separate cygwin home also between 32 and 64 bit WBR, Audrey Repin Regards Marco Andrey has expressed his opinion on Cygwin's user home several times now. And I sincerely hope that it will not become the accepted view for the location of an user's home. Please, please, please, do NOT remove the possibility to maintain (the location of an user's home of) Cygwin as far away from Windows as possible ... (otherwise I will have another reason the stick to the passwd/group files) And my apology to Andrey for failing to maintain the appropriate threading. Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 23:09, Warren Young wrote: On Nov 10, 2014, at 1:52 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpM3S9HzTFaN.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen corinna-cygwin at cygwin.com writes: One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. [...] Default to /home/$USER unless a specific AD attribute is specified in some configuration file (maybe nsswitch.conf, maybe something else) and that attribute is non-empty. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Would work for me, but then the configuration of those mount points would need to be directable somehow. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). For local accounts maybe some environment variable or registry key should be available as a configuration option. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 11:18, Corinna Vinschen wrote: On Nov 10 23:09, Warren Young wrote: On Nov 10, 2014, at 1:52 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Another way to handle Cygwin-specific settings would be to utilize the description(*) field in the user's entry, just as implemented for SAM accounts. See the SAM part of https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo for how to use XML-alike entries in the description field to add user data, for instance cygwin home=/foo/bar\ shell=/bin/tcsh/ This could be added to some standard scheme: 1. Utilize the description attribute. 2. If description is empty, utilize homeDirectory. 3. If homeDirectory is empty, use /home/$USER. Or this could be added as a setting in nsswitch.conf: home: [unix|win|desc|home] I could think of arbitrarily complex ways to extend this nsswitch.conf setting, as in: home: /foo/bar/%U With %U being the Windows username, %D the domain name, %u the Cygwin user name. But all this also takes time to implement, of course :( Corinna (*) Note the naming confusion: The `net user /comment:...' command sets the AD attribute description. The `net user /usercomment:...' command sets the AD attribute comment. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6aJ2OoBzj7.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 11:05, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. [...] Default to /home/$USER unless a specific AD attribute is specified in some configuration file (maybe nsswitch.conf, maybe something else) and that attribute is non-empty. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Would work for me, but then the configuration of those mount points would need to be directable somehow. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) For local accounts maybe some environment variable or registry key should be available as a configuration option. I'm not that concerned about SAM accounts. Typically they have no problem with /home/$USER anyway, and they have the SAM description field to add cygwin-specific data. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpE01c0ou7c2.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This became especially noticeable with Cygwin 64-bit because Windows does not automatically redirect write attempts to %LOCALAPPDATA%\VirtualStore. Anyhow, that's probably left to a different conversation for a different day... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 07:11, Bryan Berns wrote: One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This can be easily fixed by providing matching mount points in /etc/fstab or /etc/fstab.d. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_pq9xIARQW.pgp Description: PGP signature
RE: RFC: 1.7.33 problem with user's home directory
Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) Sorry to join in the fun here so late, but I like the current behavior and really don't see any reason (given my usage) why I'd want to mix my cygwin and windows files together in the same directory. Additionally, I don't have the ability to change the unixHomeDirectory field in our AD. I also like having everything stored under one main directory (c:\cygwin) for ease of backup and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems. As I result, if folks feel that something must be done, I like the plan above. I don't really care what the default behavior is, so long as the home: home option is available. Dave
Re: RFC: 1.7.33 problem with user's home directory
On 11/11/2014 4:59 AM, Corinna Vinschen wrote: Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Using the unixHomeDirectory feels wrong to me because it doesn't provide a context to indicate where the home directory is located. Its intended purpose is to permit the specification of the home directory for UNIX systems. On a UNIX system it might be a local disk or /home might be on one or more network file systems which might or might not be accessible from a Windows system. What would the behavior be if unixHomeDirectory was /afs/example.edu/users/j/e/jeff and no AFS client was installed on the Windows system? What would the behavior be if there was an AFS client installed on the Windows system? To access AFS from Windows would require UNC notation not an absolute root. Does a default location in the Windows profile make sense and permit administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to indicate an alternative location? Or perhaps a per-user environment variable which would also be distributed via the user's registry hive. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Frank Fesevur! I see literally zero reason to maintain separate, cygwin-specific home directory. I think I have to disagree with you. When mixing MSYS, msysGit and Cygwin in the same home directory the dot-files can become a problem. Especially when it comes to line ending in those files and the line ending setting in .gitconfig. I think, the number of people mixing these things is lower than number of people using Cygwin with roaming profiles. And they know what they are doing, by definition. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 18:05 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. When you clarify your question, this seems to be the same point. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. Yes, this makes more sense. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. As has been pointed out, unixHomeDirectory is to tell *NIX system, where o look for user's homedir. Cygwin is not a a Unix system, and I have to agree that using this attribute for Cygwin wouldn't be the right thing. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) system: Use homeDirectory AD attribute. cygwin: Use current Cygwin way of /home/$USERNAME. Default setting is up to discussion. This is more clear in my opinon, than unix or win (Cygwin is not unix/linux, neither it's windows - it's a userspace DLL providing POSIX API compatibility in Windows), and definitely more clear, than home: home. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 18:18 Sorry for my terrible english...
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 08:51, Jeffrey Altman wrote: On 11/11/2014 4:59 AM, Corinna Vinschen wrote: Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Using the unixHomeDirectory feels wrong to me because it doesn't provide a context to indicate where the home directory is located. That's why I started this discussion in the first place. It seemed like a good idea at the time, but not so anymore. Does a default location in the Windows profile make sense and permit administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to indicate an alternative location? Or perhaps a per-user environment variable which would also be distributed via the user's registry hive. I'd prefer an admin-provided /etc/nsswitch.conf setting over registry or environment... :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqwUvBS41GK.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen writes: Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I don't see why not, given that there's the possibility of having different information for Windows, Cygwin and UNIX in the same AD. But more realistically, one of the extensionAttributes that Exchange plugs in anyway could keep that information. For local accounts maybe some environment variable or registry key should be available as a configuration option. I'm not that concerned about SAM accounts. Typically they have no problem with /home/$USER anyway, and they have the SAM description field to add cygwin-specific data. OK. We'll find out soon enough how to set up a local sshd account anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 17:44, Achim Gratz wrote: Corinna Vinschen writes: Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I don't see why not, given that there's the possibility of having different information for Windows, Cygwin and UNIX in the same AD. It's a bit complicated. You need a way to distinguish the name of an attribute from simple values like home, or cygwin as Andrey proposes. My simply Cygwin-internal LDAP interface has no way of providing arbitrary attribute strings either, so that needs to be extended first. Microsoft themselves use XML strings in some attribute blobs for TS settings and stuff, so maybe the description field should be sufficient. I'm wondering if we really need other attributes then. But more realistically, one of the extensionAttributes that Exchange plugs in anyway could keep that information. I have no experience with Exchange, so I can't tell. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1b_QUfvNgV.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 18:29, Andrey Repin wrote: Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. It's not the wrong thing if it's not used for anything else in a company. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpe5rLtu3FOg.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. It's not the wrong thing if it's not used for anything else in a company. I would step away from any possible if's as much as... possible in such case. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. I'm just summing up suggestions that have been raised in the list for last day. :) Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Not home directory. User profile directory. https://cygwin.com/ml/cygwin/2014-11/msg00201.html %AppData%/Cygwin == %HOMEPATH%/AppData/Roaming/Cygwin From corporate environment point of view, Cygwin is an application like every other one, and expected to behave according to environment standards, not invent its own. Windows environment standard dictates, that if an application intend to store large amount of user-specific files, it should do so uder %AppData%, or %LocalAppData% for discardable or hardware-specific environment. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 23:01 Sorry for my terrible english...
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen writes: - If your account is an AD account, the home directory is taken from the RFC 2307 entry unixHomeDirectory. This isn't set yet in our domain, but there's another AD just for the UNIX accounts (I haven't looked at how that one is structured yet). There's talk about maybe unifying these two AD in the future, but I have no idea how that would work. - Otherwise, if these values are empty or don't exist, your fallback home directory is /home/$USER (without domain prefix). As you may have noticed, there's nothing in there taking the Windows home directory into account. It's indeed not used at all by the new code. I think that is generally the right idea, since mixing all the .-files into the normal Windows home directory results in a mess, especially when there are Windows programs ported from Unix that use the same scheme for themselves. What I'm doing right now is to create an /etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME (always a network drive for normal domain users) when I set up a new users' machine or login on a server. I also mount the actual Windows home back under ~/winhome. Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... That would cause serious problems for me I think. Keeping the home directory pinned to /home/$USER and automounting this based on some rule involving either or both of those entries seems a better idea in the long run. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RFC: 1.7.33 problem with user's home directory
Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. Here's how it works and how it's documented in the preliminary documentation at https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo - If your account is an AD account, the home directory is taken from the RFC 2307 entry unixHomeDirectory. - Otherwise, if these values are empty or don't exist, your fallback home directory is /home/$USER (without domain prefix). As you may have noticed, there's nothing in there taking the Windows home directory into account. It's indeed not used at all by the new code. Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin home directory by converting the SAM/AD home folder entry to POSIX style, if it's non-empty. Fallback is /home/$USER. When I implemented the new scheme I thought it a good idea to decouple the Cygwin home dir from the Windows home dir. However, in the today's discussion the following two arguments came up: - If you're using the Windows home folder setting to maintain file server based home directories, you typically want that these directories are used for Cygwin stuff as well (central administration, central backup). Having to maintain the home directories twice, once in the homeDirectory, once in the unixHomeDirectory entry is quite a hassle, especially given that unixHomeDirectory does not support variable substitution (e.g. /home/%USERNAME% won't work). - If you're already using AD as NIS server, unixHomeDirectory is already used for UNIX machines. Trying to align the unixHomeDirectory for Cygwin to homeDirectory for all the rest of Windows will potentially become impossible then. These arguments are quite serious and it questions the good idea part of this change a lot. What do you think? Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... Corinna (*) This would automatically work for SAM accounts as well because SAM provides the same Windows home folder entry. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpu7vfKeFLuO.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 22:18, Achim Gratz wrote: Corinna Vinschen writes: - If your account is an AD account, the home directory is taken from the RFC 2307 entry unixHomeDirectory. This isn't set yet in our domain, but there's another AD just for the UNIX accounts (I haven't looked at how that one is structured yet). There's talk about maybe unifying these two AD in the future, but I have no idea how that would work. If you're doing that at one point... - Otherwise, if these values are empty or don't exist, your fallback home directory is /home/$USER (without domain prefix). As you may have noticed, there's nothing in there taking the Windows home directory into account. It's indeed not used at all by the new code. I think that is generally the right idea, since mixing all the .-files into the normal Windows home directory results in a mess, especially when there are Windows programs ported from Unix that use the same scheme for themselves. What I'm doing right now is to create an /etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME (always a network drive for normal domain users) when I set up a new users' machine or login on a server. I also mount the actual Windows home back under ~/winhome. Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... That would cause serious problems for me I think. Keeping the home directory pinned to /home/$USER and automounting this based on some rule involving either or both of those entries seems a better idea in the long run. ...it might give you similar trouble as you outline above. As soon as the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix machines, Cygwin's usage of unixHomeDirectory would potentially break your modus operandi... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6uPEn0QRVG.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin home directory by converting the SAM/AD home folder entry to POSIX style, if it's non-empty. Fallback is /home/$USER. When I implemented the new scheme I thought it a good idea to decouple the Cygwin home dir from the Windows home dir. However, in the today's discussion the following two arguments came up: - If you're using the Windows home folder setting to maintain file server based home directories, you typically want that these directories are used for Cygwin stuff as well (central administration, central backup). Having to maintain the home directories twice, once in the homeDirectory, once in the unixHomeDirectory entry is quite a hassle, especially given that unixHomeDirectory does not support variable substitution (e.g. /home/%USERNAME% won't work). - If you're already using AD as NIS server, unixHomeDirectory is already used for UNIX machines. Trying to align the unixHomeDirectory for Cygwin to homeDirectory for all the rest of Windows will potentially become impossible then. These arguments are quite serious and it questions the good idea part of this change a lot. What do you think? Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... All I can say about this issue is… I told you. I see literally zero reason to maintain separate, cygwin-specific home directory. If you want a separate environment to play with, VirtualBox is there to accommodate your wildest dreams. (Though, Oracle is trying hard to turn people away from using VB since 4.3.13+) -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 03:37 Sorry for my terrible english...
Re: RFC: 1.7.33 problem with user's home directory
On 11/10/2014 3:52 PM, Corinna Vinschen wrote: Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That way the home directory is isolated from native windows applications that might use the same file names but with different line endings directly in %HOMEPATH%. And, the data is within the user profile so that when accessed via redirection or otherwise, the data is accessible on every machine the user logs into. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: RFC: 1.7.33 problem with user's home directory
On 11/10/2014 4:45 PM, Andrey Repin wrote: I see literally zero reason to maintain separate, cygwin-specific home directory. My reason to have a separate, cygwin-specific home directory is to have one that is shared between Cygwin and Linux. Windows define home directories rarely are shared -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On 2014-11-10 14:52, Corinna Vinschen wrote: When I implemented the new scheme I thought it a good idea to decouple the Cygwin home dir from the Windows home dir. However, in the today's discussion the following two arguments came up: - If you're using the Windows home folder setting to maintain file server based home directories, you typically want that these directories are used for Cygwin stuff as well (central administration, central backup). Having to maintain the home directories twice, once in the homeDirectory, once in the unixHomeDirectory entry is quite a hassle, especially given that unixHomeDirectory does not support variable substitution (e.g. /home/%USERNAME% won't work). - If you're already using AD as NIS server, unixHomeDirectory is already used for UNIX machines. Trying to align the unixHomeDirectory for Cygwin to homeDirectory for all the rest of Windows will potentially become impossible then. These arguments are quite serious and it questions the good idea part of this change a lot. What do you think? Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... If one uses the same program, one native Windows and one Cygwin, they would then potentially cause conflicting/incompatible config dot-files in the same directory (line endings, path conventions, etc.). Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10, 2014, at 9:26 PM, Yaakov Selkowitz yselkow...@cygwin.com wrote: On 2014-11-10 14:52, Corinna Vinschen wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... If one uses the same program, one native Windows and one Cygwin, they would then potentially cause conflicting/incompatible config dot-files in the same directory (line endings, path conventions, etc.). That’s only true if you make Cygwin $HOME == `cygpath -u %USERPROFILE%`. If you put it somewhere under AppData/…/Cygwin, any non-Cygwin program that stomps on that directory isn’t following the platform rules. Not that I think the risk of this is all that great. I find that a lot of Windows software that comes from the Unix/Linux world already does something different with RC files and such. Common schemes are: 1. Store files under AppData/…/AppName, where they won’t conflict with Cygwin $HOME == %USERPROFILE% 2. Name files and directories differently, often without leading dots, harkening back to the FAT naming limitations. Leading underscores are a common alternative here. Care to list some native Win32 ports that *do* put their user files in %USERPROFILE%, using the same naming scheme as on Linux/Unix except prefixed $HOME? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10, 2014, at 1:52 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10, 2014, at 6:38 PM, Jeffrey Altman jalt...@secure-endpoints.com wrote: My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That’s certainly the way you’re *supposed* to do it on Windows. There’s some value in using %USERPROFILE% for this, however: 1. c:\Users\ShortName is directly analogous to /home/shortname on Linux or /Users/ShortName on OS X. 2. Recent versions of Windows have given up on the “My” prefix for the main directories within your user profile directory which happens to make them match the scheme used on Ubuntu, Fedora, OS X, etc. Finger memory like “cd ~/Desktop” will serve you better if Cygwin doesn’t bury the user directory underneath AppData somewhere. You can paper over #2 with symlinks, of course, as I already do while using the current c:\cygwin\home scheme. It would just be nice to avoid the need to create those symlinks. Symlinks don’t always behave exactly the same as real directories, for one thing. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Andrew DeFaria! On 11/10/2014 4:45 PM, Andrey Repin wrote: I see literally zero reason to maintain separate, cygwin-specific home directory. My reason to have a separate, cygwin-specific home directory is to have one that is shared between Cygwin and Linux. I do that without creating cygwin-specific /home. Windows define home directories rarely are shared So do Linux... -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 09:26 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Yaakov Selkowitz! When I implemented the new scheme I thought it a good idea to decouple the Cygwin home dir from the Windows home dir. However, in the today's discussion the following two arguments came up: - If you're using the Windows home folder setting to maintain file server based home directories, you typically want that these directories are used for Cygwin stuff as well (central administration, central backup). Having to maintain the home directories twice, once in the homeDirectory, once in the unixHomeDirectory entry is quite a hassle, especially given that unixHomeDirectory does not support variable substitution (e.g. /home/%USERNAME% won't work). - If you're already using AD as NIS server, unixHomeDirectory is already used for UNIX machines. Trying to align the unixHomeDirectory for Cygwin to homeDirectory for all the rest of Windows will potentially become impossible then. These arguments are quite serious and it questions the good idea part of this change a lot. What do you think? Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable... If one uses the same program, one native Windows and one Cygwin, they would then potentially cause conflicting/incompatible config dot-files in the same directory (line endings, path conventions, etc.). I would imagine using one or another. But not both. Native version of the same program usually runs better, than the one running through compatibility layer. Then again, many programs, that have native Windows version, use native Windows conventions (I.e. put things in %AppData% rather than clogging %USERPROFILE% with dot-dirs.) Out of my list of programs, only GIMP and Dia would share the config dirs, if I would try to set up Cygwin versions of either along with native one. And all this worth nothing, because if someone's doing something like that, they are either know what they are doing, and prepared for the possible outcome, or deserve everything that could happen. IMO. Not to mention, we're discussing default configuration here. You can alter it easily to fit your needs, Cygwin gives you all that you need to achieve it. In short, elusive benefits of having a separate cygwin-specific clean homes versus confusing disjoint of multiple places to look for single user's files, settings, and other stuff when it comes to backups and migrating profiles. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 09:28 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen corinna-cygwin at cygwin.com writes: This isn't set yet in our domain, but there's another AD just for the UNIX accounts (I haven't looked at how that one is structured yet). There's talk about maybe unifying these two AD in the future, but I have no idea how that would work. If you're doing that at one point... ...it might give you similar trouble as you outline above. As soon as the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix machines, Cygwin's usage of unixHomeDirectory would potentially break your modus operandi... Right, that's why I think that Cygwin should always have the users home in /home/$USER and mount that based on some rule that the administrator can specify. Regards, Achim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
