Cygwin, Chris, Corinna - thanks!
Hi, It has likely been over a decade since Chris blasted me into orbit over something I stuck my head over the parapet for(*). Corinna I don't think I've ever wrangled with. Nevertheless, with the New Year beckoning it is about time I acknowledged just how much easier life has been because of them both. I've had a few beers tonight but even so, am I correct in thinking cygwin has been around since windows2000? (*) No can't remember. Something about FreeCiv. I wrote a sound kludge. Chris made me see cygwin "is unix". Anyways, there is no windoze system that I've ever had control of, that I haven't stuck cygwin on. Carry on the good work & Merry Crimbo! -- 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: mt and tar fail on LTO-5 drives
On Monday 19 August 2013 17:40:31 bartels wrote: > On 08/19/2013 06:31 PM, Eliot Moss wrote: > > First of all, it's not clear to me whether it is a Microsoft problem > > or a device driver problem. I would see what's known about the > > behavior of the devices and their drivers with the specific Windows > > version you have. Of course it could be that other tools don't need to > > ask those same questions, for some reason, so that they end up working > > fine .. > > Good thinking. > > Running W7 64 professional. > > It detects the HP drive and automatically installs some driver. > This driver shows the same behaviour as the HP driver. > > And then there is the IBM driver. Not sure if W7 installs a default > driver for that. Same story. This *might* be useful.. http://www-01.ibm.com/support/docview.wss?uid=swg21393009 ..particularly.. http://www-01.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html Please bear in mind the page is for TSM (Tivoli Storage Manager) so even if you find your drive in there it still may mean you need a driver. It is often the case when an IBM driver is required that both the driver and drive firmware must match. I'm going to duck out now except to say one more thing. When I've had to install TSM on a windows machine & it's gone wrong it has always been the driver (or getting windows to use the right driver) at fault. Guy > What does that tell you? > > - Bartels > > -- > 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 -- 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: Windows 7, cron, permissions
Hi Marco, Sorry. I believed it best to post all available details. The key problem is this message.. Access Denied. Administrator permissions are needed to use the selected options. Use an administrator command prompt to complete these tasks. On Monday 28 May 2012 16:59:45 marco atzeri wrote: > On 5/28/2012 4:11 PM, Guy Harrison wrote: > > Hi Folks, > > > > The actual fault lies in 'cj-defrag' where 'cjx' mails the output > > of 'cj-defrag'. 'cj-defrag' calls a child script 'sd-defrag' and > > all 'sd-defrag' does is call "df.exe". The single line at the bottom > > simplifies the problem: do a quick defrag of the E: drive. > > [cut] > > please rewind and try to explain your problem so that anyone that > has no clue of your problem could follow you. I already had headache > after the first sentences. > > Did you notice that your mail was the supposed 1st mail of a > chain and we have no background of your experience.. TIA Guy -- 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
Windows 7, cron, permissions
Hi Folks, The actual fault lies in 'cj-defrag' where 'cjx' mails the output of 'cj-defrag'. 'cj-defrag' calls a child script 'sd-defrag' and all 'sd-defrag' does is call "df.exe". The single line at the bottom simplifies the problem: do a quick defrag of the E: drive. The other issue was $TMP being set to somewhere unwritable. This is a work machine so I'm assuming it's some daft policy setting. Setting TMP to "/tmp" fixed that. $ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.Uu0sojHu8c installed on Mon May 28 14:46:36 2012) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) PATH="$HOME/bin:/usr/local/sd/bin:/usr/local/bin:/usr/bin:/bin" TMP="/tmp" #-- #minhrs dom mon dow cj exe args #-- ##20 12 * * * cjx cj-my-backup ##29 12 * * * cjx cj-df ##30 12 * * * cjx cj-updatedb ##40 12 * * * cjx cj-defrag ##01 */4 * * * cjx chk-au #-- * * * * * /cygdrive/c/Program\ Files/Defraggler/df.exe E: /QD $ cd&& cat cron.log This file was written by the /usr/bin/cronlog script on 20120528_144702 From: root (Cron Daemon) To: zrgh1 Subject: Cron /cygdrive/c/Program\ Files/Defraggler/df.ex e E: /QD X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: <**> Access Denied. Administrator permissions are needed to use the selected options. Use an administrator command prompt to complete these tasks. User "cyg_server" is a member of "Administrators" and UAC is disabled. I have checked the "Run this program as an administrator" option(*) on the shortcut (compatibility tab) to the desktop mintty terminal before running 'cron-config'. (*) Ditto for "setup.exe". Created a shortcut to that and always run as administrator. When I run.. "/cygdrive/c/Program\ Files/Defraggler/df.exe E: /QD" ..from the mintty command line all is well. It appears (**) the cron daemon is not getting privileges to run "df.exe" but I am stumped on how to proceed. TIA Guy -- 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: IBM ssh gateway
[snip] > > ..unfortunately I can't post the value for SSH_USER but as previously > > posted SSH_GATE is "198.81.193.104". Is it possible for others to try.. > > $ ssh -vv 198.81.193.104 > > ..as that's enough to trigger the fault. On Thursday 02 February 2012 04:38:59 Larry Hall (Cygwin) wrote: > > Indeed. I do see that even if I limit authentication methods to > password. And it does go through OK if I use a web client (serfish). Thanks for the help guys. I have raised a problem report with IBM and will let the list know the outcome. It may be some time though, software issues can take a few weeks! TIA Guy -- 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: IBM ssh gateway
On Wednesday 01 February 2012 18:04:19 Larry Hall (Cygwin) wrote: > On 2/1/2012 9:42 AM, Guy Harrison wrote: > > Hi Ryan, > > > > On Wednesday 01 February 2012 13:43:32 Ryan Johnson wrote: > >> On 01/02/2012 5:46 AM, Guy Harrison wrote: > >>> Hi Folks, > >>> > >>> Can anyone help interpret this? I am fairly certain the problem lies > >>> with IBM but I am no crypto expert. Is (for instance) the server > >>> rejecting the connection because (say) it does not understand ECDSA? > >>> Unfortunately I do not have an older instance of cygwin ssh to try > >>> that theory out. The failure is recent. I upgraded my cygwin > >>> instances over xmas. > >>> > >>> My primary concern is that the latter (linux) connection (after ~~~) > >>> may fail after a future upgrade. > >> > >> I would definitely check with your local network security folks. When > >> I was last at IBM I had trouble connecting from a certain machine -- > >> just that one -- and nobody could figure out why. Finally, it turned > >> out that I had a lot of locales installed and the long list of > >> supported languages announced by my ssh client triggered some firewall > >> rule. > > > > Unfortunately I forgot to mention the problem occurs both from my home > > network and via my work network (which I could easily have believed was > > at fault - they've messed with it a lot recently). The ~~~ linux box > > above connects via my home network but I have an aix box at work that > > also connects successfully whereas work cygwin (that's on XP) fails in > > the same fashion as my original post. > > So you're defining a successful connection as one where any key file is > ignored/invalidated and you're left to login with your password? Yes. Only password authentification is allowed on that IP address. Once connected, it is possible to connect to virtual machines we have set up via our company account. Ordinarily our usual scenario is to connect to the gateway with a username plus forward some local ports.. $ ssh \ -L "$RHE55_SSH"":""$RHE55":22 \ -L "$RHE55_VNC"":""$RHE55":5900 \ -L "$RHE55_SQL"":""$RHE55":3306 \ \ "$SSH_USER"@"$SSH_GATE" ..which will facilitate subsequent key authentification via the local port.. $ ssh -p $RHE55_SSH -YC \ -o UserKnownHostsFile=/dev/null \ -o StrictHostKeyChecking=no \ $SSH_USER@localhost "$@" ..unfortunately I can't post the value for SSH_USER but as previously posted SSH_GATE is "198.81.193.104". Is it possible for others to try.. $ ssh -vv 198.81.193.104 ..as that's enough to trigger the fault. > That's > what you're showing with the Linux machine. If that's the benchmark, > have you tried eliminating your keys on your Cygwin machine to see if you > get to the same point as Linux? Yes. Same fault occurs with no valid keys. :-| TIA Guy -- 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: IBM ssh gateway
Hi Ryan, On Wednesday 01 February 2012 13:43:32 Ryan Johnson wrote: > On 01/02/2012 5:46 AM, Guy Harrison wrote: > > Hi Folks, > > > > Can anyone help interpret this? I am fairly certain the problem lies > > with IBM but I am no crypto expert. Is (for instance) the server > > rejecting the connection because (say) it does not understand ECDSA? > > Unfortunately I do not have an older instance of cygwin ssh to try that > > theory out. The failure is recent. I upgraded my cygwin instances over > > xmas. > > > > My primary concern is that the latter (linux) connection (after ~~~) > > may fail after a future upgrade. > > I would definitely check with your local network security folks. When I > was last at IBM I had trouble connecting from a certain machine -- just > that one -- and nobody could figure out why. Finally, it turned out that > I had a lot of locales installed and the long list of supported > languages announced by my ssh client triggered some firewall rule. Unfortunately I forgot to mention the problem occurs both from my home network and via my work network (which I could easily have believed was at fault - they've messed with it a lot recently). The ~~~ linux box above connects via my home network but I have an aix box at work that also connects successfully whereas work cygwin (that's on XP) fails in the same fashion as my original post. I'm not sure about checking the locale's passed? None of the windows boxes have anything other than en_US/en_GB installed though. > Meanwhile, have you tried using `ssh -i' with a different key type? That > should clarify whether it's an ECDSA issue, at least. No change I'm afraid.. ssh -vvv -i ~/.ssh/id_dsa.pub 198.81.193.104 ..no point duplicating the original output. Fwiw there is only a DSA key on all these boxes. TIA Guy -- 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
IBM ssh gateway
Hi Folks, Can anyone help interpret this? I am fairly certain the problem lies with IBM but I am no crypto expert. Is (for instance) the server rejecting the connection because (say) it does not understand ECDSA? Unfortunately I do not have an older instance of cygwin ssh to try that theory out. The failure is recent. I upgraded my cygwin instances over xmas. My primary concern is that the latter (linux) connection (after ~~~) may fail after a future upgrade. (windows 2003 server 32bit) $ cygcheck -cd | egrep "ssh|ssl" libopenssl098 0.9.8t-1 openssh 5.9p1-1 openssl 0.9.8t-1 $ ssh -vvv 198.81.193.10 OpenSSH_5.9p1, OpenSSL 0.9.8t 18 Jan 2012 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 198.81.193.104 [198.81.193.104] port 22. debug1: Connection established. debug1: identity file /home/Administrator/.ssh/id_rsa type -1 debug1: identity file /home/Administrator/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/Administrator/.ssh/id_dsa" as a RSA1 public key debug1: identity file /home/Administrator/.ssh/id_dsa type 2 debug1: identity file /home/Administrator/.ssh/id_dsa-cert type -1 debug1: identity file /home/Administrator/.ssh/id_ecdsa type -1 debug1: identity file /home/Administrator/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 debug1: match: OpenSSH_5.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "198.81.193.104" from file "/home/Administrator/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Read from socket failed: Connection reset by peer ~~~ [admin@sdvmc32v5 ~]$ cat /etc/redhat-release CentOS release 5.7 (Final) [admin@sdvmc32v5 ~]$ uname -a Linux sdvmc32v5 2.6.18-274.17.1.el5 #1 SMP Tue J
Re: accessing cygwin functions from non-cygwin app
On Tue, 26 Nov 2002 11:13:20 +0100, "Jan Beulich" <[EMAIL PROTECTED]>
wrote:
>Hello,
>
>while I was trying to understand this on my own I'm ready to give up. All
>I intended was translating a coupld of filenames from cygwin to Win32 notation
>in an otherwise Win32-only app. I quickly realized that cygwin1.dll does not
>do all the necessary initialization on its own, i.e. from DllMain. Instead it
>appears that I am expected to explicitly call one or more functions inside the
>DLL to perform thisinitialization. However, whatever I tried (dll_crt0,
>dll_dllcrt0) didn't work (i.e. crashed due to insufficient prior initialization),
>but cygwin_attach_dll is neither exported from the DLL nor would it, from its
>use inside the sources, appear to be meant for the case I'm dealing with
>(where a main executaböle directly attaches to cygwin1.dll). And even if
>this is the function to use, then I have a problem using it as the application
>cannot be expected to have access to the perprocess class (nor is the app a
>C++ app, and neither is it being built with gcc) or other cygwin sources, and
>it also cannot link against libcygwin.a.
>Any advice on what I am missing here in this as I originally thought simple
>scenario would be very welcome - thank you in advance!
You need "cygpath". You have system(). You know the full path to
cygwin1.dll (either you supplied it or via ::GetModuleFileName or
registry mount "/") so can replace the explicit path in the crude
example below with the proper one...
int
main(int argc, char *argv[])
{const char sfx[] ="j:/cygwin/bin/cygpath -wa ";
char cmd [MAX_PATH + sizeof(sfx) + 1];
if (argc < 2)
return EXIT_FAILURE
;
sprintf(cmd,"%s%s",sfx,argv[1]);
system(cmd);
return EXIT_SUCCESS; //ahem
}
...you'd probably want to programatically prefix your "j:/cygwin/bin" to
PATH prior to system(). If you go via the '-e' option of bash/sh then
you'd be able to use a wrapper script to convert more than one at once
or call your own cygwin app that invokes the relevent functions
directly.
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gcc problem?
On Thu, 21 Nov 2002 10:46:26 +0800, "Carlo Florendo" <[EMAIL PROTECTED]>
wrote:
>Hello,
>
>Ever since I installed a newer cygwin, I've encountered problems which I
>didn't encounter before. First, there was the
>"ls -l"problem which has not yet been resolved (and which is threaded as "ls
>problem" in this list.). Just today, i discovered something wrong while
>using gcc. I compiled the snippet below and it's supposed to prompt me for
>input twice. However, I only get prompted once. (Using the visual c++
>compiler, the borland 5.5 compiler gives the correct results)
The reverse is true for the example below: ie you were encountering
problems before, but not realising it.
>My gcc version is 2.95.3-5.
>Cygwin version is The cygwin1.dll version I am using is
>1.3.15-cygwin-1-3-15-1.
>
>---begin snippet-
>#include
>int main()
>{
> int n;
> char string[80];
> for ( n=0 ; n<2 ; n++ )
> {
> printf( "Enter some words: " );
> scanf( "%s", string);
> printf( "The first word you entered is : %s\n", string );
> fflush ( stdin );
^^^hint: "while('\n'!=getchar());"
> }
> return 0;
>}
You can't flush(stdin). Nothing wrong with Cygwin here, simply the other
compilers implementing stuff that isn't part of the language. The FAQ
for comp.lang.c or alt.comp.lang.learn.c-c++ will no doubt give you
ample insight.
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: (Serious) X11 problem
On Fri, 1 Nov 2002 21:31:37 +0100, jblazi <[EMAIL PROTECTED]> wrote: >I have tried to compile an X11 program from the Guile tutorial >http://www.gnu.org/software/guile/docs/guile-tut/tortoise1.html. I could >compile it but when I run it from bash, I get a core dump. I don't program X, nevertheless there's nothing there that I can see which checks for the existence of an X server. Looks like all the error checking has been omitted for tutorial clarity. Here's a hint on avoidance until you reach the tutorial which does it in code... #! /bin/sh if [ -z "$DISPLAY" ] then echo "No X atm" exit `false` else "$HOME"/tortoise1 fi Either of "info bash" or "man ash" (ash=sh). >On the Linux system I use for my work, the program runs flawlessly. I cannot >tell if this is because the program is badly written (that is not >well-behaved) or because there is a bug Cygwin / X11 somewhere. echo $DISPLAY man X >I shall not need X11 (as far as I can tell now) on Windows, but I thought this >may be interesting for Cygwin community. > >(By the way: Cygwin seems to be a phantastic product, now that learnt a few >things with a lot of help from this mailing list.) Loosely, you just need to launch a command shell from inside X and it'll run. Fyi it does work. -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin, GNU make and VC++ ?
On Mon, 28 Oct 2002 22:51:21 -0500, Christophe Dupre <[EMAIL PROTECTED]> wrote: >Hello everyone, >I'm trying to recompile a homegrown program that was originaly >developped for Unix under Windows. We were successful in compiling this >program with the cygwin-supplied gcc using our current Makefile. > >Now we'd like to recompile with the 'native' compiler, cl.exe provided >with Visual Studio, as some believe the native compile would produce >faster binaries (it's a long-running analysis code - even 5% speedup >would be significant). Also, the gcc binary can't seem to be able to >allocate more than 1024MB of memory, even though the machine has 4GB >physical (this is under Windows 2000). Even then, we had to modify a >registry key to be able to use more than 256MB, which is not great for >end-users. Take a look at the "-mno-cygwin" flag. I don't know what the ram issues are there but it will speed things up (no cygwin1.dll) while you solve your VC issues. >Anyway, we're making progress in being able to compile with CL.EXE, but >we're having trouble with include files. We use the flag >'-I/home/user/dg/include' to point to the include directory, but it >can't find it. If we use '-I../include' it works, but for many reasons >we need to be able to specify absolute paths for include files. > >Has anyone done that ? I was not able to find anything relevant in the >archives. For Borland Builder, yes. Initially three scripts (mutated into a program after a while): "bcc", "b++" and "bar" corresponding to "gcc", "g++", and "ar" respectively: borland linker driven via compiler so no need for a "bld" at the time. Worked well (CXX=b++ AR=bar etc) considering how crude it was. Essentially they recreated a plain windows environment, translated gcc options and rearranged gcc command line ordering into rough bcc32 equivilents (along with a "pass-through" option for precise control). -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fwd: problem compiling under cygwin
On Thu, 31 Oct 2002 13:11:36 +0100, Stan Pinte <[EMAIL PROTECTED]> wrote: > >hello, > >I am trying to compile something under a pretty recent version of cygwin, >and it fails, because > >typedef complex sim_complex; > >gives that error: > >../gossip/sim.h:37: syntax error before `;' token > >Here enclosed the full stacktrace. g++ v3 ? It doesn't ignore standard namespace like v2. "std::complex" for instance. -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Viruses being transported with cygwin messages
On Sun, 13 Oct 2002 21:36:02 -0400, "Gregg C Levine" <[EMAIL PROTECTED]> wrote: >Hello from Gregg C Levine >Okay. I'll agree with you on that notion, Christopher. No real arguement >there. Now as to about those messages? Are those actual messages? I'm >inclined to think not. Nope. Two arrived here. The original messages are in the archives... http://sources.redhat.com/ml/cygwin/2002-08/msg00071.html http://sources.redhat.com/ml/cygwin/2002-02/msg00636.html ...whereas the new arrivals have truncated html-ized text and what looks like Bugbear - identical 50.6k (?upx compressed?) binaries: connexionscard-pass.txt.scr james_simmons_1.jpg.scr Neither has any connection with their original poster. -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cvs cygwin1.dll
On Thu, 26 Sep 2002 10:42:56 -0400, Christopher Faylor <[EMAIL PROTECTED]> wrote: >On Thu, Sep 26, 2002 at 05:20:53AM +0000, Guy Harrison wrote: [snip] >>If I knew unix I probably could - it's preventing me understanding >>crucial aspects of the cygwin dll. Nevertheless, methinks we're both >>correct. I've been thinking along these lines... > >Why are you mentioning UNIX? This is all Windows code. > >Nevermind. You don't have to answer that. This conversation is becoming >Derbyshire-esq. Sigh! >Let me ask a simple question: Do you still have problems with the >current version of cvs? Just a yes or no answer please. No descents >into code. No tweaking values that you think are causing problems. No >colloquial observations. Just "yes, it works" or "no, it still hangs". No, it still hangs. -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cvs cygwin1.dll
On Sun, 22 Sep 2002 12:40:54 -0400, Christopher Faylor <[EMAIL PROTECTED]>
wrote:
>>>On Fri, Sep 20, 2002 at 11:26:42AM +0000, Guy Harrison wrote:
>>>>On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <[EMAIL PROTECTED]>
>>>>wrote:
>>
>>Shame us non-developers can't get it "readonly".
>>http://cygwin.com/ml/cygwin-developers/2002-09/msg00071.html
>
>Yeah. Life's a bitch, isn't it?
Yep!
>Anyway, you are looking at the wrong message.
>
>Remember this?
Yes, sorry. I neglected to acknowledge your comment. Too many dratted
interruptions around here.
>On Fri, Sep 20, 2002 at 11:56:57AM -0400, Christopher Faylor wrote:
>>I suspect that this is actualy due to a deadlock in the code init.cc
>>which was recently discussed in cygwin-developers.
>
>If you look at my message which immediately follows the one that you mention
>which actually *mentions init.cc*, you will see the cause of at least one
>deadlock-on-exit in cygwin.
>
>Robert Collins has vowed to fix this problem this weekend. Until then,
>however, I have commented out the code in question.
Okidoki.
>>>I don't think it has anything to do with suspended threads. You can
>>>certainly verify this by adding code to kill the threads specifically,
>>>though, and see what happens.
>>
>>I did. I declared threads[1]. All the work gets shoved onto
>>cygthread::simplestub which neither suspends nor stays resident.
>
>Not the same thing at all.
I don't follow the implication. Had the fault been in info->func() then
::simplestub would have done same. It didn't. Explicitly terminating the
thread would bypass the dll detach/race thereby imposing a much greater
impact on code behaviour.
>>Hung process:
>>
>>Name-Pid-Pri-Thd--HndMem-User-Time---Kernel-Time---Elapsed-Time
>>sh---344---4---1---67---1832---0:00:00.020---0:00:00.0800:02:29.935
>>--VM--WS---WS-PkPriv---Faults-NonP-Page-PageFile
>>--351732183219641476--4923---21-1476
>>-Tid-PriCswtchState-User-Time---Kernel-Time---Elapsed-Time
>>-548---4-1---Wait:Suspended---0:00:00.000---0:00:00.0000:02:29.825
>>
>>Relevent log:
>>
>>Quick Key:
>> 90 GetCommandLine() chars
>>[n/32] =threads[n] of NTHREADS=32
>>mti=main_thread_id
>>nam=ignore fixed on "mti" here
>>sdc=SD_count (member added to cygthread class) suspend count
>>av =threads[].avail
>>id =threads[].id
>>h =threads[].h
>>sus=another suspend count
>>gle=GetLastError() for failed "sus"
>>
>><344/509> cli(90):J:\cygwin\bin\sh.exe
>>pid=344 tid=509[0/32]{mti:509}: nam=[main] sdc=-999 av=877 id=0 h=296
>>sus=2 gle=0
>>pid=344 tid=509[1/32]{mti:509}: nam=[main] sdc=-999 av=212 id=0 h=300
>>sus=2 gle=0
>>pid=344 tid=509[2/32]{mti:509}: nam=[main] sdc=-999 av=894 id=0 h=304
>>sus=2 gle=0
>>pid=344 tid=509[3/32]{mti:509}: nam=[main] sdc=-999 av=482 id=0 h=308
>>sus=2 gle=0
>>
>>The ::SuspendThread() and ::ResumeThread() calls in cygthread.cc assign
>>their result directly to SD_count. I set it explicity to silly negative
>>values at these points:
>>
>>-999 in cygthread::runner() after their ::CreateThread()
>>-99 in cygthread::stub just prior to init_exceptions()
>>-2 cygthread::exit_thread ::SetEvent()
>>- cygthread::stub ::ExitThread()
>>
>>Nothing else touches 'SD_count'. The above output is generated by a
>>function 'SD_DumpLiving()' inserted immediately prior to ::ExitProcess()
>>within _pinfo::exit().
>>
>>Our hung process is definately suspended.
>
>Not necessarily. I see nothing in the above which would disprove the
>theory that this is the problem which I raised in cygwin-developers. Of
>course, I am not 100% sure that I understand the above data.
No worries. One big multi meg file or [ahem] 16,000+ tiny ones. Didn't
think I ought to post that. The main point is (non-static)
cygthread::SD_count is explicitly initialised by me. I've often seen the
later members of the threads[] array zero.
I've looked into that aspect a bit more. Other perfectly functional
processes are having this occur. For instance, the "sig" thread isn't
always getting allocated into threads[NTHREADS-1] but earlier up and
threads["sig"+1]..threads[NTHREADS-1] are all zero. AFAIKT this isn't a
bug, the current cygthread::new() code looks able to cope. I mention it
on the off-chance that being able to "new cygthread" pri
Re: cvs cygwin1.dll
On Fri, 20 Sep 2002 11:56:57 -0400, Christopher Faylor <[EMAIL PROTECTED]> wrote: >On Fri, Sep 20, 2002 at 11:26:42AM +0000, Guy Harrison wrote: >>On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <[EMAIL PROTECTED]> >>wrote: Shame us non-developers can't get it "readonly". http://cygwin.com/ml/cygwin-developers/2002-09/msg00071.html ...sounds *exactly* like my problem. Moreover the build date on my last cygwin1.dll that works is 2002-07-11. Similar timeframe. >>>On Wed, Sep 18, 2002 at 06:42:50PM +, Guy Harrison wrote: >>>>On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <[EMAIL PROTECTED]> >>>>wrote: >>>> >>>>>On Fri, Sep 13, 2002 at 09:09:37AM +, Guy Harrison wrote: >>>>>>I can't seem to figure out how to set a breakpoint in sigproc.cc without >>>>>>recompiling make with debug. Any hints? >>>>> >>>>>Just attach to the running process and set a breakpoint. >>>>> >>>>>Alternatively, use the "dll" command to load cygwin1.dll and then set >>>>>a breakpoint on a *line number*. >>>> >>>>Thanks, the latter helped verify that debugging made the problem go away >>>>- ditto strace. Initially I thought it was a race. Racing certainly >>>>helps trigger it but that isn't the problem. >>>> >>>>I can't see a mechanism involving cygthread::stub to cater for the case >>>>where "last man out"+1 ensures "last man out" is running. In all >>>>situations where abnormal behaviour occurs we're left waiting upon a >>>>process that consists of a single suspended cygthread::stub thread. >>>>Others should be able to verify this by bumping up the size of the >>>>cygthread.cc threads[] array up to a silly value then attempt an >>>>intensive configure/make/install with it. Conversely now that I've set >>>>threads[1] there's been no breakages. >>> >>>Where are you seeing this wait? Details please. >> >>Any reasonably intensive configure/make/install build. Not surprising >>'cos that's what I do most. Name almost any process that occurs during >>that and its had a hang on a lone suspended thread - all the parent >>processes waiting on it. Spurious. > >The "where" meant where in the code. > >You apparently tracked things down to the cygthread code but I don't >see any real analysis of why the cygthread code would cause this. The >fact that you twiddled something and the problem went away does not >necessarily mean that you've found the source of the problem -- not >in any complex system at least. I stared at it until I went boss-eyed *then* I twiddled it. >I suspect that this is actualy due to a deadlock in the code init.cc >which was recently discussed in cygwin-developers. > >>The implication is that cygthread::stub's should be in suspended state >>as the process exits. Is this (a) correct, (b) expected, (c) required? > >a, b. > >>Anyone know, or heard of, issues reguarding suspended threads and >>::ExitProcess()? > >Deadlocks with thread or process attach/detach code are documented in >MSDN. > >>Possibles that come to mind - winAPI bug whereby a suspended thread can >>be momentarily woken (ie enough to become the main thread), or perhaps a >>suspended thread can linger due to a handle being left open on it and >>therby become the main thread. > >I don't think it has anything to do with suspended threads. You can >certainly verify this by adding code to kill the threads specifically, >though, and see what happens. I did. I declared threads[1]. All the work gets shoved onto cygthread::simplestub which neither suspends nor stays resident. >The deadlock would be more likely if there are more threads and with the >new cygthread code there will always be at least six extra threads. Thanks for confirming (a) & (b). I put some checks into _pinfo::exit() immediately prior to ::ExitProcess(). The info didn't mean much without that. Hung process: Name-Pid-Pri-Thd--HndMem-User-Time---Kernel-Time---Elapsed-Time sh---344---4---1---67---1832---0:00:00.020---0:00:00.0800:02:29.935 --VM--WS---WS-PkPriv---Faults-NonP-Page-PageFile --351732183219641476--4923---21-1476 -Tid-PriCswtchState-User-Time---Kernel-Time---Elapsed-Time -548---4-1---Wait:Suspended---0:00:00.000---0:00:00.0000:02:29.825 Relevent log: Quick Key: 90 GetCommandLine() chars [n/3
Re: cvs cygwin1.dll
On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <[EMAIL PROTECTED]> wrote: >On Wed, Sep 18, 2002 at 06:42:50PM +0000, Guy Harrison wrote: >>On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <[EMAIL PROTECTED]> >>wrote: >> >>>On Fri, Sep 13, 2002 at 09:09:37AM +, Guy Harrison wrote: >>>>I can't seem to figure out how to set a breakpoint in sigproc.cc without >>>>recompiling make with debug. Any hints? >>> >>>Just attach to the running process and set a breakpoint. >>> >>>Alternatively, use the "dll" command to load cygwin1.dll and then set >>>a breakpoint on a *line number*. >> >>Thanks, the latter helped verify that debugging made the problem go away >>- ditto strace. Initially I thought it was a race. Racing certainly >>helps trigger it but that isn't the problem. >> >>I can't see a mechanism involving cygthread::stub to cater for the case >>where "last man out"+1 ensures "last man out" is running. In all >>situations where abnormal behaviour occurs we're left waiting upon a >>process that consists of a single suspended cygthread::stub thread. >>Others should be able to verify this by bumping up the size of the >>cygthread.cc threads[] array up to a silly value then attempt an >>intensive configure/make/install with it. Conversely now that I've set >>threads[1] there's been no breakages. > >Where are you seeing this wait? Details please. Any reasonably intensive configure/make/install build. Not surprising 'cos that's what I do most. Name almost any process that occurs during that and its had a hang on a lone suspended thread - all the parent processes waiting on it. Spurious. It just will not be debugged. Attaching a debugger after the fact isn't possible. Not limited to gdb: borland builder, borland tdb, W32dsm87 (some disassembler I didn't know I had) and VC6 all refuse to attach to the hung process. Faced with this I compiled 'ash' and 'make' then followed the top level 'make'. Doesn't break. The act of debugging "fixes" the problem. I tried strace again: liberated the 0x2000 STRACE flag and implemented a user_printf() such that I could insert things at choice places in order to drastically reduce output. No joy. After all, debuggers have to stop/start threads but it was worth a whirl. Since then I've been dumping data direct to a file via the WinAPI. Doing this does have some minor side-effects on behaviour, depending where and how much stuff I write, but at least it still hangs. The file tends to end up huge. Too much to get a grip on. It would help if I could confirm some things... I see ::ExitProcess() in only pinfo.cc - assuming I keep my grubby fingers off the keyboard, is this the only place a process will exit or are there "normal" situations in which ::TerminateProcess() gets called (which ones)? The implication is that cygthread::stub's should be in suspended state as the process exits. Is this (a) correct, (b) expected, (c) required? Anyone know, or heard of, issues reguarding suspended threads and ::ExitProcess()? Possibles that come to mind - winAPI bug whereby a suspended thread can be momentarily woken (ie enough to become the main thread), or perhaps a suspended thread can linger due to a handle being left open on it and therby become the main thread. Similarly, anyone know or heard of, issues reguarding an active main thread yielding to another active thread within ::ExitProcess()? The cygthread::stub (info->func) itself: are any of these allowed to be still running when the process exits? Can Spy++ from VC6 be trusted? I need to ask because VC itself was the only debugger that crashed more often than issue a refusal to attach. Some info here would be good. Spy++ is the only tool I've got which tells me the state of the thread. Links to better tools welcomed! ;-) -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cvs cygwin1.dll
On Fri, 13 Sep 2002 08:58:16 -0400, Christopher Faylor <[EMAIL PROTECTED]>
wrote:
>On Fri, Sep 13, 2002 at 09:09:37AM +0000, Guy Harrison wrote:
>>I can't seem to figure out how to set a breakpoint in sigproc.cc without
>>recompiling make with debug. Any hints?
>
>Just attach to the running process and set a breakpoint.
>
>Alternatively, use the "dll" command to load cygwin1.dll and then set
>a breakpoint on a *line number*.
Thanks, the latter helped verify that debugging made the problem go away
- ditto strace. Initially I thought it was a race. Racing certainly
helps trigger it but that isn't the problem.
I can't see a mechanism involving cygthread::stub to cater for the case
where "last man out"+1 ensures "last man out" is running. In all
situations where abnormal behaviour occurs we're left waiting upon a
process that consists of a single suspended cygthread::stub thread.
Others should be able to verify this by bumping up the size of the
cygthread.cc threads[] array up to a silly value then attempt an
intensive configure/make/install with it. Conversely now that I've set
threads[1] there's been no breakages.
Assuming the above gets fixed, coming back to racing, I saw that often
times the suspended thread never even got started by the time it found
itself in control. Might be worth trying cygthread::runner firing
non-suspended threads then let each stub initially stop itself. It's
tempting to suggest taking advantage of windows' dire scheduling with
something like this ...
cygthread::stub()
{
cur = DropPriorityToMostIdle();
while (!info->func)//"volatile"
;
RestorePriority(cur);
::CreateEvent();
while (1) {
if (!info->func)
::ExitThread(0)
;
info->func();
info->func = 0;
::SetEvent();
cur = DropPriorityToMostIdle();
while (!info->func)
//::Sleep
;
RestorePriority(cur);
}
}
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Problems linking program
On Fri, 19 Apr 2002 15:25:27 -0500, "Matt Minnis" <[EMAIL PROTECTED]> wrote: >Larry, > >I did an nm -C and collected the output to a text file. >I found references to these functions in libc, libg, and libcygwin. >I am not quite sure what to look for now. >Can you explain what I need to be looking for? In the case of functions, big 'T's ;-) Loosely: Definitions. One thereof. Multiple definitions means you have to make an executive decision about which lib was intended, and no definition implies "go download missing package" or "bad config wrong machine". nm -A --defined-only `find /lib -name '*.a'` | grep umoddi3 [snip path]/libgcc.a:_umoddi3.o: b .bss /libgcc.a:_umoddi3.o: d .data /libgcc.a:_umoddi3.o: ? .stab /libgcc.a:_umoddi3.o: ? .stabstr /libgcc.a:_umoddi3.o: t .text /libgcc.a:_umoddi3.o: t ___clz_tab /libgcc.a:_umoddi3.o: t ___gnu_compiled_c /libgcc.a:_umoddi3.o:0100 T ___umoddi3 /libgcc.a:_umoddi3.o: t gcc2_compiled ...implies "-lgcc" is missing from the link line. Now you're certainly on your own because that's automatically done via "specs". [snip] -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: porting problem
On Thu, 21 Mar 2002 17:36:46 -0400, "Gabriel Antonio Arcos Acosta"
<[EMAIL PROTECTED]> wrote:
>I'm trying to port a program that was originally designed on IRIX system
>with Delta/C++ compiler over a SGI Indy box. When I try to compile one of
>the source files this error appear:
>
>$ gcc -w -g -I/usr/X11R6/include Chandler.cc -c -o Chandler.o
>Chandler.cc: In method `void Chandler::GenerarPuntos(Complejo &, char = 0,
>char
>= 1)':
>Chandler.cc:59: initialization of non-const reference type `class Complejo
>&'
>Chandler.cc:59: from rvalue of type `Complejo'
>Lemniscata.h:130: in passing argument 1 of
>`Lemniscata::FuncionCaracteristica(Co
>mplejo &)'
>Chandler.cc:100: initialization of non-const reference type `class Complejo
>&'
>Chandler.cc:100: from rvalue of type `Complejo'
>Lemniscata.h:130: in passing argument 1 of
>`Lemniscata::FuncionCaracteristica(Co
>mplejo &)'
>
>Can someone tell what this error means? I'm using the gcc compiler on Win98
>with cygwin. The source compile well on the Indy box.
Highly unlikely to be either a cygwin or gcc issue. Try DejaNews on
comp.lang.c++ for the reason. Hint:
struct X{
X(/*const*/ string &){}
};
main()
{X x("fred");
return 0;
}
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: input stream crash with gcc 3.1
On Tue, 19 Mar 2002 14:02:34 +0900, "Dylan Cuthbert" <[EMAIL PROTECTED]> wrote: >Hmm.. I noticed some talk on a mailing list somewhere about problems with >locales... could it be to do with input streams trying to look up locale >info and getting null ptrs as a result? > >I'll try compiling libstdc++-v3 with -g and -O0 and see how far I can get - >does gdb 5.1 work ok with gcc 3.1 output? I don't know if this will be useful or not: the problem does not occur with g++ 3.0.3 though (probably down to me building it wrong) I recall having to fiddle with its specs file - some confusion of which version of what to link against iirc. -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ls /cygdrive
On Tue, 26 Feb 2002 11:01:19 -, "Chris January" <[EMAIL PROTECTED]> wrote: >Can someone with Cygwin 1.3.10 DLL please check what output you get if you >type the following: >1. Click Cygwin.bat >2. Type cd /cygdrive >3. Type ls Administrator@SD ~ $ cd /cygdrive Administrator@SD /cygdrive $ ls c d e g h j Administrator@SD /cygdrive $ pwd /cygdrive Administrator@SD /cygdrive $ cd Administrator@SD ~ $ mount J:\cygwin\bin on /usr/bin type system (binmode) J:\cygwin\lib on /usr/lib type system (binmode) J:\cygwin on / type system (binmode) J:\work on /wrk type user (binmode) c: on /cygdrive/c type user (binmode,noumount) d: on /cygdrive/d type user (binmode,noumount) e: on /cygdrive/e type user (binmode,noumount) g: on /cygdrive/g type user (binmode,noumount) h: on /cygdrive/h type user (binmode,noumount) j: on /cygdrive/j type user (binmode,noumount) -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd and fstat
On Fri, 18 Jan 2002 16:12:17 +0100, Corinna Vinschen <[EMAIL PROTECTED]> wrote: >On Fri, Jan 18, 2002 at 01:31:16PM +0100, Pavel Tsekov wrote: >> >> >> Guy Harrison wrote: >> >> >On Thu, 17 Jan 2002 14:49:28 GMT, [EMAIL PROTECTED] (Guy Harrison) >> >wrote: >> > >> > >> >> >> [snip] >> >> >> >Could someone enlighten me about 'allow_ntsec'. How does CygWin turn >> >this on? >> >> >> >> When you add "ntsec" to the environment variable CYGWIN. Check FAQ and >> documentation for more info. Also read the mailing list. > >Especially /usr/doc/Cygwin/cygrunsrv.README > /usr/doc/Cygwin/openssh-3.0.2p1-4.README > >If you'd used ssh-host-config to install ssh, it would have >asked if it shall sshd install as a service and how to set the >environment variable CYGWIN, defaulting to "CYGWIN=binmode ntsec tty". I did. I still don't know the cause but armed with your info and Pavel's I know for sure it wasn't cygwin: I've stepped through the lot, sshd and cygwin1.dll! I trundled across & physically rebooted the server: Problem gone. It seemed to have a "ControlSet001" deficiency (ie no Environment key). -- [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd and fstat
On Thu, 17 Jan 2002 14:49:28 GMT, [EMAIL PROTECTED] (Guy Harrison)
wrote:
I'm pleased to be able to report some progress! I've located where the
key difference lies between sshd running as an NT service and sshd
running in just about any other fashion.
1236int
1237get_file_attribute (int use_ntsec, const char *file,
1238int *attribute, uid_t *uidret, gid_t
*gidret)
1239{
1240 int res;
1241
- 1242 if (use_ntsec && allow_ntsec)
1243{
- 1244 res = get_nt_attribute (file, attribute, uidret,
gidret);
- 1245 if (attribute && (*attribute & S_IFLNK) ==
S_IFLNK)
- 1246*attribute |= S_IRWXU | S_IRWXG | S_IRWXO;
- 1247 return res;
1248}
1249
1250 if (uidret)
1251*uidret = getuid ();
1252 if (gidret)
1253*gidret = getgid ();
1254
In almost all circumstances 'allow_ntsec' is true. No problem - sshd
correctly obtains the permissions on the client's $HOME/.ssh/*keys.
The single circumstance in which 'allow_ntsec' is false, is when sshd is
running *directly* as a service: in other words, as it is designed to.
Could someone enlighten me about 'allow_ntsec'. How does CygWin turn
this on?
TIA
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: sshd and fstat
On Thu, 17 Jan 2002 09:59:44 -0500, Peter Buckley
<[EMAIL PROTECTED]> wrote:
>IIRC, SYSTEM should be the owner of the keys. And it is highly
>recommended that the service be run as SYSTEM. Check out
>http://tech.erdelynet.com for more info on the permissions for the key
>files etc.
Info is much appreciated. The service is running as SYSTEM though, and I
had also run the script from tech.erdelynet.com. For verification is
this correct for /etc... ?
-rw-r--r-- 1 Administ Administ 955 Jan 13 06:43 ssh_config
-rw--- 1 SYSTEM SYSTEM668 Oct 29 21:37 ssh_host_dsa_key
-rw-r--r-- 1 Administ Administ 606 Oct 29 21:37 ssh_host_dsa_key.pub
-rw--- 1 SYSTEM SYSTEM531 Oct 29 21:36 ssh_host_key
-rw-r--r-- 1 Administ Administ 335 Oct 29 21:36 ssh_host_key.pub
-rw--- 1 SYSTEM SYSTEM887 Oct 29 21:36 ssh_host_rsa_key
-rw-r--r-- 1 Administ Administ 226 Oct 29 21:36 ssh_host_rsa_key.pub
-rw-r--r-- 1 Administ None 1.5k Jan 17 14:43 sshd_config
As for the files in the individual /home/.ssh directories, assuming the
script worked ok, they should be owned by the relevent /home owner?
Incidentally I did try changing their ownership to SYSTEM but to no
avail.
>Guy Harrison wrote:
>
>> Hi,
>>
>> Not knowing anything about SSH I didn't realise openssh-3.0.2p1-4 (and
>> former) versions shouldn't have been asking for a password with the
>> correct keys at either end. I assumed I'd got something in a mess. It
>> appears not.
>>
>> In the end I compiled openssh so I could get a bit more information on
>> the failure.
>>
>>
>> int
>> secure_filename(FILE *f, const char *file, struct passwd *pw,
>> char *err, size_t errlen)
>> {
>> uid_t uid = pw->pw_uid;
>> char buf[MAXPATHLEN], homedir[MAXPATHLEN];
>> char *cp;
>> struct stat st;
>> int zzz;
>> if (realpath(file, buf) == NULL) {
>> snprintf(err, errlen, "realpath %s failed: %s", file,
>> strerror(errno));
>> return -1;
>> }
>> if (realpath(pw->pw_dir, homedir) == NULL) {
>> snprintf(err, errlen, "realpath %s failed: %s",
>> pw->pw_dir,
>> strerror(errno));
>> return -1;
>> }
>> log("realpath=[%s][%s]",buf,homedir);
>> /* check the open file to avoid races */
>> zzz = fstat(fileno(f), &st);
>> log("st_uid=[%d] pw_uid=[%d]",st.st_uid,uid);
>> if ((zzz < 0) ||
>> (st.st_uid != 0 && st.st_uid != uid) ||
>> (st.st_mode & 022) != 0) {
>> snprintf(err, errlen, "bad ownership or modes for file
>> %s",
>> buf);
>> return -1;
>> }
>>
>>
>> When run as a service sshd is emitting...
>>
>> The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
>> could not be found. It contains the following insertion string(s):
>> /usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
>> 0x1B0 : debug1: temporarily_use_uid: 500/513 (e=18).
>>
>> The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
>> could not be found. It contains the following insertion string(s):
>> /usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
>> 0x1B0 :
>> realpath=[/home/Administrator/.ssh/authorized_keys][/home/Administrator].
>>
>> The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
>> could not be found. It contains the following insertion string(s):
>> /usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
>> 0x1B0 : st_uid=[18] pw_uid=[500].
>>
>> The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
>> could not be found. It contains the following insertion string(s):
>> /usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
>> 0x1B0 : Authentication refused: bad ownership or modes for file
>> /home/Administrator/.ssh/authorized_keys.
>>
>> Seems to think authorized_keys is owned by SYSTEM:18 but it isn't.
>> Stopping sshd as a service and running from within bash "sshd -d" works
>> fine and emits...
>>
>> debug1: temporarily_use_uid: 500/513 (e=500)
>> debug1: trying public RSA key file
>> /home/Administrator/.ssh/authorized_keys
>> realpath=[/home/Administrator/.ssh/authorized_keys][/home/Administrator]
>> st_uid=[500] pw_uid=[500]
>> debug1: restore_uid
>> Accepted rsa for Administrator from 192.168.0.1 port 2446
>>
>> ...which isn&#x
sshd and fstat
Hi,
Not knowing anything about SSH I didn't realise openssh-3.0.2p1-4 (and
former) versions shouldn't have been asking for a password with the
correct keys at either end. I assumed I'd got something in a mess. It
appears not.
In the end I compiled openssh so I could get a bit more information on
the failure.
int
secure_filename(FILE *f, const char *file, struct passwd *pw,
char *err, size_t errlen)
{
uid_t uid = pw->pw_uid;
char buf[MAXPATHLEN], homedir[MAXPATHLEN];
char *cp;
struct stat st;
int zzz;
if (realpath(file, buf) == NULL) {
snprintf(err, errlen, "realpath %s failed: %s", file,
strerror(errno));
return -1;
}
if (realpath(pw->pw_dir, homedir) == NULL) {
snprintf(err, errlen, "realpath %s failed: %s",
pw->pw_dir,
strerror(errno));
return -1;
}
log("realpath=[%s][%s]",buf,homedir);
/* check the open file to avoid races */
zzz = fstat(fileno(f), &st);
log("st_uid=[%d] pw_uid=[%d]",st.st_uid,uid);
if ((zzz < 0) ||
(st.st_uid != 0 && st.st_uid != uid) ||
(st.st_mode & 022) != 0) {
snprintf(err, errlen, "bad ownership or modes for file
%s",
buf);
return -1;
}
When run as a service sshd is emitting...
The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
could not be found. It contains the following insertion string(s):
/usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
0x1B0 : debug1: temporarily_use_uid: 500/513 (e=18).
The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
could not be found. It contains the following insertion string(s):
/usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
0x1B0 :
realpath=[/home/Administrator/.ssh/authorized_keys][/home/Administrator].
The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
could not be found. It contains the following insertion string(s):
/usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
0x1B0 : st_uid=[18] pw_uid=[500].
The description for Event ID ( 0 ) in Source ( /usr/sbin/sshd.exe )
could not be found. It contains the following insertion string(s):
/usr/sbin/sshd.exe : Win32 Process Id = 0x1B0 : Cygwin Process Id =
0x1B0 : Authentication refused: bad ownership or modes for file
/home/Administrator/.ssh/authorized_keys.
Seems to think authorized_keys is owned by SYSTEM:18 but it isn't.
Stopping sshd as a service and running from within bash "sshd -d" works
fine and emits...
debug1: temporarily_use_uid: 500/513 (e=500)
debug1: trying public RSA key file
/home/Administrator/.ssh/authorized_keys
realpath=[/home/Administrator/.ssh/authorized_keys][/home/Administrator]
st_uid=[500] pw_uid=[500]
debug1: restore_uid
Accepted rsa for Administrator from 192.168.0.1 port 2446
...which isn't the end of it. I fired up a bash shell, launched from a
service with SYSTEM authority expecting a failure...
debug1: temporarily_use_uid: 500/513 (e=18)
debug1: trying public key file /home/Administrator/.ssh/authorized_keys
realpath=[/home/Administrator/.ssh/authorized_keys][/home/Administrator]
st_uid=[500] pw_uid=[500]
...but it worked, both as "sshd -d" and as a straight "sshd" (so it
forked in case that was it).
fstat will only fail when sshd is running as a service as SYSTEM. The
only viable approach I can think of at this point is to attach gdb to
the process forked by sshd and I can't for the life of me figure out how
to do that. I hope this info is useful to you folks with more intimate
knowledge 'cos I'm stuck! :-|
--
[EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
