Re: [PATCH] Don't set sticky bit on /var/log
On Aug 27 20:35, Corinna Vinschen wrote: On Aug 27 19:11, Jon TURNEY wrote: For the purposes of discussion, attached is a patch which changes the mode which setup gives /var/log from 1777 to 0777. See this thread [1] for why I think I want to do this. I haven't thought at all about the security implications of this change at all. I have observed that /var/log has mode 0755 on a couple of linux systems I've looked at. It looks like the setting of mode 1777 was added by Corrina on s/rrin/rinn/ 2008-08-20, I'm guessing as part of the Cygwin 1.7 changes. [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00090.html The problem is in fact one of security. If the directory has 0777 permissions, everyone can remove log files from everyone else. That's hardly feasible, especially given service logs and stuff. May I suggest to follow the basic route you outlined in the aforementioned mail? Create a subdir /var/log/XWin with 0777 permissions and use that to create the XWin logs. is there some way to set this as global setting right from the package installation? Here's another idea. What about making the default logfile name user-specific, as in /var/log/XWin.$USER.$DISPLAY.log ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] inform user if any postinstall script failed to run
On 27/08/2010 19:33, Christopher Faylor wrote:
On Fri, Aug 27, 2010 at 06:15:38PM +0100, Jon TURNEY wrote:
On 29/07/2010 17:28, Jon TURNEY wrote:
On 28/07/2010 15:58, Christopher Faylor wrote:
On Wed, Jul 28, 2010 at 03:25:17PM +0100, Jon TURNEY wrote:
Anyhow, here's another attempt, which unfortunately changes rather more than I
wanted to. It adds a new page, which is displayed if any script failed, and
reports which packages and scripts failed.
That is great. Please check in (with a ChangeLog of course).
Due to the way I tested this change, I'd failed to notice that when a package
is installed with a failing postinstall script, this will list the failing
script twice, once with the package name and once as 'no package'.
Attached is a patch to remedy that.
Do we realy need a separate for loop for this? Couldn't we just piggy
back on the previous for loop?
Sure. I'm not sure if it's any more elegant, though :-)
Index: postinstall.cc
===
RCS file: /cvs/cygwin-apps/setup/postinstall.cc,v
retrieving revision 2.25
diff -u -r2.25 postinstall.cc
--- postinstall.cc 30 Jul 2010 20:53:42 - 2.25
+++ postinstall.cc 28 Aug 2010 12:25:34 -
@@ -74,7 +74,7 @@
class RunScript
{
public:
- RunScript(const std::string name, const vectorScript scripts) :
_name(name), _scripts(scripts), _cnt(0)
+ RunScript(const std::string name, const vectorScript scripts,
vectorScript *script_list) : _name(name), _scripts(scripts),
_script_list(script_list), _cnt(0)
{
Progress.SetText2 (name.c_str());
Progress.SetBar1 (0, _scripts.size());
@@ -114,11 +114,22 @@
fs \t j-baseName() exit code retval \r\n;
s = s + fs.str();
}
+
+// Remove each script we try to run from the list of scripts
+if (_script_list)
+ {
+std::vectorScript::iterator p = find(_script_list-begin(),
_script_list-end(), *j);
+if (p != _script_list-end())
+ {
+_script_list-erase(p);
+ }
+ }
}
}
private:
std::string _name;
const vectorScript _scripts;
+ vectorScript *_script_list;
int _cnt;
};
@@ -146,6 +157,12 @@
std::string s = ;
+ // Build a list of the scripts in /etc/postinstall
+ std::string postinst = cygpath (/etc/postinstall);
+ vectorScript script_list;
+ RunFindVisitor myVisitor (script_list);
+ Find (postinst).accept (myVisitor);
+
// For each package we installed, we noted anything installed into
/etc/postinstall.
// run those scripts now
int numpkg = packages.size() + 1;
@@ -154,22 +171,16 @@
{
packagemeta pkg = **i;
- RunScript scriptRunner(pkg.name, pkg.installed.scripts());
+ RunScript scriptRunner(pkg.name, pkg.installed.scripts(), script_list);
scriptRunner.run_all(s);
++k;
Progress.SetBar2 (k, numpkg);
}
- // Look for any scripts in /etc/postinstall which haven't been renamed .done,
- // and try to run them...
- std::string postinst = cygpath (/etc/postinstall);
- vectorScript scripts;
- RunFindVisitor myVisitor (scripts);
- Find (postinst).accept (myVisitor);
-
+ // Run any scripts left in the list, which haven't been claimed by any
package
{
-RunScript scriptRunner(No package, scripts);
+RunScript scriptRunner(No package, script_list, NULL);
scriptRunner.run_all(s);
}
Index: script.h
===
RCS file: /cvs/cygwin-apps/setup/script.h,v
retrieving revision 2.13
diff -u -r2.13 script.h
--- script.h16 Apr 2006 15:37:49 - 2.13
+++ script.h28 Aug 2010 12:25:34 -
@@ -35,6 +35,7 @@
or command.com (9x). Returns the exit status of the process, or
negative error if any. */
int run() const;
+ bool operator == (const Script s) { return s.scriptName == scriptName; } ;
private:
std::string scriptName;
static char const ETCPostinstall[];
Re: [PATCH] inform user if any postinstall script failed to run
On Sat, Aug 28, 2010 at 01:30:54PM +0100, Jon TURNEY wrote: On 27/08/2010 19:33, Christopher Faylor wrote: On Fri, Aug 27, 2010 at 06:15:38PM +0100, Jon TURNEY wrote: On 29/07/2010 17:28, Jon TURNEY wrote: On 28/07/2010 15:58, Christopher Faylor wrote: On Wed, Jul 28, 2010 at 03:25:17PM +0100, Jon TURNEY wrote: Anyhow, here's another attempt, which unfortunately changes rather more than I wanted to. It adds a new page, which is displayed if any script failed, and reports which packages and scripts failed. That is great. Please check in (with a ChangeLog of course). Due to the way I tested this change, I'd failed to notice that when a package is installed with a failing postinstall script, this will list the failing script twice, once with the package name and once as 'no package'. Attached is a patch to remedy that. Do we realy need a separate for loop for this? Couldn't we just piggy back on the previous for loop? Sure. I'm not sure if it's any more elegant, though :-) Yow. No, it isn't. I didn't think you'd need to modify RunScript to deal with the behavior. So, nevermind. The previous solution looks simpler. Please go ahead with that one. cgf
Re: 1.7.6: Install error said postinstall error
On 25/08/2010 10:24, Lucas wrote: When I was installing Cygwin downloaded using the newest setup.exe yesterday, lots of error happend and the install GUI said postinstall error. This doesn't seem to be an X problem, so should have been sent to the main cygwin list. Packages: No Package boxes.sh: exit code : 2 http://sourceware.org/ml/cygwin/2010-08/msg00199.html Add the missing : to /etc/postinstall/boxes.sh and all should be well. libglade2.0.sh: exit code : 2 http://cygwin.com/ml/cygwin-xfree/2010-08/msg00120.html fontconfig.sh: exit code : 14 Not sure what's causing this one. Can you post the output from trying to run /etc/postinstall/fontconfig.sh and/or /var/log/setup.log.full ? I have searched the maillist and found many people asked about this error but the error code are not like mine, so I turn for help here, thinking that maybe somebody here knows about it. Besides, the error report mails seem to not have got any solution so for, so is this a bug of the bash scripts in the new version? I have attached the setup.log. THANKS a lot, everybody! -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/utils ChangeLog cygcheck.cc cygpath ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-28 11:22:37 Modified files: winsup/utils : ChangeLog cygcheck.cc cygpath.cc ldh.cc locale.cc mkgroup.c mkpasswd.c module_info.cc path.cc ps.cc regtool.cc strace.cc Added files: winsup/utils : loadlib.h Log message: * loadlib.h: New header implementing safe LoadLibrary calls. Include throughout files using LoadLibrary function. * cygcheck.cc (dump_sysinfo): Retrieve kernel32.dll handle via GetModuleHandle, rather than using LoadLibrary. * cygpath.cc (get_long_name): Ditto. (do_sysfolders): Append .dll suffix in LoadLibrary call. * ldh.cc (WinMain): Use LoadLibraryExW with DONT_RESOLVE_DLL_REFERENCES to avoid loading malicious library code. * locale.cc (print_locale_with_codeset): Change way to retrieve kernel32.dll path. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/loadlib.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.539r2=1.540 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/cygcheck.cc.diff?cvsroot=srcr1=1.123r2=1.124 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/cygpath.cc.diff?cvsroot=srcr1=1.62r2=1.63 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ldh.cc.diff?cvsroot=srcr1=1.1r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/locale.cc.diff?cvsroot=srcr1=1.9r2=1.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/mkgroup.c.diff?cvsroot=srcr1=1.47r2=1.48 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/mkpasswd.c.diff?cvsroot=srcr1=1.54r2=1.55 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/module_info.cc.diff?cvsroot=srcr1=1.3r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/path.cc.diff?cvsroot=srcr1=1.28r2=1.29 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ps.cc.diff?cvsroot=srcr1=1.27r2=1.28 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/regtool.cc.diff?cvsroot=srcr1=1.29r2=1.30 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/strace.cc.diff?cvsroot=srcr1=1.56r2=1.57
src/winsup/doc ChangeLog new-features.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-28 11:36:43 Modified files: winsup/doc : ChangeLog new-features.sgml Log message: * new-features.sgml (ov-new1.7.7): Document change to avoid DLL hijacking. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.313r2=1.314 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.53r2=1.54
src/winsup/utils ChangeLog ldh.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-28 12:12:54 Modified files: winsup/utils : ChangeLog ldh.cc Log message: * ldh.cc (WinMain): Change DONT_RESOLVE_DLL_REFERENCES to LOAD_WITH_ALTERED_SEARCH_PATH. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.540r2=1.541 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ldh.cc.diff?cvsroot=srcr1=1.2r2=1.3
Re: Windows batch program to open shell at directory
Thanks for all your great suggestions. Here is what I settled on for the batch file: c:\cygwin\bin\zsh --login -c cd '%1' ;exec zsh The only thing I have to work out is how to handle cases where the %1 argument contains spaces. Thanks again! -- 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: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
2010/8/27 Charles Wilson: On 8/27/2010 2:33 PM, Andy Koppe wrote: On 27 August 2010 19:22, neomjp wrote: 2. I understand that the reason to have tcltk-20080420-1 as a win32 app is to have a graphical insight that does not depend on X Window. Cygwin programs can have Win32 interfaces actually, as proven by the likes of rxvt, mintty, and the Xwin server itself. The real issue is that tcltk-20080420-1 presents the GDI (e.g. native windows) backend implementation for tcl/tk. I was proposing that we eventually modify our offerings so that the new (probably split up) replacement package(s) present the X11 backend implementation instead. It has nothing to do with whether tcltk is a win32 *application* as opposed to a cygwin one. It's all about which interface the application/library uses to put graphics on the screen: GDI or X11. So far, nothing has occurred on that line AFAIK. If it is to happen, the current maintainer has to just pull the trigger and say we are going to do this. Existing maintainers of tcl/tk clients will then adapt; until (if) that happens, nothing will change. I think the big hangups were (a) insight (b) git (c) python-idle. insight might actually be dead or dying, not sure. Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. A big nuisance in my eyes. Why do I have to start a xserver, when I can use native fast small GDI? The PIPE problem appears elsewhere also, and will be fixed with 1.7.7. -- Reini -- 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: command-line package installation
2010/8/28 Bryan: Is there any chance that the roadmap for cygwin has a commandline package manager, or to expand the capabilities of setup.exe in the future? I think I can find and delete what I need to until then, but a package manager type thing would be great... other than find and delete, are there any other ways to do what I'm needing? Roadmap is nice :) You can help out with my http://code.google.com/p/cygwin-rurban/source/browse/trunk/contrib/cyginstall/cyginstall -- Reini -- 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: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 8/28/2010 10:31 AM, Reini Urban wrote: 2010/8/27 Charles Wilson: Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. A big nuisance in my eyes. Why do I have to start a xserver, when I can use native fast small GDI? Why do you have to start cygserver (for posix IPC), when you can use native fast small named pipes, or native fast small shared memory? Either tcl/tk is actually ported to cygwin, or it isn't. When compiled as it currently is, internally tcl/tk is a hybrid monster: this is actually a bug in tcl/tk. It conflates the concept of display technology with runtime support. So, when you compile for GDI you also get I like C:/foo paths and other native-win32-ness -- BUT it isn't actually a native win32 app/lib, because it ALSO uses the cygwin runtime. It just uses it wrong. But, it was always just a stop-gap, quick-n-dirty port. It worked -- enough that GDB/insight DTRT, at least. When it is used by other clients, technically -- AFAIK -- it isn't actually supported. But there are sharp edges in this unhappy marriage of GDI, native win32 calls, and the cygwin runtme. So, the right answer is a real port of tcl/tk. There are two ways to do this: 1) just compile it like you would on unix. Then, you get X11, not GDI -- but you also avoid all the other win32isms. This will just work; recompile with the correct options and you're golden. 2) disentagle all the assumptions in the tcl/tk code between windowing system and win32ness as it relates to non-windowing code. This is a BIG job, and NOBODY wants to do it. okay, so: 3) or...status quo with a mostly working, two year old pseudo port, with some sharp edges... During a previous discussion, the list consensus was that X11 /would/ have been fine, BUT at the time we didn't actually have a maintained Xserver since the previous maintainer left, and our current maintainers had not yet stepped forward. Now, though, our X server is well maintained and works very well...so that reason no longer applies. The only /technical/ barrier now is that in some security-locked-down environments, non-Admin's cannot grant permission to applications to open a networking port. Since on cygwin, even unix domain sockets are emulated using networking ports, AND because the Xserver /will not work/ without that unix socket being opened...you can't run an Xserver in those environments, which means you wouldn't be able to run insight, gitk, etc etc. Then there's the pain involved in coordinating the switch with other maintainers of tcltk clients, and the existing higher-priority demands on cgf's time, ... and it just hasn't bubbled to the top. The PIPE problem appears elsewhere also, and will be fixed with 1.7.7. Well, I wasn't pre-cognitively suggesting, last year, that we switch from GDI to X11 to fix this PIPE problem... -- Chuck -- 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: command-line package installation
On Sat, Aug 28, 2010 at 09:43, Reini Urban rur...@x-ray.at wrote: 2010/8/28 Bryan: Is there any chance that the roadmap for cygwin has a commandline package manager, or to expand the capabilities of setup.exe in the future? I think I can find and delete what I need to until then, but a package manager type thing would be great... other than find and delete, are there any other ways to do what I'm needing? Roadmap is nice :) You can help out with my http://code.google.com/p/cygwin-rurban/source/browse/trunk/contrib/cyginstall/cyginstall -- Reini I will give this a try... many thanks Reini. I didn't have an issue with apt-cyg until I tried to run gcc commands. It appeared that there was some permission issues running postinstall scripts, and it seemed to affect the creation of $PATH directories... I just need something solid, and will Just Work. Thanks again... Bryan -- 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: command-line package installation
On Sat, Aug 28, 2010 at 10:51:19AM -0500, Bryan wrote: On Sat, Aug 28, 2010 at 09:43, Reini Urban wrote: 2010/8/28 Bryan: Is there any chance that the roadmap for cygwin has a commandline package manager, or to expand the capabilities of setup.exe in the future? ??I think I can find and delete what I need to until then, but a package manager type thing would be great... other than find and delete, are there any other ways to do what I'm needing? Roadmap is nice :) You can help out with my ??http://code.google.com/p/cygwin-rurban/source/browse/trunk/contrib/cyginstall/cyginstall I will give this a try... many thanks Reini. I didn't have an issue with apt-cyg until I tried to run gcc commands. It appeared that there was some permission issues running postinstall scripts, and it seemed to affect the creation of $PATH directories... I just need something solid, and will Just Work. You could also, of course, consider modifying setup to do what you want and then contributing that code back to the community. Then you'd have something which exactly fit your needs and others would also benefit. cgf -- 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: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
Charles Wilson schrieb: On 8/28/2010 10:31 AM, Reini Urban wrote: 2010/8/27 Charles Wilson: Obviously git and python-idle both work with X (on linux) so it's doable to convert -- just a nuisance. A big nuisance in my eyes. Why do I have to start a xserver, when I can use native fast small GDI? Why do you have to start cygserver (for posix IPC), when you can use native fast small named pipes, or native fast small shared memory? Because we don't have posix IPC semantics in native windows. So, the right answer is a real port of tcl/tk. There are two ways to do this: 1) just compile it like you would on unix. Then, you get X11, not GDI -- but you also avoid all the other win32isms. This will just work; recompile with the correct options and you're golden. 2) disentagle all the assumptions in the tcl/tk code between windowing system and win32ness as it relates to non-windowing code. This is a BIG job, and NOBODY wants to do it. I did it for perltk two years ago and posted the patches to the perltk tracker. It was a nobrainer, needed one day and was straightforward. Tk is very well prepared for supporting windows GDI or unix X. But I'm not interested to maintain it. And I'm not interested to have to start startxwin for a simple tk gui. pTk is essentially the same as Tk upstream, just portable, hence the name. Just two lines are problematic, using the unix event loop with /dev/windows should be replaced by using the native windows event loop. pTk/mTk/win/tkWinX.c: GetMessage() via select() on /dev/windows and callback did not work for me. http://rt.cpan.org/Public/Bug/Display.html?id=31792 I have no idea what would be involved to try out the pTk cygwin Win32 wish instead of the original tk wish. If anyone is concerned about our current tcltk path mess should try it. http://search.cpan.org/dist/Tk/ The Tk svn already has my cygwin patches in. But I have more important things to do. -- 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
SSH - Can't Login (3rd Post)
I've posted this 3 times now. I'm wondering if anyone from the Cygwin staff is receiving it. I've been an outstanding member of the mailing list for a very long time. Anyway, here's my issue: I've set up SSH with no problems in the past, yet when I try to log into itself I get the following: # ssh -v ca53...@localhost OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh_config debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/544 debug1: identity file /home/ca53918/.ssh/id_rsa type 1 debug1: identity file /home/ca53918/.ssh/id_rsa-cert type -1 debug1: identity file /home/ca53918/.ssh/id_dsa type 2 debug1: identity file /home/ca53918/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6 debug1: match: OpenSSH_5.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/ca53918/.ssh/id_rsa Connection closed by 127.0.0.1 There's an immediate connection. The sshd service is running, and I've used both the ssh_user_config and ssh_host_config script to set up the environment. All the appropriate files look clean underneath my .ssh directory. Any help will be greatly appreciated. Thanks, and regards, Auteria W. Winzer Jr. -- 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 Sat, Aug 28, 2010 at 4:34 PM, Auteria W. Winzer Jr. wwin...@yahoo.com wrote: I've posted this 3 times now. I'm wondering if anyone from the Cygwin staff is receiving it. I've been an outstanding member of the mailing list for a very long time. Anyway, here's my issue: I've set up SSH with no problems in the past, yet when I try to log into itself I get the following: snip Check the following: ls -la /home/USER/.ssh ls -la /home Does the .ssh folder have permissions 700 and files within 600? Do you have StrictModes yes in your sshd_conf file? If so, then the server will ignore the keys in the .ssh sub-directory if the home directory is writeable by anyone other than the Owner. slide -- 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: WLMP cannot map to parent and Rebaseall fails for unknown reason.
On 8/27/2010 12:11 PM, Oren Elrad wrote: snip PS. I know that WLMP is not Cygwin's problem. I was merely hoping that some kind soul would point me in the right direction to rebasing all my DLLs for a happy cygwin + WLMP family. Have you considered http://cygwin.com/acronyms/#BLODA? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Creating a file within Cygwin with setting SYSTEM attribute
I have access to cpio sources that I would like to add support for copying/creating Cygwin's symbolic links. At present, any files I create would be as regular files. Any hints as how I would set this attribute so I could create these symbolic links. Does setting _IFLNK in the mode automatically perform setting SYSTEM attribute? -- http://genealogy.mcferrin.org/ # McFerrin Family History, Public View -- 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
[ANNOUNCEMENT] Updated: w32api-3.15-1
I've made a new version of the w32api (3.15-1) available for download. A list of what has changed can be found here: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog?rev=1.1055cvsroot=src To update your installation, click on the Install Cygwin now link on thehttp://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at:cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read*all* of the information on unsubscribing that is available starting at this URL. Chris -- 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: Creating a file within Cygwin with setting SYSTEM attribute
On Sat, Aug 28, 2010 at 08:50:46PM -0400, Paul McFerrin wrote: I have access to cpio sources that I would like to add support for copying/creating Cygwin's symbolic links. At present, any files I create would be as regular files. Any hints as how I would set this attribute so I could create these symbolic links. Does setting _IFLNK in the mode automatically perform setting SYSTEM attribute? If Cygwin's cpio didn't create symbolic links then there would be something seriously wrong with it. As it turns out, it *does* work as expected so, if you're not seeing the correct behavior, then you're probably not running using the Cygwin version of cpio. cgf -- 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
