Re: alias command not effective
On Mon, Jan 17, 2011 at 14:04, Eric Blake wrote: On 01/17/2011 01:24 AM, Thomas Wiedmann wrote: Hello, After defining an alias, e. g. alias laf='ls -la' | grep -v ^d That defined an alias in the subshell used to form the pipeline. Aliases in child processes do not affect the parent process. And, using my paranormal powers, I'd say the command line the OP wants is: alias laf='ls -la | grep -v ^d' (note the second quote char was moved to the end) laf bash:: laf: command not found Because the parent process still doesn't have an alias defined. What may be the reason, that the use of an alias, defined, had not been accepted? What has to be done to resolve this problem? Don't pipe the output of alias into another command, thereby avoiding the subshell that would limit the alias to just the child shell. He never wanted to pipe the alias command :) The real answer is: Double-check the quoting rules, so that pipe char doesn't get interpreted by bash. This is not cygwin-specific. ditto. ___ Julio Costa -- 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: SSH - Can't Login (3rd Post)
On Mon, Aug 30, 2010 at 18:03, Auteria W. Winzer Jr. wrote: I checked the following below. The user's home directory has the proper permissions (755), the .ssh directory is 700, and the files underneath the .ssh directory is 600. By default StrictModes is set to no. I still can't log in. Any help will be greatly appreciated. Help us helping you. Begin by posting a relevant part of the SERVER side log, with at least a DEBUG1 level. Also the requested information as stated in http://cygwin.com/problems.html might be useful... -- 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 Regards, ___ Julio Costa -- 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: missing dependency in setup.ini
On Tue, Jun 15, 2010 at 16:11, Paul McFerrin wrote: I did a total install of 1.7 and founf a missing dependency. for he man command. Well I see the problem. He-Man has a dependency on the universe, and that is something that our setup.exe can't cope with... yet! sorry, didn't resist :o) Back to serious mode... It failed to download the gunzip command. And is there any (gzip/gunzip) related errors in /var/log/setup.log? Or /var/log/setup.log.full? -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Thu, Jun 10, 2010 at 11:10, Andrey Repin wrote: Greetings, Julio Costa! Hi, Andrey! And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? It's already been explained in this very thread. I'm must be getting pretty dense. The only explanation I already had seen was from Eric Blake: (...) but Windows insists on having the .exe suffix for cmd to be able to run an executable (...) That was already been explained, in other occasions, and also in the thread indicated by myself. The point is, that *is not* a reason, because it is easily fixed by set PATHEXE=%PATHEXE%:.. Demo: = - = - = - = - = - = - That's nice one, as has been pointed, but let's make a step back to the definitions and see what we have on hand, before advancing in this way? Extension is a part of the file name, after last period. Two conclusions we can make from it: 1. Extension itself can't contain a period. 2. The file can't have an extension only and only if it has no periods in the name. Doing this kind of magic, you only ease the burden of file handling for cygwin in windows, but by a little margin, IMO. Not quite. How many Cygwin executables with dots in the filename (excluding the final .exe, of course) are there in the distribution? Anyway, you _are_ right. You have the right to want to build something like 'my.app', and then thing gets borked. But as I said, this is just a DEMO of what's possible to do. If we wanted to really step into this, and ensure a 100% solution, that would involve a much more elaborated approach (i.e., involving a lot of shell integration work). I'm afraid the work to fill in that gap would not justify the small gains, though. File name could have more dots than what you can imagine... You.can.try.my.imagination! Also, this same trick could be applied to the Explorer as well. REGEDIT4 [HKEY_CLASSES_ROOT\.\shell\Open\command] @=\%1\ %* That's what the regtool example I gave is doing, basically. Sorry for my terrible english... As I'm not a native speaker, I found your english truly enjoyable. Maybe mine is as terrible as yours, but no one as told me yet! :) ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 20:49, Christopher Faylor wrote:
On Wed, Jun 09, 2010 at 05:28:16PM +0100, Julio Costa wrote:
On Wed, Jun 9, 2010 at 16:47, Christopher Faylor wrote:
On Wed, Jun 09, 2010 at 03:02:16PM +0100, Julio Costa wrote:
On Wed, Jun 9, 2010 at 14:20, Eric Blake wrote:
Have you ever encountered a makefile that doesn't consistently use
$(EXEEXT) everywhere? ??Too many people just expect 'gcc -o foo ...' to
produce foo, then 'strip foo' to work, without realizing that on cygwin,
gcc created 'foo.exe' and strip _has_ to have .exe magic.
That's just one of the several scenarios which would greatly benefit
from a removal of .exe magic.
Uh, no. ??That would BREAK makefiles.
Huh? I'm getting dense. My reading was:
if gcc (or cygwin with his magic) did't apply the .exe extension, then
{strip,cp,mv,install,etc...} wouldn't need the .exe magic
period.
else
stripcompany _do_ need the .exe magic
# ...and possibily because of that, some Makefiles were needlessly
modified to do his own magic
end if
So, what would break?
Any makefile which didn't use the absolute latest version of gcc which
has this critically important change to remove .exe.
How come? I thought that that kind of things was handled by an regular
autoconf, which tries to see what is the result of a gcc
compilation... (the a.out test)
For the record, unless Corinna thinks it's a good idea (which I doubt):
we're not going to change Cygwin to drop all of the .exe extensions from
every single file in the distribution and I'd be violently opposed to
the notion of changing gcc's default behavior after all of these years.
Well, here you have two unbeatable arguments:
1) violence
2) after all these years
That is quite enough to make your point.
After all, WJM, right?
I rest my case.
--
___
Julio Costa
--
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: setting CYGWIN=nodosfilewarning not working.
On Thu, Jun 10, 2010 at 12:55, prakash babu wrote: I have a web application which runs as SYSTEM user in windows. It executes the following command using Java Runtime.exec api's C:/cygwin/bin/sh.exe -c C:/cygwin/bin/mkdir.exe -p 'C:/cygwin/tmpdir' (snip) Is there any other way to set the CYGWIN environment variable. Yes there are. Try launching like this: C:/cygwin/bin/sh.exe -c CYGWIN=nodosfilewarning /bin/mkdir -p 'C:/cygwin/tmpdir' -- ___ Julio Costa -- 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: Server 2008 permission denied on creating files of certain extensions.
On Thu, Jun 10, 2010 at 13:55, Jason Pyeron wrote: I can create almost any file, but when the extension is of the executible nature to windows I get a permission denied error. As your problem is specific to executables, two things from top of mind: 1) Possible BLODA; If you deactivate your antivirus/malware software, do the problem go away? 2) UAC. Is this in an elevated shell? If this doesn't help, I think you should follow the problem report guidelines in http://cygwin.com/problems.html so we can assess what could be wrong. -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 05:40, Christopher Faylor wrote: On Wed, Jun 09, 2010 at 02:38:30AM +0100, Julio Costa wrote: And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? It's already been explained in this very thread. I'm must be getting pretty dense. The only explanation I already had seen was from Eric Blake: (...) but Windows insists on having the .exe suffix for cmd to be able to run an executable (...) That was already been explained, in other occasions, and also in the thread indicated by myself. The point is, that *is not* a reason, because it is easily fixed by set PATHEXE=%PATHEXE%:.. Demo: = - = - = - = - = - = - D:\ETC\Toolsren C:\cygwin\bin\base64.exe C:\cygwin\bin\base64 D:\ETC\Toolsset pathext PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH D:\ETC\Toolsbase64 --help 'base64' is not recognized as an internal or external command, operable program or batch file. D:\ETC\Toolsset pathext=%pathext%;. D:\ETC\Toolsbase64 --help Usage: base64 [OPTION]... [FILE] Base64 encode or decode FILE, or standard input, to standard output. -w, --wrap=COLS Wrap encoded lines after COLS character (default 76). Use 0 to disable line wrapping. -d, --decode Decode data. -i, --ignore-garbage When decoding, ignore non-alphabet characters. --helpDisplay this help and exit. --version Output version information and exit. With no FILE, or when FILE is -, read standard input. The data are encoded as described for the base64 alphabet in RFC 3548. When decoding, the input may contain newlines in addition to the bytes of the formal base64 alphabet. Use --ignore-garbage to attempt to recover from any other non-alphabet bytes in the encoded stream. Report bugs to bug-coreut...@gnu.org. = - = - = - = - = - = - We can argue about the most effective way of making that environment change permanent (possibly done by setup.exe itself), but failing that explanation, I don't see other reasons. That was the objective of my question: Are there other reasons to maintain the .exe magic? -- ___ Julio Costa -- 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: ssh setup fails on cygwin
On Wed, Jun 9, 2010 at 10:36, prakash babu wrote: I know that cygwin 1.5 is no longer supported but since my application requires ssh to be setup and extensively uses chmod on MS-DOS paths I want atleast the the cygwin 1.5 install and ssh setup done successfully. Why don't you use the cygpath utility, like was already proposed to you? Hence I installed cygwin 1.5 on three windows XP machines using setup-legacy.exe (...) Why is this inconsistent behaviour. i. How do I go about debugging this issue and setup ssh(any logs to look into). Could this be a mounting issue That is, at least, a mounting issue. The quick, dirty, fix is to copy all executables from /usr/bin to /bin Personally I wouldn't spend more time in a 1.5 installation than that needed to 'quick, dirty, fixes' :) ii. Can this behaviour be because of the mirror site chosen. not probable iii. Can this behaviour be because of the OS flavour, patches or the softwares installed in the OS Not this behaviour directly, but maybe the failure to achieve a correct installation could be explained by BLODA (see http://cygwin.com/faq/faq.using.html#faq.using.bloda) iv. Why does echo $SHELL on a bash shell display /bin/sh instead of /bin/bash. because it din't found /bin/bash (it was in /usr/bin/bash), and for some strange reason, /bin/sh could be installed correctly, while /bin/bash did not (or the other way around). As from package, both are installed in /usr/bin, but if the installation is working properly, they should have appeared in /bin, through mounting. ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 12:39, Andy Koppe wrote: On 9 June 2010 10:48, Julio Costa wrote: And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? As far as I understand it, the original reason for it was that Windows 9x always required it. Of course Cygwin 1.7 no longer supports 9x, so from that perspective, it's no longer needed. That's how I see it too. [Running in cmd.exe] The point is, that *is not* a reason, because it is easily fixed by set PATHEXE=%PATHEXE%:.. That's a nice one. I certainly didn't know about that. Explorer still needs the .exe though. Nope also. Try this at a cmd.exe: D:\ETC\Toolsassoc .=MyDefaultLauncher .=MyDefaultLauncher D:\ETC\Toolsftype MyDefaultLauncher=%COMSPEC% /C %1 MyDefaultLauncher=C:\WINDOWS\system32\cmd.exe /C %1 D:\ETC\Toolsregtool set /user/Software/Microsoft/Command Processor/AutoRun 'set PATHEXT=%PATHEXT%;.' Now, try this in a Windows explorer: rename joe.exe (or vi.exe, or whatever...) to remove the extension. Now double-click it, and voilá. DISCLAIMER: This is only a proof-of-concept. There are clearly some rough edges to remove, but this should give you the general idea... More importantly, a lot of build scripts likely depend on the .exe being added automatically. Hm. Maybe they shouldn't. After all, the .exe magic has been around also so that kind of scripts DIDN'T needed that kind of expectations :) The frequent questions and problems around this issue do make me wonder though whether it wouldn't indeed be better to drop the .exe magic completely, deal with the ensuing pain, but eventually be done with it. +1 from me. -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 14:20, Eric Blake wrote: Have you ever encountered a makefile that doesn't consistently use $(EXEEXT) everywhere? Too many people just expect 'gcc -o foo ...' to produce foo, then 'strip foo' to work, without realizing that on cygwin, gcc created 'foo.exe' and strip _has_ to have .exe magic. That's just one of the several scenarios which would greatly benefit from a removal of .exe magic. Perhaps it does make sense to drop .exe suffixes; teaching gcc that -o foo means we really want a suffix-less file, and teaching users that they want to modify PATHEXE to include . if they are working from the windows side of things. Teaching is good, but I think that this part could even be made automatic, as I already demonstrated. But it won't be an overnight switch, and will come with its share of complaints on the list. Sure thing. Meanwhile, we can't get away from .lnk magic, but that produces orders of magnitude less complaints on the list, so I'm not as worried about it. The .lnk magic is a truly different beast, at least in the reasons that made it necessary... so I think that should be let alone, at least for now... -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 15:28, Corinna Vinschen wrote: On Jun 9 08:14, Eric Blake wrote: On 06/09/2010 08:08 AM, Andy Koppe wrote: More importantly, a lot of build scripts likely depend on the .exe being added automatically. Hm. Maybe they shouldn't. Yeah, but shouldn't never stopped anyone, hence any transition would certainly not be pain-free. A first step would be teaching gcc to not append .exe. Many configure scripts (certainly almost all scripts based on autoconf) determine $(EXEEXT) based on gcc behavior, and will just do the right thing throughout the rest of the build with $(EXEEXT) empty (as evidenced by their behavior on Linux). But even with that gcc change, we'd have to keep .exe magic in cygwin1.dll until everything in the distro has been rebuilt without an .exe suffix. However, I'm starting to like the idea, if we can get buy-in from the gcc packager. Dave? I seriously doubt the advantages. Cygwin will have to support .exe for the next couple of years anyway. There are too many applications out there already using the .exe suffix. Of course they are. for them: mv application.exe application :) Humour aside, all the *specifics* that could be spread all over a bunch of applications (and I believe they are a bunch!) are also some patches which are only contributing to deviate from the pristine sources, and the build OOTB nirvana... That is not to say that there will be many other patches which are of course needed, but you can't say that if this were to be implemented it would be a step closer in the POSIX purity way. There are too many people out there expecting foo to start foo.exe. They will be still starting foo.exe when they write foo. Because foo is foo, now. There are too many applications calling stat before exec which will fail. One patch less, then. Because such thing clearly could not belong to the POSIX original code. To me this all is a moot discussion for the very minor benefit to allow a file foo alongside of a file foo.exe. That's not really the benefit we are all aiming, just a nice consequence of a broader objective, POSIX compliance. But I DO see that there are agitated waters if we go this way... Maybe it's just a question of managing these transformations in a phased way, but in the end, it's your call, of course. There are already some proposals in this thread, which seems to be of value, namely the one by Eric regarding gcc... With that and some minor tweaks to add the aforemented PATEXT and ASSOC hacks, could open the way to then, slowly, removing the magic spread over those applications... and only in the end, in cygwin. -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 16:47, Christopher Faylor wrote:
On Wed, Jun 09, 2010 at 03:02:16PM +0100, Julio Costa wrote:
On Wed, Jun 9, 2010 at 14:20, Eric Blake wrote:
Have you ever encountered a makefile that doesn't consistently use
$(EXEEXT) everywhere? ??Too many people just expect 'gcc -o foo ...' to
produce foo, then 'strip foo' to work, without realizing that on cygwin,
gcc created 'foo.exe' and strip _has_ to have .exe magic.
That's just one of the several scenarios which would greatly benefit
from a removal of .exe magic.
Uh, no. That would BREAK makefiles.
Huh? I'm getting dense. My reading was:
if gcc (or cygwin with his magic) did't apply the .exe extension, then
{strip,cp,mv,install,etc...} wouldn't need the .exe magic
period.
else
stripcompany _do_ need the .exe magic
# ...and possibily because of that, some Makefiles were needlessly
modified to do his own magic
end if
So, what would break?
--
___
Julio Costa
--
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: 'cp' utility bug when dest-name.exe file exist.
On Wed, Jun 9, 2010 at 16:51, Christopher Faylor wrote: On Wed, Jun 09, 2010 at 10:50:34AM -0400, Stephen Morton wrote: We use a make environment that is part cygwin and part pure windows executables (long story). And it all works in linux too. I suspect it would break in the worst ugly ways if the .exe magic did not exist. And, it is this kind of thing that the .exe magic is trying to help. It wasn't implemented because of Windows 95. It is there because many UNIX apps expect executables to have .exe extensions. What kind of executables? Windows ones? Fine. Cygwin ones? Only if it is poorly written Makefile - i.e., does not use $(EXEEXT)... Is this one of those cases where the cumulating user errors are more important than the ultimate project objective (POSIX compliance/transparency)? Changing to whole distribution to not use .exe is a huge undertaking for little gain. I think it is a little more than... a little gain. But that's subjective, of course. Nevertheless, I do agree - it's a daunting task. Just one that doesn't necessarily must be done all at once... -- ___ Julio Costa -- 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: 'cp' utility bug when dest-name.exe file exist.
Ok, I would like to jump in this subject, because this is getting me too waay curious... On Wed, Jun 9, 2010 at 01:17, Matthew B. Smith wrote: Ill throw in my two cents. I don't want to overwrite an existing file accidentally. Ie if I ls foo and that writes to foo.exe I would be frustrated. This hasn't happened to me yet so it might not be to big of a problem. It seems a bit odd that the behavior would change if there is a file in the directory of a different name. odd seems like a true description of this .exe magic behaviour. And that is because Cygwin is trying to be more smart than the user itself :) If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Not exactly. Try this in a cmd.exe: PATHEXT=%PATHEXT%;. Now try running something extensionless... tadaa! CMD magic! :) And this is where my head got reeeally spinning... can anyone, please, explain the reason to why this .exe magic exists, anyway? And to all of you following this subject - there are some interesting answers in this OLD thread: http://www.cygwin.com/ml/cygwin/2007-04/msg00515.html Alas, it is not clear (at least to me) what kind of use cases are we trying to protect with the .exe magic. The cmd.exe launching of executables is solved with the PATHEXT. Is there any more use cases? I'm just reviving this question because I think this could be one of those historic features, which at one point in time turns obsolete but it has always been there... (* wishful thinking alarm*) I am just against operating systems making decisions for the user, or restricting him/her unnecessarily. And, yes, I know that this happens all the time... ditto. And additionally, this is one of those kind of features which is probably a real PITA to maintain (in several packages besides the cygwin itself), fattening the patching over upstream versions... and of course one more big stone to add to the slowness of cygwin. I see several downsides of this feature... and I fail to see the upsides. Please, cgf and corinna, can you shed some light on this? Best regards, ___ Julio Costa -- 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: C program compilation. Needed .dll's for .exe.
On Wed, May 26, 2010 at 03:39, Kaylan wrote: OS: Windows 7 cygwin installation: Basic C/C++ compilation,debug,link,make,ect I have searched all over for answers and have came up with nothing. When i compile a C program i now know i need to include some .dll's with the .exe in order for it to run on a remote machine. At least thats been the case so far. I used the command cygcheck to see what .dll's i need to include with my .exe and i get this big list. So my question(s) is, Do i really need to include all those .dll's? Is there anyway to make the .exe independent? Are there any shortcuts to manually including all those .dll's in a distribution folder with the .exe? Short Answer: No. Although you can compile statically most of the libs, cygwin1.dll is not possible to include in the executable. There are technical reasons, and also licencing reasons. Please see: http://cygwin.com/faq/faq-nochunks.html#faq.programming.static-linking What about simply including the cygwin setup with my software? Then what would need to be installed on the remote machine to simply RUN applications compiled with cygwin? You don't need necessarily to distribute the setup.exe, or build a cygwin package. You can do as probably you already are doing: gather the needed Dll's (only those specific to Cygwin, of course), join the .exe, and include the source, (as this is required by the licencing), and just drop it together in a directory on the client PC's. Any help what so ever is greatly appreciated. Regards, ___ Julio Costa -- 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: sigh
LOL! From a mail sent out in July 2009! :) On Tue, Apr 13, 2010 at 15:36, Christopher Faylor wrote: http://beautifuldiscovery.wordpress.com/2010/04/12/bash-access-violations-in-cygwin/ cgf -- ___ Julio Costa -- 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: What happens to disappearing programs when ones I used disappear from 1.7.1-1
Hi, On Tue, Jan 5, 2010 at 16:46, Paul McFerrin wrote: Fellows: I from time to time miss some of my programs AND they are not listed in the http://cygwin.com/packages/ page. One in particular which is a heavey hitter for me is col.exe. [SNIP] WJFFM: From http://cygwin.com/cgi-bin2/package-grep.cgi?grep=col.exe Found 4 matches for col.exe. netpbm/netpbm-10.44.2-1 Toolkit for manipulation of graphic images netpbm/netpbm-10.47.2-1 Toolkit for manipulation of graphic images util-linux/util-linux-2.13.1-2 Random collection of Linux utilities util-linux/util-linux-2.14.1-1 Random collection of Linux utilities Short answer: You need to install util-linux package. -- ___ Julio Costa -- 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_NT-5.1 1.7.0(0.214/5/3) ps (cygwin) 1.11 - how do I display the arguments to the processes?
Hi Larry,
If you want a more dirty-cheap solution, without installing anything,
you could also try something like this in a bash shell:
for i in /proc/[0-9]* ; do echo -n ${i#/proc/}: ; cat -v $i/cmdline
; echo ; done | sed -e 's/\^@/ /g'
--
___
Julio Costa
--
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: R: Cygwin 1.5 vs. 1.7: tail
Hi Roland, On Wed, Oct 28, 2009 at 11:15, Roland Schwingel wrote: Hi Marco, Thanks for your reply. Quoted e-mail edited; please see http://cygwin.com/acronyms/#PCYMTNQREAIYR Marco Atzeri wrote on 28.10.2009 12:05:09: --- Mer 28/10/09, Roland Schwingel ha scritto: the manual says tail -N +3 /path/to/some/file You mean tail -n +3 /path/to/some/file If I do that it will work fine. I just wonder it this change was on purpose or not, because the other form (without -n) still work on other systems like mac/linux. I do share my scripts across several platforms. And these particular tail line haven't changes for ages here. Depends on the version of tail and other GNU utilities. Please see this excerpt from the info tail: --- Scripts intended for use on standard hosts should avoid obsolete syntax and should use `-c COUNT[b]', `-n COUNT', and/or `-f' instead. If your script must also run on hosts that support only the obsolete syntax, you can often rewrite it to avoid problematic usages, e.g., by using `sed -n '$p'' rather than `tail -1'. If that's not possible, the script can use a test like `if tail -c +1 /dev/null /dev/null 21; then ...' to decide which syntax to use. Even if your script assumes the standard behavior, you should still beware usages whose behaviors differ depending on the POSIX version. For example, avoid `tail - main.c', since it might be interpreted as either `tail main.c' or as `tail -- - main.c'; avoid `tail -c 4', since it might mean either `tail -c4' or `tail -c 10 4'; and avoid `tail +4', since it might mean either `tail ./+4' or `tail -n +4'. --- Or this: --- The GNU utilities normally conform to the version of POSIX that is standard for your system. To cause them to conform to a different version of POSIX, define the `_POSIX2_VERSION' environment variable to a value of the form MM specifying the year and month the standard was adopted. Two values are currently supported for `_POSIX2_VERSION': `199209' stands for POSIX 1003.2-1992, and `200112' stands for POSIX 1003.1-2001. For example, if you have a newer system but are running software that assumes an older version of POSIX and uses `sort +1' or `tail +10', you can work around any compatibility problems by setting `_POSIX2_VERSION=199209' in your environment. --- So, you could try this, or using the standard form, -n NN ___ Julio Costa -- 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
hardlink giving out .lnk?
Something strange... at least to me. STC: /tmp$ uname -a CYGWIN_NT-5.1 PT00062412 1.7.0(0.214/5/3) 2009-10-03 14:33 i686 Cygwin /tmp$ ls -l /dev/log srw-rw-rw- 1 SYSTEM root 53 Oct 9 23:12 /dev/log /tmp$ ln /dev/log log /tmp$ ls -l total 1 srw-rw-rw- 2 SYSTEM root 53 Oct 9 23:12 log.lnk HUH? .lnk?? This is a **hard link**. And even if it was a symbolic, there's no more .lnk, unless we ask explicitely, right? FYI, I can do a ln -s log.lnk log, and it still works (eg., with logger), AFAICS. But this is probably not the intended way of working. -- ___ Julio Costa -- 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: OpenSSH - sftp not working for non-Administrator users
On Tue, Oct 6, 2009 at 10:15, Corinna Vinschen wrote: On Oct 5 20:18, Julio Costa wrote: On Mon, Oct 5, 2009 at 19:50, Corinna Vinschen wrote: Why don't you just put cygwin1.dll into $CHROOT-DIR/bin? I did. It obviously works. But I see this more as the workaround, not the solution. I'm trying to go from the workaround to the general solution. I think putting the DLL into /bin is the general solution. Ok. Solution 3). That closes this thread. Let's move on, then. I wrote this on this list a couple of times and I'm writing this again, as long as anybody wants to read it: Chroot is a bad hack, bad fake on Cygwin and I curse the day I added this to Cygwin. Don't use chroot and think you're safe. You're not. It's just a joke of a jail. Don't put too much work into it. I, certainly, won't. I'll open a new thread about these Chroot recurring misleads. It deserves a thread of it's own. -- ___ Julio Costa -- 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
Cygwin Chroot security considerations [WAS: OpenSSH - sftp not working for non-Administrator users]
On Tue, Oct 6, 2009 at 10:15, Corinna Vinschen wrote: I wrote this on this list a couple of times and I'm writing this again, as long as anybody wants to read it: Chroot is a bad hack, bad fake on Cygwin and I curse the day I added this to Cygwin. Please don't. It isn't a bad hack. Its a step forward to a proper chroot implementation, even if currently it's not even half way there. And it is always useful if you know how to handle with its shortcomings. Now there is an important statement that is useful to put with all emphasis for all future searchers out there: === Cygwin chroot is NOT a full (not even half) implementation of a Unix chroot. Don't expect Unix chroot-like security using the current Cygwin chroot implementation! === There. Now I wrote it too. :) Now that everyone got their warning, it would be extremely useful to enlist what are the specific shortcomings so that anyone who still wants to try that knows what is expected, about the (in)security of the solution. I'll give my 2cents here (correct me please if I say something wrong): The status quo regarding Chroot in Cygwin is: This is only a path filter, and only for file handling done exclusively through the posix (cygwin) API; So, the (big-as-a-whale) security hole is basically - anything that can call any Windows API file handling function! To control this, the security controls/ recommendations are: 1) ONLY setup chroots for Non-Admin users. Failing that, and there's no way (ever!) to control the user's actions. REALLY, it's non-negotiable :) 2) Setup the chroot so that there are NO writable files/directories - exception would be, of course, a single /pub dir to make file transfers; 3a) Setup a restricted shell (rbash comes to my mind, although I'd prefer something more light) so that there is no possibility to execute anything besides the commands made available; **This is to avoid a download of a script/exe to /pub and then execute it**. That's where the HOLE is right now. 3b) OR, use a suitable ForceCommand on sshd_config, although suitable will widely depends on the objectives for using sshd. As far as I can tell, and with a bare minimum commands in /bin, there is a possibility of getting things minimum secured, at least for the popular use of sshd, as a sftp/scp provider for secure file transfers. NOT as a general ssh remote shell service - not a chance! Don't use chroot and think you're safe. You're not. It's just a joke of a jail. Don't put too much work into it. I, certainly, won't. I certainly will. That's because this is better than nothing, **if you know what you are doing**, and **if you don't expect a Unix chroot**. Nevertheless, it's already an evolution from plain *blerg* Windows. As soon as I've my scripts stabilized, I'll share with you my way of setting this up, in a (hopefully) secure way. Please stay tuned... but don't hold your breath :) -- ___ Julio Costa -- 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: OpenSSH - sftp not working for non-Administrator users
Hi all, Please allow me to revive this thread... On Mon, Jul 20, 2009 at 12:57, Corinna Vinschen wrote: On Jul 20 13:43, Thorsten Kampe wrote: * Doug Lim (Mon, 20 Jul 2009 00:46:44 -0500) The cygcheck.out file shows that the cygwin directory was in the PATH when you ran the cygcheck program. It doesn't necessarily mean that it is the path that a service sees. I added D:\cygwin\bin to the PATH via the Environment Variables button on the Advanced tab in the System Properties control panel applet followed by a system reboot after cygwin and openssh were installed. If you're suggesting that's not sufficient for a running service to see the updated path, then what would you suggest should be done differently? Please read again what cgf wrote. Nevertheless there's something fishy. The /bin path is added automatically by cygrunsrv so that the service doesn't have to care for a default $PATH by itself. I assume it has something to do with path permissions. Check the ACLs. Corinna ... the reason is, I myselft stumped into something similar. After configuring openssh with chrooted sessions, I can login into one of these sessions (with a non-admin users), but any command that I try fail silently (unless it is a built-in). From what I observed with the help of process monitor, is that any failing command try to load cygwin1.dll from the current directory (/bin) but will fail, because the dll in in /usr/bin. This difference (/bin vs /usr/bin) is not of importance to the majority of the cases because: a) /bin and /usr/bin are mirrors of each other , through mount magic; b) /usr/bin is also in the PATH. But in a sshd chrooted environment thigs are different: there is no mount -magic, and the .dlls get copied to the /usr/bin, following advice from ldd. The PATH also only have /bin, which don't help. So, I was thinking, shouldn't make more sense that cygrunsrv do: a) add /usr/bin also as a bare-minimum, to cover chrooted environments (and to follow the /usr/bin/*.dll dependencies of cygwin binaries); b) add IN FRONT of PATH , not in the end, as it does now? Because this is calling for trouble. After all, cygrunsrv is for cygwin services, not Windows ones. Do I make any sense yet? :) -- ___ Julio Costa -- 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: OpenSSH - sftp not working for non-Administrator users
On Mon, Oct 5, 2009 at 19:50, Corinna Vinschen wrote: On Oct 5 16:07, Julio Costa wrote: On Mon, Jul 20, 2009 at 12:57, Corinna Vinschen wrote: Nevertheless there's something fishy. The /bin path is added automatically by cygrunsrv so that the service doesn't have to care for a default $PATH by itself. I assume it has something to do with path permissions. Check the ACLs. ... the reason is, I myselft stumped into something similar. After configuring openssh with chrooted sessions, I can login into one of these sessions (with a non-admin users), but any command that I try fail silently (unless it is a built-in). From what I observed with the help of process monitor, is that any failing command try to load cygwin1.dll from the current directory (/bin) but will fail, because the dll in in /usr/bin. This difference (/bin vs /usr/bin) is not of importance to the majority of the cases because: a) /bin and /usr/bin are mirrors of each other , through mount magic; b) /usr/bin is also in the PATH. But in a sshd chrooted environment thigs are different: there is no mount -magic, and the .dlls get copied to the /usr/bin, following advice from ldd. The PATH also only have /bin, which don't help. So, I was thinking, shouldn't make more sense that cygrunsrv do: a) add /usr/bin also as a bare-minimum, to cover chrooted environments (and to follow the /usr/bin/*.dll dependencies of cygwin binaries); Why don't you just put cygwin1.dll into $CHROOT-DIR/bin? I did. It obviously works. But I see this more as the workaround, not the solution. I'm trying to go from the workaround to the general solution. I see three probable paths here: 1) General solution: cygrunsrv should, as a cygwin service guardian, be responsible to setup a dependable bare-bone environment for any general use of a cygwin service. Adding /usr/bin:/bin in front of PATH would definitely contribute to it; 2) Specific solution: AFAICT, this problem only occours in sshd (with chroot involved). So, the same PATH amendment could be easily done by ssh-host-config at the service installation code; 3) Do-nothing solution: it's already done! And then every Cygwin user will have to struggle with strange happenings when trying to set up sshd/sftp chroots... even if it ends finding this thread that's not the kind of user experience that Cygwin should be, right? I'm not talking here about saving the world :) Clearly either solution 1) or 2) are one-liner patches - and I'm just asking what route do you think is better. Then I'll present the patch, no broken fingers! :) -- ___ Julio Costa -- 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: cygrunsrv/autossh howto start even the destination address is not reachable yet?
Hi, On Sun, Oct 4, 2009 at 17:57, Matthias Meyer wrote: Hi, I've running port forwarding in WindowsXP as well as Windows Vista by using autossh, running as a service, installed by cygrunsrv. cygrunsrv -I service-tunnel -f secure tunnel for service \ -n -t auto -y tcpip -O -u $priv_user -w $priv_pwd -p /bin/nice \ -a -n 10 /bin/autossh -R 12345:localhost:22 \ -M 0 -N -C -i /etc/ssh/id_rsa -p 24 u...@server.domain.at My problem is: If the client have a dialin connection to an internet provider, the internet connection isn't established when the autossh service will be started. Therefore I get an error message: ssh: Could not resolve hostname server.domain.at: no address associated with name How to configure/install the service wether in a way that he waits for an established internet connection or in a way that he try again until the hostname can be resolved? If autossh is started succesfull and I disconnect the internet connection, autossh will try again and again until the connection is established again. But autossh do not start if the hostname can not be resolved. I use autossh a lot, although not in a service. From what I can see, AUTOSSH_GATETIME is your friend. Add it to the service instalation with -e AUTOSSH_GATETIME=0 -- ___ Julio Costa -- 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
mkpasswd, mkgroup: __progname points to rubbish
Hi, In last cygwin beta: $ uname -a CYGWIN_NT-5.2 VFPT-ITSECVMT 1.7.0(0.212/5/3) 2009-09-11 01:25 i686 Cygwin If I do (obviously found by mistake): $ mkpasswd -n 0 mkpasswd: unknown option -- n Try '̨ a --help' for more information. Note the rubish after Try. Or, if I do: $ mkgroup -S-- ª a: Only one character allowed as domain\user separator character. Rubbish. But when I do: $ mkgroup -n 0 mkgroup: unknown option -- n Try 'mkgroup --help' for more information. ...OK! The difference is in the 'default' clause of the select statement in the getopt output handling in main(). In mkgroup.c, argv[0] is used; in mkpasswd.c, it's __progname. Several other places with error conditions are using __progname, and the problem is identical. another example: $ mkpasswd -p idiot/path ̨ a: 'idiot/path' is not a fully qualified path. So, I currently don't know WHY __progname it's apparently non-initialized. If it is obvious for you, I'll stop right here. If you'd like that I dig more deeper, please say so! -- ___ Julio Costa -- 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: syslog-ng: some packaging glitches
Hi,
On Thu, Mar 19, 2009 at 17:36, Julio Emanuel wrote:
Hi Corinna (I think this is with you),
I've been struggling with a small (but deadly) problem in the current
syslog-ng package:
~ $ cygcheck -c syslog-ng
Cygwin Package Information
Package Version Status
syslog-ng 3.0.1-1 OK
The service could not be started after running syslog-ng-config,
complaining like this: Improperly formatted configuration pragma,
colon expected; line='@version 3.0\x0a'.
This still happens :(
... and that's normal, because there were no new syslog releases since! :)
The patch (in correct order this time):
~ $ diff -u /usr/bin/syslog-ng-config.old /usr/bin/syslog-ng-config
--- /usr/bin/syslog-ng-config.old 2009-09-28 16:15:27.367887300 +0100
+++ /usr/bin/syslog-ng-config 2009-09-28 16:15:50.197327200 +0100
@@ -205,7 +205,7 @@
then
echo Creating default ${SYSCONFDIR}/syslog-ng.conf file
cat ${SYSCONFDIR}/syslog-ng.conf EOF
-...@version 3.0
+...@version: 3.0
options {
keep_hostname(yes);
owner(system);
Could we have a 3.0.1-2, please? Or a 3.0.x whatever. I recall that
there were some other problems, but those related with upstream code.
I'll probably bump into them in the new few hours :(
Also, as a sidenote, It's very disturbing finding that I'm the only
syslog-ng cygwin user in this 6+ months!?
At least I've no other explanation why no one else had problems with
syslog-ng...
--
___
Julio Costa
--
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: sftp on a Windows 2003 server
Dave, If you want to consider, maybe it would be better to try with the newer Cygwin version, 1.7. There was some changes/improvements related to environments and installations done by Domain users (instead of local ones) and also related to the use of public key authentications. And those are really needed in Win 2003 environments. The documentation links that Larry sent are already for the 1.7 version. If you will give a try, please remember to completly remove the current Cygwin installation. Then give us feedback if it behaved better. ___ Julio Costa -- 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: 1.7.0-51: Problem using ssh public/private key authentication
Hi Michael, On Thu, Jul 23, 2009 at 10:49, Michael H. wrote: Corinna Vinschen-2 wrote: On Jul 16 12:20, Michael H. wrote: Hello, When I am using cygwin 1.5 both the public/private key and the keyboard authentication with ssh work without problems. On 1.7 keyboard authentication also works but public/private key authentication produces following error on the machine which I use to connect to the server (client is Linux - server is Windows XP SP3 / Cygwin): 4 [main] -bash 3392 C:\cygwin\bin\bash.exe: *** fatal error - couldn't dynamically determine load address for 'WSAGetLastError' (handle 0x), Win32 error 126 Connection to xx.xx.xx.xx closed. I suspect of configuration / permissions problems... Are you setting up some kind of chroot? Also, is there any output on the /var/log/sshd.log file? Weird. Works fine for me. me too. Is it possible that there is anything wrong in the steps I have done to setup the host (listed in my first post)? At the first sight, no. But it's not clear if you are using the vanilla standard config files. If you did some change, it could be important to share with us. You can also try to run sshd by-hand to show us some verbose info: cygrunsrv -E sshd /usr/sbin/sshd -ddde Then you can try to connect to your PC and see if the generated output gives you any clue. NOTE: It's possible that the problem doesn't show up in this debugging mode. You will be running the sshd deamon as yourself, not as the SYSTEM account. ___ Julio Costa -- 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: popup consoles on Windows 7
On Sun, Jul 5, 2009 at 01:11, Christopher Faylor wrote: On Sat, Jul 04, 2009 at 12:14:31PM -0400, Christopher Faylor wrote: On Fri, Jul 03, 2009 at 11:02:12AM -0400, Christopher Faylor wrote: On Fri, Jul 03, 2009 at 12:44:23PM +0200, Corinna Vinschen wrote: I have some testing code which only tries to create an invisible console if the application to execv is not a Cygwin application. It seems to work nicely. I'm just not sure if it's really *that* simple... I actually had some plans (which I have talked about here from time to time) for the invisible console for cygwin apps so I am not ready to admit defeat for this method yet. I think I have a workaround for this which avoids the flashing console... I've checked in a workaround for the problem: http://cygwin.com/ml/cygwin-cvs/2009-q3/msg00010.html cgf rules!! I checked this by removing the Windows 7 code from mintty and rebuilding it. With the currently released version of Cygwin 1.7.0-50 this causes a windows console to be displayed on the screen along with the expected mintty window. With the 20090703 snapshot, which includes Corinna's workaround, I got a flashing console. With the code in CVS I got the expected behavior of no console flash. Cool! But not so cool as if M$FT would correct their bugs :( booo! As I type this I realize that I didn't really confirm that the new invisible console code has the desired effect in mintty. It is supposed to make some (native?) apps work better. I thought that one of the apps was the net command and I don't have any problems running it but does anyone remember a specific program (maybe even a cygwin program?) which required the existence of a console to work correctly? If so, I'd like to add it to the comments in the source code and verify that it still works. Remember old DOS days? EDIT. It even resizes my cmd window, so I bet it *must* have a strong reason to want a console. If you want to try a snapshot, make sure that you grab the new helper app cygwin-console-helper.exe and put it in /bin. Without this, you'll still see the same flashes as the 20090703 snapshot. The new .exe file is in here: http://cygwin.com/snapshots/cygwin-inst-20090704.tar.bz2 Thanks for looking (hard) into this. I've no Win7 right now, but I already downloaded a copy, just because of these matters. I'll try it during next week. -- ___ Julio Costa -- 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: popup consoles on Windows 7
On Thu, Jul 2, 2009 at 18:44, Christopher Faylor wrote: On Thu, Jul 02, 2009 at 05:41:18PM +0100, Julio Costa wrote: HKCU\Console\argv[0]\WindowPosition = 0x80008000, where argv[0] is the name of current command being launched Yes, I know, more klumsy workaround... I'm not happy with that also, but at least avoids the console *window* flashing. Alas, the ShowWindow stuff it's still needed for the taskbar icon :( You haven't programmed many multi-threaded, multi-process aware applications if you think that setting a registry key is going to work right. No, I haven't - Damn, I've been discovered! :) But now that you've mentioned it, I see your point. I was just reporting a result from an observational experiment. I even didn't done that with real code. But the usefulness of this registry hack was limited, as I referred. Oh well, back to the workbench :) Why on Earth are we having this trouble to have an available console all the time? Is it necessary to redirect the in/out streams? Is it another thing? I'm really trying to think 'out of the box', because it could be the case that there is another implementation path that doesn't really need consoles at all... Yeah, what were we thinking? We went out of our way to set up a hidden console, expending considerable effort to do so when they really weren't needed. Did I wrote something like that? Well, YOU did. How about if you think within the box and do a google search rather than suggesting that we didn't know what we were doing? Nice way to help others to help you. Even if they are waay below in the mighty coders scale, I don't think that's a reason to be rude. Not that it is a novelty, I've been following this mailing list for almost a year now. You know, you shouldn't take everything that is asked in this list as a criticism. I've probably didn't asked in the best way either, but you should have a much more flexible filter because not everyone on this list is English native. So, maybe there is a little language barrier that distorted the meaning I was trying to give the question. I just asked to clarify was a need (da console) expressed in various places, either in cygwin, in mintty, and probably many others, but found no explanation on this need, beside what was already said in this very thread. That only tell me that it is needed. Let me rephrase that in three questions: What happens if we launch commands without a console created? What are the type of programs that really need that console? Is it possible to identify them prior to launch them? -- ___ Julio Costa -- 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: popup consoles on Windows 7
On Fri, Jul 3, 2009 at 11:44, Corinna Vinschen wrote: On Jul 3 10:18, Julio Costa wrote: Let me rephrase that in three questions: What happens if we launch commands without a console created? That's actually the same question as the next one, isn't it? It is now, that I seen the answer to the next one :) What are the type of programs that really need that console? Cygwin processes don't worry about the console. They use what they get as file descriptors and live with that. Native processes exist in two variations. Some of them just use the stdio handles like Cygwin processes. Some of them require to be run in a console becasue they use Console I/O functions directly. Ahhh! That's the core problem... I didn't realize that there could be applications wanting to do that... Duh! These applications will fail miserably in a Cygwin environment not attached to a console. Unfortunately there are quite a lot of them used for Windows system administration. Rats! At least that's as far as I rememeber this whole issue. I may have forgotten some aspect, but I'm fairly sure that we can drop the hidden console business as far as only Cygwin processes are affected. Is it possible to identify them prior to launch them? Cygwin checks for a Cygwin application prior to execv it. Not a Cygwin application == may need a console. I have some testing code which only tries to create an invisible console if the application to execv is not a Cygwin application. It seems to work nicely. I'm just not sure if it's really *that* simple... Thanks for the clarification! Besides that, is it possible to distinguish if, being *not* a Cygwin application, it would *need* direct console IO? If I understand it correctly, knowing if an application is for subsystem windows or console does *not* give us a foolproof answer to if it would need the direct console IO. That's bad. This identification could be very handy to only try risky and costly things only when really needed... As for the action itself, to hide the console, I've been looking in the MS documentation and I saw some potential insteresting info about the STARTUPINFO passed to the CreateProcess: 1) Use STARTF_USEPOSITION, with dwX = dwY = 0x8000 (similar to the registry hack?); 2) OR, use STARTF_USESHOWWINDOW, with wShowWindow = SW_HIDE; 3) OR (far fetched) use lpDesktop with something 'WinStaHIDE\Default' I've not tested it (I've no access to a proper build system to do this, neither to a Win7). Probable drawbacks: 1) I'm guessing that NO window will show after even the created by child processess... Is it possible to change the dwFlags field on the child process, after it starts? That would solve it; 2) ditto; 3) It force us to do a SetProcessWindowStation and SetThreadDesktop to something that must be stored and passed to the child, after the AllocConsole is done ; AND, there is also the probability of Win7 just plain ignores the lpDesktop setting. Well, this is all I can see for now. Hope it helps somehow. -- ___ Julio Costa -- 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: popup consoles on Windows 7
On Sun, Jun 28, 2009 at 11:30, Corinna Vinschen wrote: On Jun 27 09:39, Andy Koppe wrote: 2009/6/26 Corinna Vinschen: On Jun 26 15:08, Julio Costa wrote: I've been following this discussion, crossing fingers to someone came to some conclusion, as this is the biggest show-stopper for Cygwin in several months. I've not access to a Win 7, but I would like at least to drop some ideas to someone with more insight comment on and (hopefully) come to a solution. 1) If we make a service (let's call it cygconsole, or include it in cygserver, whatever), with no desktop interaction, whose only purpose is to AllocConsole()... 1.a) do that console gets created? 1.b) Is it invisible? 2) IF the two answers are true, then 2.a) Do an arbitary process can do an attachconsole to the PID of that service? IF it is also an YES, we have a framework for an workaround/alternative implementation! Cool? It's an interesting idea, but rather tricky to implement. I assume you will get an ERROR_ACCESS_DENIED when trying to attach to a console of another user, and a cygserver service would usually run under SYSTEM. Relying on a service at all doesn't sound overly tempting, either. I'm still hoping for another solution. How about implementing this idea solely in the Cygwin DLL rather than through a service, i.e. the first process that needs a hidden console allocates one, and any subsequent processes attach to that. That could be better only because it's more manageable. But the service idea was precisely because I guess it's now the only way in Win7 to get an invisible console. Only problem is that the console is automatically freed once all processes using it have finished, so a new one would have to be allocated again when another process comes along that needs one. Yes, that is another downside, but still, it's an evolution Yeah, that could be an option as a per-session workaround if there's no other way to accomplish it. Speaking of that, I don't yet have another proposal or even a more concrete on my own proposed design, but until happier days, I' ve found that we can skip the console window flashing altogether if we write this registry key PRIOR to AllocConsole(): HKCU\Console\argv[0]\WindowPosition = 0x80008000, where argv[0] is the name of current command being launched Yes, I know, more klumsy workaround... I'm not happy with that also, but at least avoids the console *window* flashing. Alas, the ShowWindow stuff it's still needed for the taskbar icon :( As for my service proposal, the only concrete result so far is an error (bleah!) when AttachConsole. Curiously, not the ERROR_ACCESS DENIED, but the 31 (ERROR_GEN_FAILURE)... The next step is to play a little with security descriptors on the created console, but before I dive deeper, I'd like to make a stupid question... Why on Earth are we having this trouble to have an available console all the time? Is it necessary to redirect the in/out streams? Is it another thing? I'm really trying to think 'out of the box', because it could be the case that there is another implementation path that doesn't really need consoles at all... -- ___ Julio Costa -- 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: popup consoles on Windows 7
Hi, On Fri, Jun 26, 2009 at 14:36, Corinna Vinschen wrote: On Jun 26 13:41, Andy Koppe wrote: 2009/6/26 Corinna Vinschen: Forgot to say: the occurances of this could at least be reduced by trying AttachConsole to get a hold on the parent process' console, if any. When I attempted that in MinTTY, though, I couldn't make it work. Yes, I thought of trying AttachConsole first. It's a band-aid since it will of course not work if there's just no parent console That can be dealt with, because AttachConsole reports back whether it did manage to attach, so if it doesn't, one can then call AllocConsole and ShowWindowAsync. Yes, I'm aware how this would work. What I mean is, it's *still* a band-aid since in case of a fail to attach, you still have to alloc a console and you're back to the original problem. What we could do using that technique is to minimize the number of console windows. But it doesn't help to avoid them entirely. You have still cluttered your desktop, or rather, your taskbar with console windows. I've been following this discussion, crossing fingers to someone came to some conclusion, as this is the biggest show-stopper for Cygwin in several months. I've not access to a Win 7, but I would like at least to drop some ideas to someone with more insight comment on and (hopefully) come to a solution. 1) If we make a service (let's call it cygconsole, or include it in cygserver, whatever), with no desktop interaction, whose only purpose is to AllocConsole()... 1.a) do that console gets created? 1.b) Is it invisible? 2) IF the two answers are true, then 2.a) Do an arbitary process can do an attachconsole to the PID of that service? IF it is also an YES, we have a framework for an workaround/alternative implementation! Cool? (crossing fingers) ___ Julio Costa -- 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: [1.7] does LD_PRELOAD support more than 1 dll ?
On Fri, May 29, 2009 at 09:10, Marco Atzeri marco_atz...@yahoo.it wrote: the outcome is: $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll sudoku 3 [main] bash 12924 C:\cygwin2\bin\bash.exe: *** fatal error - error while loading shared libraries: /tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll: cannot open shared object file: No such file or directory Hangup while if I specify only 1 dll $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll sudoku it works. Is it a bug, feature or a BLODA issue ? I don't know if it still stands up to date, but after a minor googling, I stumbled upon this message: http://www.cygwin.com/ml/cygwin-cvs/2005-q2/msg00031.html Where it reads: * hookapi.cc (ld_preload): Use colon as a separator rather than space. So, it might worth the test :) Hope it helps. ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [cygcheck] produces repeated output - 6 times!
On Mon, May 4, 2009 at 09:25, Corinna Vinschen wrote: Bug in user as far as the position of the -v option is concerned. Try this: $ cygcheck -v /bin/ash.exe c:\cygwin\bin\ash.exe - os=4.0 img=1.0 sys=4.0 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2009/5/4 9:45 C:\WINDOWS\system32\ADVAPI32.DLL - os=5.1 img=5.1 sys=4.0 ADVAPI32.dll v0.0 ts=2009/2/6 12:02 C:\WINDOWS\system32\KERNEL32.dll - os=5.1 img=5.1 sys=4.0 KERNEL32.dll v0.0 ts=2009/3/21 12:36 C:\WINDOWS\system32\ntdll.dll - os=5.1 img=5.1 sys=4.10 ntdll.dll v0.0 ts=2009/2/6 12:01 C:\WINDOWS\system32\ntdll.dll (already done) C:\WINDOWS\system32\RPCRT4.dll - os=5.1 img=5.1 sys=4.10 RPCRT4.dll v0.0 ts=2008/4/13 21:20 C:\WINDOWS\system32\ADVAPI32.dll (recursive) C:\WINDOWS\system32\KERNEL32.dll (already done) C:\WINDOWS\system32\ntdll.dll (already done) C:\WINDOWS\system32\Secur32.dll - os=5.1 img=5.1 sys=4.0 Secur32.dll v0.0 ts=2009/2/3 12:24 C:\WINDOWS\system32\ADVAPI32.dll (recursive) C:\WINDOWS\system32\KERNEL32.dll (already done) C:\WINDOWS\system32\ntdll.dll (already done) C:\WINDOWS\system32\KERNEL32.dll (already done) C:\WINDOWS\system32\ntdll.dll (already done) C:\WINDOWS\system32\KERNEL32.dll (already done) Yes, you are right. Only yesterday I found out that - and I had to do source-code analisys to came to that conclusion! Why on earth, do you ask? Because: ~ $ cygcheck -h Usage: cygcheck PROGRAM [ -v ] [ -h ] cygcheck -c [ PACKAGE ] [ -d ] cygcheck -s [ -r ] [ -v ] [ -h ] cygcheck -k cygcheck -f FILE [ FILE ... ] cygcheck -l [ PACKAGE ] [ PACKAGE ... ] cygcheck -p REGEXP List system information, check installed packages, or query package database. [snip] Let me zoom on that: cygcheck **(followed by)** PROGRAM **(and THEN)** [ -v ] [ -h ] So, at least, a doc bug. Unfortunately, I'm so doc biased, that I had to do source code analysis to came to this simple conclusion - fortunately, YMMV :) Also, besides the usage message issue, I think that it should had complained about the inexistent '-v' file - that would had give me a tip. ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[cygcheck] produces repeated output - 6 times!
Hi all, I found a strange behaviour with cygcheck, regarding the listing of DLL dependencies. Please take a look at the following: ~ # uname -a CYGWIN_NT-5.2 vfpt-itsecvmt2 1.7.0(0.210/5/3) 2009-04-14 17:25 i686 Cygwin ~ # cygcheck /bin/ash.exe C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll ~ # cygcheck /bin/ash.exe -v C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\ash.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll Note: I tried with some more executables in /bin (ls, scp,bash...). All of them, when used with -v option, gave the same output, 6 times in a row. I was expecting a verbose (although useful) output, like the version numbers for libraries and such... Bug in cygcheck? Or bug in user? :) ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [openssh] service with domain user
On Tue, Apr 21, 2009 at 18:28, Corinna Vinschen wrote: Well, PTC. If you have a domain account, its rights are usually administered centralized. Not here. Who are we to change the user rights locally for that user? That's the responsibility of the admins. Precisely. In this context, I'm Admin (the local one). And here's another problem in domain environments: If the environment is using domain policies, It isn't. Not for privileges, anyway. you might even be out of luck to set the user rights at all on your local machine. Even in my tiny setup at home you would be unable to install a domain member machine and change cyg_server's rights. Of course. It that particular scenario. But it isn't mine. Just because there are cases in which the proposed implementation will not work (and they are supposed to be that way), it's not a reason to not implement for those folks who would, but they can't, just because it's not implemented. Actually I'm a bit surprised with the amount of (small, tiny, amounting to a huge pile) problems that I've bumped into which are most of the time related to the fact I'm using a domain user... Well, sorry about that. You got what you paid for. You're not the only domain user out there. You're expecting something which just isn't there. The script was meant to ease the installation for local users in the first place. In corporate or governmental environments I don't expect the script to work OOTB. The script will almost never meet the requirements exactly. Ok, that's the current status. That's precisely what I was asking with all this blahblah of mine. [...rants deleted...] Ok, sorry for the tone. I now think that I was putting too much expectation on the wrong features. Again, these service installation scripts are a volunteer effort which many users are happy with. Due to the complexity of different Windows installations they won't work smoothly in all environments. Too bad the script doesn't fit your needs, but, as others, I have only so much time to work on that stuff. Nobody is accusing of not working or anything... :) The objective of this mail was simply to sense if the current status regarding Cygwin vs domain users: 1) is expected to be that way (currently); 2) is desirable to change (in a more compatible way to domain users); 1) Is unquestionably answered: It is. 2) Apparently, by your argumentation, the answer is no. Nevertheless, we can close this subject for now. I will have to do something about this (for me, at least). It I found it suitable for patching Cygwin, PTC. And then it's your call. No hurt feelings or anything. Regarding editrights, I think that there is a problem also. Is the reported output in my previous email as expected? No. The account is missing the other rights I talked about in my first reply. I know that is missing rights. That's wasn't my question. I'll try to rephrase: Shouldn't the two 'editrights' commands, in the given context, give the same output? Or, as an alternative question: Why do the first 'editrights' command fails? ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [openssh] service with domain user
Why do the first 'editrights' command fails? Because I'm trying to do 'editrights' with a cygwin user, when editrights only accepts *Windows* users - duh! Once again, I took it for granted something that it just isn't there... So, forget this question, sorry for the noise... ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question: Desired owner/group when running setup-1.7.exe
On Tue, Apr 21, 2009 at 10:54, Corinna Vinschen wrote: On Apr 20 23:13, Julio Costa wrote: BUT, may I make one last wish? I think that if this is important enough to change in setup.exe, I think it is equally important to maintain after installation, by implementing the same algorith in (at least) mkpasswd to avoid incoherence. I understand what you're up to but you can't do that. The fact that an account is member of the Administrators group shouldn't lead to an automatism which sets its primary group to Administrators. That's probably nice and feasible in most cases for a local, non-domain account, but you can't just override the primary group choices in a active directory structure. Especially in big companies or governments the group memberships and primary groups have been chosen for a reason. Actually, I DO work for one of those - and their choice were... not choose, hence the default 'Domain Users' assignment. And my perception that the Windows primary group does not have an useful purpose. So I can't really agree with you, but as long as other administrators can work in an installation made by a Domain User (member of local admins)... I'll try to cut through the other bushes along the way. PS: I know, we can always edit passwd by hand. But this is more a question of why should we, when we already identified that there's a need for change in the gid algorithm? For local admin users it sounds like an interesting idea, for AD accounts I'm not going to do that. I think oranges, you think apples. You own the trees, so I guess I'll just paint apples in orange, as soon as I have them :) -- ___ Julio Costa
[openssh] service with domain user
Hi Cygwinners, I've been struggling with an openssh instalation in a test environment, with the following characteristics: 1) Host is a Windows 2003 sp2; So, privsep is enforced; 2) Installation of cygwin made with a domain user (local admin); 3) Main objective of sshd: file transfers and remote shell for either domain users (regular or admin) and local users (restricted only); After many tries and tests, I've come to the conclusion that for achieving 3), the sshd deamon should run with a domain user; no problem, we allocated one for that purpose. But now I can't make ssh(d) work correctly. I used the trick of adding the domain user to passwd and renaming it to cyg_server, and indeed the service got installed with the correct domain user, no questions asked (thanks, Corinna!). But, that's the end of the story. I can't make ssh work, and typically the message I see in logs is like this: sshd: PID 3572: fatal: seteuid 18606: Permission denied I thought that the correct permissions/privileges were assigned in the ssh-host-config... isn't that so? How do I find what is missing? Thanks for you help! PS: I'm also seeing strange things coming from editrights - see these (failed) attempts, that should give the same output: # This is for context: ~ $ grep cyg_server /etc/passwd cyg_server:unused:47000:10513:U-DOMAIN\SECSERVICE,S-1-5-21-682003330-2049760794-1801674531-37000:/home/SECSERVICE:/bin/bash ~ $ editrights -u cyg_server -l Error in getSID (LsaLookupNames returned 0xc18c=STATUS_TRUSTED_DOMAIN_FAILURE)! ~ $ editrights -u DOMAIN\\SECSERVICE -l SeServiceLogonRight Have Fun! (I'm not) ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [openssh] service with domain user
On Tue, Apr 21, 2009 at 16:31, Corinna Vinschen wrote: On Apr 21 14:56, Julio Costa wrote: I thought that the correct permissions/privileges were assigned in the ssh-host-config... isn't that so? How do I find what is missing? No, ssh-host-config can only set the user rights for the local account, and it only does so if it has been asked to create the account. If you pre-create the account (as you have to do if you use a domain account), you're responsible to give it the necessary rights yourself. You mean, like in shame on you domain user! take this broken wings and fly way!? Now seriously, I understand perfectly why it does not do that right now, taking the historical absence (as long as I can see) of domain-user-type users of Cygwin... but what if I asked Shouldn't that kind of setup be done in the script? (PTC is a logical answer, but still... I like to see it) Actually I'm a bit surprised with the amount of (small, tiny, amounting to a huge pile) problems that I've bumped into which are most of the time related to the fact I'm using a domain user... I'm working for a big corporation, and like such, every server is in some domain, and we all use our domain users to work in any server. As I'm not in THE systems or network admin's team, but in a server client or applicational admin team, I have the typical profile of Local Admin, Regular Domain User. Is that profile so rare out there? Is not something that Cygwin should support in a more friendly (if not transparent) manner? I, for one, created a cyg_server account using ssh-host-config on the domain controller, then created a domain policy to propagate the necessary permissions to other machines in the domain. That I can't do. But also do not need to, because I've my Cygwin work focused in one, two server at most, at the moment. You can also create the important rights(*) for this user on a per-machine base using editrights or native Windows tools. Precisely. Although I still thinking Why do I have to do this by hand? Regarding editrights, I think that there is a problem also. Is the reported output in my previous email as expected? Do you want me to start another thread on that? ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 11:07, Corinna Vinschen wrote: On Apr 19 10:27, Julio Costa wrote: [X ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: [...] I'm also more inclined to the 3rd option, although I've not taken that decision easily, because user foo would not see his/her files as foo's but as Admins's (actually root). But seems to be the more compatible solution. The least harm law... WHy do you think that? Setup.exe has nothing to do with the Cygwin DLL as far as file ownership is concerned. The files installed from the distro will be owned by Administrators, the files created within Cygwin will be owned by the user itself. I know that setup.exe is independent of cygwin.dll but - now I'm confused - are you saying that ONLY files installed by setup.exe will follow this new ownership rule, but subsequent executions / copying / file creations, etc, *inside* Cygwin environments will still use Admin:None or whatever for ownership? Are you saying that the proposed changes will be only at the *packaging* level, forced to have owner uid to that of Admins? In that case, how will you enforce ownership on pos-instalation scripts? That doesn't make much sense... and it's not even coherent behavior. And surely will break things in the long run. And I would add another rule: If the installing user is not Admin, but the primary group is 'Domain Users', change gid to 'Users', so that an instalation don't be inaccessible for local users. I don't think that's necessary. Either you're an admin and you want to install for everyone, or you are a user just installing for yourself. There's no other option and no need for another option. Yes, you're right. Fair enough. Never mind my (not so) bright idea :) -- ___ Julio Costa
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 14:58, Corinna Vinschen wrote: Sorry, but this is getting too complicated. I thought I'm asking a simple question. I was just trying to help this along so that the least number of people have trouble with the default file permissions. Here's another simple approach: Keep all ownership as it is. Just add an ACE for the administrators group with rw- access rights to the ACL of files created/unpacked by setup. I like that one too. Maybe even more simple would be to assign that ACE to the cygwin root, in the first install, and let it be inherited throughout all cygwin tree. PS: It really should be rwx, right? ___ Julio Costa
Re: Question: Desired owner/group when running setup-1.7.exe
On Mon, Apr 20, 2009 at 18:30, Corinna Vinschen wrote: I just re-thought the problem and came to a different idea. The whole problem seems tyo boil down to other administrators not bein able to manipulate Cygwin files in, say, /bin or /usr. But that's not really a problem since all Admin users have the right to manipulate all files, same as the root user on POSIX systems. There's actually no reason to add an ACE for administrators. You know, I thought that when I saw the ACE proposal... but then I decided it would be better to send you a telepathic message rather than an email g However, given that all users are in the group None, using this group for the default group ownership for files is rather insecure. On a POSIX system the files in the system directories are owned by a group which only sys admins are member of. In our case, that would be most closely resembled by the Admins group. So, actually I'm now rather leaning towards solution two. As long as it isn't the do-nothing solution, I'm already happy :) And thinking more on the subject, it seems that it is really for the better, because with the solution number 2, there is a coherence between what you see (group ownership) and what you get (root-admin-like permissions). BUT, may I make one last wish? I think that if this is important enough to change in setup.exe, I think it is equally important to maintain after installation, by implementing the same algorith in (at least) mkpasswd to avoid incoherence. The change (if solution 2) is in the algorithm for determining gid - instead of blindly take the primary group, add some tests for admins and act accordingly; this same algorithm should be in mkpasswd, so that all would be transparent and coherent after the deploy of packages. PS: I know, we can always edit passwd by hand. But this is more a question of why should we, when we already identified that there's a need for change in the gid algorithm? Sorry for the to and fro :} Sorry for being sticky - but I still believe these kind of changes are for the best on Cygwin's interoperability. -- ___ Julio Costa
Re: Question: Desired owner/group when running setup-1.7.exe
On Sat, Apr 18, 2009 at 17:52, Karl M wrote: ... So, here's the multiple choice question: How should setup.exe choose the file ownership for extracted files? [ ] I like it as it is. Just keep it. [ ] If the current user is an administrative user, make Administrators the group of the files: owner: Current user. group: Administrators. [X ] If the current user is an administrative user, make Administrators the owner of the files: owner: Administrators. group: The primary group of the account running setup. Comment: I like number 3 the best. I generally use Administrators none and 755 for everything but individual users files and special files that specific permissions for sshd and such. I currently run a script that hammers the permissions and ownership after each run of setup.exe. I usually just turn execute permissions on for everything, but I wouldn't mind doing a better job on that. My point also. I think running that kind of jobs is a no-option. What about having setup look at a special file and use the ACL as a template for what it does? Then, once a user has installed and configued, setup.exe won't bork it later. The only reason that I run a script after each setup is to fixup mounts and permissions. Perhaps setup could be given an initial template specification from the command line...that would not not add as much work to setup as GUI changes, and would all automated installs control over it. I don't think it is needed that level of complexity. The proposed defaults should be sane enough. I'm also more inclined to the 3rd option, although I've not taken that decision easily, because user foo would not see his/her files as foo's but as Admins's (actually root). But seems to be the more compatible solution. The least harm law... And I would add another rule: If the installing user is not Admin, but the primary group is 'Domain Users', change gid to 'Users', so that an instalation don't be inaccessible for local users. There is a fundamental usage philosophy difference between *nix and Windows: On *nix there is really ONE admin, root. So the group ownerships / permissions make sense implemented that way. If you don't have access, just do su (or sudo)! On Windows, It's very common to have multiple administrators (so it a schizophrenic root!), specially if we are not talking about our home computers :) So, if one admin leaves some files assigned to him but not the the group, things will be broken! Funny thing is, if implemented the 3rd option, all goes well, at 'display level', because then the root directory would show ownerships as 'root:none'. That looks like more *nix, right? :) Well, I hope I haven't said anything too stupid, because I confess I'm Windows biased by force of day-to-day business. But AFAICT, unless we had a full-working su (or sudo!) on Cygwin, either you let setup.exe be more flexible /compatible in ownerships, or risk to crop the usefulness of it. ___ Julio Costa
[1.7] Setup.exe default ownership of files in fresh install [Admin:None?]
Hi, I really had to give up and ask you all a bit of help understanding what is going on. Like the subject summarizes: After a fresh install of cygwin 1.7 (made with local user Administrator), all folder and files ownerships from cygwin root are: Administrator:None. administra...@vmguest ~ $ ls -la / total 9 drwxr-xr-x 1 Administrator None0 Apr 17 11:48 . drwxr-xr-x 1 Administrator None0 Apr 17 11:48 .. -rwxrwxrwx 1 Administrator None 57 Apr 17 11:48 Cygwin.bat -rwxrwxrwx 1 Administrator None 7022 Apr 17 11:48 Cygwin.ico drwxr-xr-x 1 Administrator None0 Apr 17 11:47 bin d--x--x--x 4 Administrator None0 Dec 1 2006 cygdrive drwxr-xr-x 1 Administrator None0 Apr 17 11:47 dev drwxr-xr-x 1 Administrator None0 Apr 17 11:47 etc drwxrwxrwx 1 Administrator None0 Apr 17 11:48 home drwxr-xr-x 1 Administrator None0 Apr 17 11:47 lib dr-xr-xr-x 10 Administrator None0 Dec 1 2006 proc drwxrwxrwt 1 Administrator None0 Apr 17 13:12 tmp drwxr-xr-x 1 Administrator None0 Apr 17 11:47 usr drwxr-xr-x 1 Administrator None0 Apr 17 11:47 var This makes very difficult to share the installation with other users - that will be the main objective in my case... This is being my number one suspect for a number of difficulties I've had trying to install a cygwin toolbox (I'll refrain from talking about that for now) on this host (it's a Vmware guest, actually) Is this an expected behaviour? Because right now it doesn't seems ok to me... Besides the usual 'cygcheck -s -v -r' in attach, I also send some background technical information run from Windows cmd.exe, before setup.exe runs, just to make sure that the 'Windows view' is the expected one - and it is. D:\install\cygwinwhoami /user /groups USER INFORMATION User NameSID vmguest\administratorS-1-5-21-221598610-1224240008-1772044280-500 GROUP INFORMATION - Group NameType SID Attributes = === Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group BUILTIN\AdministratorsAliasS-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner BUILTIN\Users AliasS-1-5-32-545 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\REMOTE INTERACTIVE LOGON Well-known group S-1-5-14 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\This OrganizationWell-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group Some light, please... -- ___ Julio Costa cygcheck.out Description: Binary data
Re: [1.7] Setup.exe default ownership of files in fresh install [Admin:None?]
On Fri, Apr 17, 2009 at 14:56, Corinna Vinschen wrote: On Apr 17 14:22, Julio Costa wrote: snip Like the subject summarizes: After a fresh install of cygwin 1.7 (made with local user Administrator), all folder and files ownerships from cygwin root are: Administrator:None. snip Is this an expected behaviour? Because right now it doesn't seems ok to me... But it is. Setup for 1.7 installs the files with POSIX permissions as they are stored in the tar archives, rather than using the ugly Windows default permissions. This is exactly what you'd expect on a Linux or UNIX box. That sounds like a good (and logic) thing to do, but... Except in some minor cases, the default permissions are usually so that you get full access for the owner and read and, where necessary, execute permissions. Once again, that makes sense, but... Why is that a problem for sharing the data with others? Like I said in my previous mail, this is a primary suspect of something not yet told about :) I'll start another thread on that later, because there could be a number of factors that can be contributing to my 'other' problems... I think that you should be counting, if not for other reasons, with the WTF factor. What I mean is: Anyone installing something with an administrator account (member of 'Administrators') is expecting to get group-wise permissions to the Administrators group (or 'root', using your default translation in passwd to make it POSIX-like). Currently it is assigned to the 'None' group. That's does not SEEM to be useful, even if it doesn't break anything at the surface. The mkpasswd also has the same problem: administra...@vmguest ~ $ mkpasswd -l -u Administrator Administrator:unused:500:513:U-VMGUEST\Administrator,S-1-5-21-221598610-1224240008-1772044280-500:/home/Administrator:/bin/bash administra...@vmguest ~ $ id uid=500(Administrator) gid=513(None) groups=0(root),544(Administrators),545(Users),513(None) Why it does not show gid=544(Administrators) or even gid=0(root)? Is this something so fundamentally different from POSIX? There is a similar problem with a domain user: domainu...@vmguest ~ $ mkpasswd -d -u domainuser DOMAINUSER:unused:18606:10513:U-DOMAIN\DOMAINUSER,S-1-5-21-682003330-2049763794-1831674531-8606:/home/DOMAINUSER:/bin/bash domainu...@vmguest ~ $ id uid=18606(domainuser) gid=10513(Domain Users) groups=0(root),544(Administrators),545(Users),10513(Domain Users) Once again, a logic output should be gid=544(Administrators) or even gid=0(root)... In the first installations I've made I were logged on with this domain user, and that proved to be the worst case, because the 'Domain Users' default group assigned to the cygwin root turned Cygwin not accessible even by Administrator(!)... see what I mean? Shouldn't this logic for determining the primary group follow some other... logic? For example, taking the output of whoami windows utility, I see that the BUILTIN\Administrators group is (like for the Administrator example) the only group marked with Group Owner in the attributes... maybe this is a way to choose from? The bottom line is... although it MAY not be breaking anything, doesn't seems logic, specially considering the observed behaviour. ___ Julio Costa
Re: [openssh] unnatended instalation + forcing service account
On Wed, Apr 15, 2009 at 16:38, Julio Costa wrote: I'm a bit in the busy side right now, but you can count with that patch until tomorrow, at most. Here it is (in attachment). ~ $ cygcheck -c openssh Cygwin Package Information Package VersionStatus openssh 5.2p1-1OK ~ $ diff -u /usr/bin/ssh-host-config /usr/local/bin/ssh-host-config ssh-host-config.diff It implements the use of the -f option of csih, when --yes or --no options are used in ssh-host-config. AND adds a -u | --user option to nominate the service account in an explicit way (with the -u option of csih). I've done some minimal tests and it seems ok. Have Fun! ___ Julio Costa ssh-host-config.diff Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [openssh] unnatended instalation + forcing service account
On Thu, Apr 16, 2009 at 17:52, Corinna Vinschen wrote:
[ ${opt_force} = yes ] opt_f=-f
[ -n ${user_account} ] opt_u=-u ${user_account}
csih_select_privileged_username ${opt_f} ${opt_u}
Shouldn't the last line read
csih_select_privileged_username ${opt_f} ${opt_u} sshd
Yes, I think it is yet another improvement.
That would make the script try to reuse the service account if it
already is installed... besides the display improvement (explicit
reference to the sshd service).
I just didn't add that because it was not being used in the original
code, and I though that there would be a design reason behind that -
like, for example, always force the privileged account selection
algorithm to run, even if there is a service installed?
That's your call. For me it's fine either way.
___
Julio Costa
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [openssh] unnatended instalation + forcing service account
On Wed, Apr 15, 2009 at 09:31, Corinna Vinschen wrote: On Apr 14 18:55, Julio Costa wrote: Now that Chuck has released a new csih, maybe also the possibility to use an alternative account could be added to this patch... Can you look into this, please? This is also important because in domain members server environments I found no way to make sshd work if it is not running under a domain account. It would be really nice to have ssh-host-config do this job (by parameters on command-line)... But that already worked all the time without having another parameter. If an account called cyg_server (cron_server, sshd_server) is already in /etc/passwd then it will be used. Just make sure that cyg_server is a domain account. I'm using this method locally as well. Sure, you're right. But this is an 'indirect' method to *make it work*, just like a workaround. I thought we could have the 'direct' method of nominate which account should be used to the service. But, as long as this behavior by design is documented in the README, or better yet, in the FAQ... I think that's ok. Does the above patch break this behaviour? No, it just allowed ssh-host-config to blindly accept the account chosen by the programmed algorithm, avoiding the dreadful question Do you want to use another account?. That is needed to allow unattended installations with ssh-host-config (using --yes). The core patch was really against csih, where is the account choice algorithm, but the patch on ssh-host-config is needed to make use of it. Came to think of it, there is also another possibility (and a simpler one), and that is to code the --yes option on the ssh-host-config to use the (new) -f option to the csih, avoiding coding the extra parameter (--force) just for this behavior. After all, this behavior should be required for --yes and possibly is not very useful if ssh-host-config is not invoked with --yes. What do you think? -- ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [openssh] unnatended instalation + forcing service account
On Wed, Apr 15, 2009 at 15:00, Charles Wilson wrote: Julio Costa wrote: Came to think of it, there is also another possibility (and a simpler one), and that is to code the --yes option on the ssh-host-config to use the (new) -f option to the csih, avoiding coding the extra parameter (--force) just for this behavior. After all, this behavior should be required for --yes and possibly is not very useful if ssh-host-config is not invoked with --yes. What do you think? That's what I did for iu-config; -y | --yes ) csih_auto_answer=yes opt_force=yes ;; -n | --no ) csih_auto_answer=no opt_force=yes ;; I then used $opt_force to determine whether -f should be passed to csih_select_privileged_username. Yes, you're right: with the --no option the 'force' option should also be a requirement. After all, if it is in 'auto-mode' doesn't make sense to ask for confirmations, does it? :) I'm a bit in the busy side right now, but you can count with that patch until tomorrow, at most. Have fun! ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[openssh] unnatended instalation + forcing service account
Hi Corinna, Did you get to see the proposed patch in this thread? http://sourceware.org/ml/cygwin/2009-03/msg00857.html http://sourceware.org/ml/cygwin/2009-03/msg00858.html Now that Chuck has released a new csih, maybe also the possibility to use an alternative account could be added to this patch... Can you look into this, please? This is also important because in domain members server environments I found no way to make sshd work if it is not running under a domain account. It would be really nice to have ssh-host-config do this job (by parameters on command-line)... If you feel comfortable with that, I can look into 'upgrading' that patch myself, and then get back to the list, because I really need this. It's just that I don't want to bump into your work just in case you are already looking into this subject. Ping? Have fun! ___ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: csih: Unattended installations are not possible
(or if user enters empty password)
# Returns 0 on total success
# Returns 1 on partial success (created user, but could not add
= [Cut here] ===
And as and example of client usage, my patch to ssh-host-config to
make it really unattended (also has a minor typo correction):
~/cygsetup/addons/usr/bin $ cygcheck -c openssh
Cygwin Package Information
Package VersionStatus
openssh 5.2p1-1OK
~/cygsetup/addons/usr/bin $ diff -u
/usr/src/openssh-5.2p1-1/contrib/cygwin/ssh-host-config
ssh-host-config
= [Cut here] ===
--- /usr/src/openssh-5.2p1-1/contrib/cygwin/ssh-host-config
2009-01-29 20:40:30.00100 +
+++ ssh-host-config 2009-03-24 15:09:30.0 +
@@ -287,6 +287,9 @@
csih_inform sshd requires. You need to have or to create a
privileged
csih_inform account. This script will help you do so.
echo
+
+ # Try to discover a privileged user, if possible the one
already used by sshd
+ csih_select_privileged_username ${with_force} sshd
if ! csih_create_privileged_user ${password_value}
then
csih_error_recoverable There was a serious problem
creating a privileged user.
@@ -432,6 +435,10 @@
csih_FORCE_PRIVILEGED_USER=yes
;;
+ -f | --force )
+with_force=-f
+;;
+
*)
echo usage: ${progname} [OPTION]...
echo
@@ -441,6 +448,7 @@
echo --debug -dEnable shell's debug output.
echo --yes-yAnswer all questions with \yes\
automatically.
echo --no -nAnswer all questions with \no\
automatically.
+echo --force -fDon't ask confirmation for sshd
account name.
echo --cygwin -c options Use \options\ as value for
CYGWIN environment var.
echo --port -p nsshd listens on port n.
echo --pwd-w passwd Use \pwd\ as password for
privileged user.
@@ -489,7 +497,7 @@
fi
# Create /var/empty file used as chroot jail for privilege separation
-csih_make_dir ${LOCALSTATEDIR}/empty Cannot create log directory.
+csih_make_dir ${LOCALSTATEDIR}/empty Cannot create chroot jail
base directory.
chmod 755 ${LOCALSTATEDIR}/empty
setfacl -m u:system:rwx ${LOCALSTATEDIR}/empty
= [Cut here] ===
With those patches, you can configure ssh in a snap:
ssh-host-config --yes --force --privileged --pwd $PASS --cygwin ''
ssh-user-config --yes --privileged --passphrase $MYPHRASE
Hope you can make something useful from these patches, because I think
this helps cygwin getting more 'smooth' in configuration activities.
Have fun!
___
Julio Costa
George Burns - Don't stay in bed, unless you can make money in bed.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: csih: Unattended installations are not possible
Sorry. Dumb gmail mailer wrapped some lines. Here are the patches, in attachments. Have Fun! ___ Julio Costa Charles Kettering - My interest is in the future because I am going to spend the rest of my life there. cygwin-service-installation-helper.sh.diff Description: Binary data ssh-host-config.diff Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] passwd: useless if used with a logged on domain user
On Mon, Mar 23, 2009 at 14:59, Corinna Vinschen wrote: On Mar 23 14:35, J?lio Costa wrote: On Sun, Mar 22, 2009 at 19:22, Corinna Vinschen wrote: On Mar 22 17:34, J?lio Costa wrote: ~ $ ./my_passwd.exe -S SYSTEM my_passwd: unknown user SYSTEM The SYSTEM user is not in the user database. So that's an expected result. It is in mine: ~ $ grep system /etc/passwd system:*:18:544:,S-1-5-18:: Let me rephrase: The SYSTEM user is not in the *Windows* user database. Ah, ok. So, this test was rubbish. Well, it's always good to test all code paths, right? :) I've come to some conclusions in this process. Here they are: #1 li - usri3_priv (line 552, 587 and 594) will only tell you if the logged on user is (isn't) admin in his/her LOGON domain! But what is needed here is to know if the logged on user is (isn't) admin in the TARGET domain/server, where is the TARGET account! So you mean we should rather check if the user is in the Administrators group (S-1-5-32-544)? Yes. Because the info in usri3_priv is wrong if you have different logon and target domains/servers, and you can't convince NetUserGetInfo to give you (e.g.) the local view (that is, query NULL server) about a domain user (that was the only way that could produce the right usri3_priv value in my test case). #2 Just querying (-S) the account characteristics does not need Admin priviledges, so the test in 552 should be done instead inside the i...@576; And should be a different test, from what is said in #1; #3 Generally, commands in Windows without providing additional information defaults to the local machine. So should passwd. Currently, I'm forced to say '-d $HOSTNAME' to ensure that the target user is really on the local machine. This is not coherent behaviour because it depends or not on if the current logged on user cames from a domain or is local. Currently the csih script breaks in his call to passwd due to this. Which breaks sshd-host-config (and maybe others?) I think the most coherent behaviour should be: 'if '-d' is not supplied, the TARGET domain is always LOCAL; otherwise, follow supplied domain'. It is precisely how NET USER and friends works, with the '/DOMAIN' parameter, with the added tweak that you don't even have to name the logon domain (although it could be done like this in passwd also, i think...) That sounds about right. I agree. Except in the case I'm just calling `passwd' without a user name in which case I definitely want to change my own password. Yes, of course. That is the primary/historical use of passwd, after all. But I'll keep trying to achieve a stable version. Unless, of course, you think that this is not the way(tm) to do it... Using CheckTokenMembership isn't quite the way to go. If I understand you right that the idea is just checking if the token contains the well-known Administrators group, I'll check in something equivalent. Ok. I'll be waiting for the a new check-in, then. Once again, many thanks for looking into this. __ Julio Costa -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] passwd: useless if used with a logged on domain user
On Mon, Mar 23, 2009 at 16:40, Corinna Vinschen wrote:
On Mar 23 15:33, Julio Costa wrote:
On Mon, Mar 23, 2009 at 14:59, Corinna Vinschen wrote:
Using CheckTokenMembership isn't quite the way to go. If I understand
you right that the idea is just checking if the token contains the
well-known Administrators group, I'll check in something equivalent.
Ok. I'll be waiting for the a new check-in, then.
I've applied another patch to passwd which now checks admin membership
by inspecting the token groups of the calling user. As you proposed,
the default is now the local machine, unless trying to change the
caller's password itself.
After a minor typo-killing:
~/passwd $ diff -u passwd_118.c passwd_118b.c
--- passwd_118.c2009-03-23 17:56:55.268054500 +
+++ passwd_118b.c 2009-03-23 18:10:55.925848600 +
@@ -571,7 +571,7 @@
strcpy (user, optind = argc ? getlogin () : argv[optind]);
/* Changing password for calling user? Use logonserver for user as well. */
- if (!server optind argc)
+ if (!server optind = argc)
{
myself = 1;
if ((logonserver = getenv (LOGONSERVER)))
All goes smooth:
~/passwd $ ./my_passwd_118b.exe -v
my_passwd_118b (cygwin) 1.5
Password Utility
Copyright 1999, 2000, 2001, 2002, 2003 Red Hat, Inc.
Compiled on Mar 23 2009
~/passwd $ id
uid=18606(security) gid=10513(Domain Users)
groups=0(root),544(Administrators),545(Users),10513(Domain Users)
~/passwd $ ./my_passwd_118b.exe -S
Account disabled : no
Password not required : no
User can't change password : yes
Password never expires : yes
Password expired : no
Latest password change : Wed Jul 18 15:34:32 2007
System password settings:
Max. password age 35 days
Min. password age 2 days
Force logout after 0 days
Min. password length: 8
# now with a local user
~/passwd $ id cyg_server
uid=1006(cyg_server) gid=544(Administrators) groups=544(Administrators)
~/passwd $ ./my_passwd_118b.exe -S cyg_server
Account disabled : no
Password not required : no
User can't change password : no
Password never expires : yes
Password expired : no
Latest password change : Sat Mar 21 01:21:39 2009
System password settings:
Max. password age 35 days
Min. password age 2 days
Force logout after 0 days
Min. password length: 0
# This is another user in the domain (not in /etc/passwd):
~/passwd $ ./my_passwd_118b.exe -S costaju
my_passwd_118b: unknown user costaju
~/passwd $ ./my_passwd_118b.exe -S costaju -d $LOGONSERVER
Account disabled : no
Password not required : no
User can't change password : no
Password never expires : no
Password expired : no
Latest password change : Wed Mar 11 15:40:35 2009
System password settings:
Max. password age 35 days
Min. password age 2 days
Force logout after 0 days
Min. password length: 8
~/passwd $
# And finally, the classic:
~/passwd $ ./my_passwd_118b.exe
Enter the new password (minimum of 5, maximum of 8 characters).
Please use a combination of upper and lower case letters and numbers.
New password:
Superb! Great work, Corinna!
___
Julio Costa
Robert Benchley - I have tried to know absolutely nothing about a
great many things, and I have succeeded fair...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
