Re: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Charles Wilson]

Corinna Vinschen wrote:

On Apr  9 10:55, Charles Wilson wrote:

Hopefully, that's more acceptable for ssh-user-config?


My bad, I didn't update csih to CVS.  I still think that's too much for
ssh-user-config.  But since we don't need the setfacl anymore, that's
a moot point now.


It may be a moot point for ssh-user-config, but it could be a useful 
behavior for some other -user-config (maybe cron user customizations?). 
 So, I've gone ahead and made the behavior silent if the 
associated/specified server is already installed. See below.



And that was really very nice.  I'm not trying to critizise the general
approach.  I just think we (that is: I) should get rid of the entire
message and the setfacl in ssh-user-config.


Well, that will certainly simplify things. However, operating on the old 
assumption, the new (not even in CVS yet) version of csih lets you do this:


compute_sshd_user() {
  if csih_is_nt
  then
if ! cygrunsrv -Q sshd >/dev/null 2>&1
then
  csih_select_privileged_username -q sshd
fi
sshd_user=$(csih_service_should_run_as sshd)
if ! setfacl -m "u::rwx,u:${sshd_user}:r--,g::---,o::---" \
 "${pwdhome}/.ssh"
then
  csih_error_multiline \

}

(a) if your service is installed, then you go directly to 
csih_service_should_run_as with the (new, optional) argument 'sshd'


(b) otherwise, behavior is the "quiet but not silent" I described in my 
last email -- and that all arises from calling 
csih_select_privileged_username -q sshd -- which is why the client 
(ssh-user-config) skips it if possible.



 svc_user=$(regtool get '/HKLM/SYSTEM/CurrentControlSet/Services/$1/ObjectName')
 svc_user="${svc_user/\.\\/$COMPUTERNAME}"
 svc_user=$([ "$svc_user" = "LocalSystem" ] && echo "SYSTEM" || echo $(fgrep 
"${svc_user}" /etc/passwd | cut -d: -f 1))

(a) csih_select_privileged_username (in CVS) already optionally accepts
the service name in addition to the -q option. Currently it is only used
to customize the Info: messages (see ${opt_servicename}, above).  So
this is even easier to add than you imagine -- if it is truly desirable
to do so.

(b) You could also do 'foo=$(cygrunsrv -V -L ${service} | sed -n
'/Account/p' | awk '{print $NF}'); foo=$(basename $foo)' which amounts
to the same thing.


Urgh!  Isn't it embarassing that *I* missed to use cygrunsrv for that?


Well, my version wasn't exactly right either. You need to (and the new, 
not even in CVS yet version does) do this:


username=$(cygrunsrv -V -Q "${opt_servicename}" 2>&1 |\
sed -n -e '/^Account/s/^.* : //p')
username="${username/\.\\/${COMPUTERNAME}\\}"
# and then something like
[ "${username}" = "LocalSystem" ] \
   && username=SYSTEM \
   || username=$(fgrep "${username}" /etc/passwd | cut -d: -f 1)




(c) But what if ${service} has not yet been installed, even though [a]
common service account exists [perhaps used by some other installed
cygwin service]?  Then you'd still need the existing logic...


Right, but that should probably be a fallback.  


Ok, that's the way it works now.  But it is also why the user-config 
client needs to check 'cygrunsrv -Q myservice' and call

  csih_select_privileged_username -q myservice
if the service is not already installed.


If the service exists,
it could run under *any* account.  It might be interesting for csih to
check always for the user running the service, not only on 2k3 and
above.


OK, csih_select_privileged_username only cares for users with the 
special (required on nt2003) perms -- therefore, it still checks 
is_nt20003 || (nt && force_privileged).  However, if the service is 
installed, then 'csih_service_should_run_as myservice' will return the 
user it is installed under, regardless of OS.


(Well, 9x always returns "")

If the service is not installed, then the behavior of 
sih_service_should_run_a is as before:
  nt2003: find pre-existing 'well-known' privileged user and specify 
that, or

  default to cyg_server
  nt && !nt2003 && !force_privileged: default to SYSTEM
  !nt (e.g. 9x): ""

For the ssh-user-config script you won't need it anymore.  I have a 
hard time to see that a normal user should know or decide about stuff
like that. 


Well, with the incantation in compute_sshd_user() above, IF the admin 
has already installed the service, then the user-config script will be 
silent (at least with regards to these issues concerning the service's 
user account.)  It will only print messages (and perhaps ask questions 
the user is ill-equipped to answer) if the user-config script is run but 
the associated server has not been installed.


Of course, if you don't care what sshd_user is, then you don't call 
either of

  csih_select_privileged_username
  csih_service_should_run_as
and it's guaranteed to be quiet. 


Nothing of that is actually helpful or informative for a
"just-a-user" user.  And except for setting permissions (which isn't
necessary!) I really think we should not call this function from pure
user conf

RE: Using windows text mode without setup.exe

[David Dyck]

On Wed, 9 Apr 2008 at 12:43 -0700, [EMAIL PROTECTED] wrote:


 Alternatively, if you don't want to go through your application fixing the
file open calls, you can just link it against textmode.o, which will cause all
your files to be opened in textmode by default.  See also

http://cygwin.com/ml/cygwin/2002-10/msg00152.html


Thanks for mentioning this - shouldn't this be mentioned in

  http://www.cygwin.com/cygwin-ug-net/using-textbinary.html

(along with perhaps some of the issues that are involved)

--
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/

cron and Windows 2000

[Vince LaMonica]

Hi all,

I recently updated cygwin on a Windows 2000 server box and I am now 
getting errors when running cron. It is the famous, "can't switch user 
context" message that I've seen a lot of posts about. The issue is that I 
am not running Windows 2003 server, but rather Windows 2000 server. 
Cygwin has been installed for 'all to run', and the cron jobs are/were 
created by user, "Administrator".


I have attempted to create a "cron_user" user, giving that user special 
permissions ["Act as part of the operating system", "replace a process 
level token", and "Increase quotas"]. After creating the user, I ran 
mkpasswd -l so now /etc/passwd has that user listed. When I attempt to su 
into that account so I can try and run cron-config under that account, I 
get the error, "su: incorrect password, or insufficient privileges to 
change user (see 
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid): Permission 
denied"


I read the section, which is why I made sure that the 3 special 
permissions were granted to that user.


So I am a bit stuck: I need to be able to run cron as ...well, someone! I 
would perfer to run cron as Administrator, since that is the only user 
who logs into the console and the only user with a crontab. Is there 
something obvious I am missing?


Thank for any info y'all can provide,

/vjl/

--
Vince J. LaMonica   Knowledge is knowing a street is one way.
[EMAIL PROTECTED]  <*>  Wisdom is still looking in both directions.

   Donate today, please: http://www.cancer.org/

--
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: Using windows text mode without setup.exe

[Corinna Vinschen]

On Apr  9 20:43, Dave Korn wrote:
> David Dyck wrote on 09 April 2008 20:37:
> 
> > On Wed, 9 Apr 2008 at 11:51 -0700, [EMAIL PROTECTED] wrote:
> > 
> >>   The application needs read from and write to files in
> >> text mode (i.e. using CRLF format).  This works fine on my development
> >> machine, because I can just use the Cygwin setup program to specify
> >> the Windows text mode as default.  However, when I package up my
> >> distribution with the Cygwin dll and install it elsewhere, the program
> >> writes UNIX linefeeds.
> > 
> > http://www.cygwin.com/cygwin-ug-net/using-textbinary.html
> > 
> >  In the open() function call, binary mode can be specified with the
> >  flag O_BINARY and text mode with O_TEXT. 
> 
>   Alternatively, if you don't want to go through your application fixing the
> file open calls, you can just link it against textmode.o, which will cause all
> your files to be opened in textmode by default.  See also
> 
> http://cygwin.com/ml/cygwin/2002-10/msg00152.html

Alternatively, consider *NOT* to ship the Cygwin DLL with your
application, and if you do, please test if a normal Cygwin release is
already installed on the machine and use it if it exists instead of
installing your own Cygwin DLL.  Otherwise your users will have trouble
no end.  Also, keep in mind that this mailing list will not support your
users which have trouble with multiple Cygwin DLL installations.  It's
not supported.  If possible, don't do it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Using windows text mode without setup.exe

[Christopher Faylor]

On Wed, Apr 09, 2008 at 02:51:36PM -0400, [EMAIL PROTECTED] wrote:
>I am developing an application that links with the Cygwin dll (i.e.  I
>don't want people to have to have a Cygwin install on their computers).
>The application needs read from and write to files in text mode (i.e.
>using CRLF format).  This works fine on my development machine, because
>I can just use the Cygwin setup program to specify the Windows text
>mode as default.  However, when I package up my distribution with the
>Cygwin dll and install it elsewhere, the program writes UNIX linefeeds.
>
>Please, is there some way to specify that Windows text mode should be
>used without going through the Cygwin setup program?  Should it be done
>automatically and I'm just missing something?
>
>As per the reporting guidelines, I am attaching the output from
>cygcheck -s -v -r.

Other people have answered the technical aspects of your question but I
wanted to remind you that if you are supplying a cygwin DLL you still
have to abide by the GPL.  That means that you need to make the source
code for both your program *and* the cygwin DLL available under the
terms mentioned at http://cygwin.com/licensing.html.

cgf

--
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: Using windows text mode without setup.exe

[Dave Korn]

David Dyck wrote on 09 April 2008 20:37:

> On Wed, 9 Apr 2008 at 11:51 -0700, [EMAIL PROTECTED] wrote:
> 
>>   The application needs read from and write to files in
>> text mode (i.e. using CRLF format).  This works fine on my development
>> machine, because I can just use the Cygwin setup program to specify
>> the Windows text mode as default.  However, when I package up my
>> distribution with the Cygwin dll and install it elsewhere, the program
>> writes UNIX linefeeds.
> 
> http://www.cygwin.com/cygwin-ug-net/using-textbinary.html
> 
>  In the open() function call, binary mode can be specified with the
>  flag O_BINARY and text mode with O_TEXT. 

  Alternatively, if you don't want to go through your application fixing the
file open calls, you can just link it against textmode.o, which will cause all
your files to be opened in textmode by default.  See also

http://cygwin.com/ml/cygwin/2002-10/msg00152.html

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Using windows text mode without setup.exe

[David Dyck]

On Wed, 9 Apr 2008 at 11:51 -0700, [EMAIL PROTECTED] wrote:


  The application needs read from and write to files in
text mode (i.e. using CRLF format).  This works fine on my development
machine, because I can just use the Cygwin setup program to specify
the Windows text mode as default.  However, when I package up my
distribution with the Cygwin dll and install it elsewhere, the program
writes UNIX linefeeds.


http://www.cygwin.com/cygwin-ug-net/using-textbinary.html

In the open() function call, binary mode can be specified with the flag
O_BINARY and text mode with O_TEXT. These symbols are defined in fcntl.h.

In the fopen() function call, binary mode can be specified by adding
a b to the mode string. Text mode is specified by adding a t to the
mode string.

The mode of a file can be changed by the call setmode(fd,mode) where fd
is a file descriptor (an integer) and mode is O_BINARY or O_TEXT. The
function returns O_BINARY or O_TEXT depending on the mode before the call,
and EOF on error.

--
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/

Using windows text mode without setup.exe

[mjumbe]

Hello,

I am developing an application that links with the Cygwin dll (i.e. I  
don't want people to have to have a Cygwin install on their  
computers).  The application needs read from and write to files in  
text mode (i.e. using CRLF format).  This works fine on my development  
machine, because I can just use the Cygwin setup program to specify  
the Windows text mode as default.  However, when I package up my  
distribution with the Cygwin dll and install it elsewhere, the program  
writes UNIX linefeeds.


Please, is there some way to specify that Windows text mode should be  
used without going through the Cygwin setup program?  Should it be  
done automatically and I'm just missing something?


As per the reporting guidelines, I am attaching the output from  
cygcheck -s -v -r.


Thank you for your time,
- Mjumbe Poe


cygcheck.out
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: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Mark J. Reed]

On Wed, Apr 9, 2008 at 12:38 PM, Matt Wozniski <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 12:20 PM, Mark J. Reed wrote:
>  > Sorry for interrupting, but what is csih?
>
>  First sentence of the first post of the thread:

...which I don't seem to have received, for some reason.  The first
message I have is from Corrina, obviously a reply to Charles, but I
don't have Charles' message.  Odd.

Thanks for the quote.

-- 
Mark J. Reed <[EMAIL PROTECTED]>

--
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: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Matt Wozniski]

On Wed, Apr 9, 2008 at 12:20 PM, Mark J. Reed wrote:
> Sorry for interrupting, but what is csih?

First sentence of the first post of the thread:

csih (cygwin-service-installation-helper) provides a library of shell
functions that can be used by other cygwin packages that provide
servers and daemons. It can assist in various service installation
tasks, such as:
[snip]

--
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: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Mark J. Reed]

Sorry for interrupting, but what is csih?

--
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: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Corinna Vinschen]

On Apr  9 10:55, Charles Wilson wrote:
> On Wed, 9 Apr 2008 14:09:56 +0200, Corinna Vinschen wrote:
> >Looks ok, but I have a few questions/comments.
> >
> >- When the script starts, the following text appears:
> [snip verbose output]
> >However, I think the whole message is too noisy and confusing for
> >non-admins.  
> 
> That is odd. That particular text was mostly taken from ssh-host-config,
> and should only appear if your script calls
> csih_select_privileged_username() with no arguments (or if you are using
> csih-0.1.3, instead of CVS csih) -- that is, the way ssh-host-config
> calls it.  The older version of csih_select_privileged_username ignores
> its arguments; the newer one honors the '-q' option that [my]
> ssh-user-config gives it. In which case, what you should see is
> something like the following (but only if nt2003 or
> csih_FORCE_PRIVILEGED_USER):
> 
> *** Info: The following privileged accounts were found: 
> *** Info: This script will assume that ${opt_servicename} will run under
> the"
> *** Info: '${username}' account."
> *** Query: Will ${opt_servicename} run under a different account?" 
> [yes/no], if yes, then:
> *** Query: Enter the user name used by ${opt_servicename}:
> 
> Hopefully, that's more acceptable for ssh-user-config?

My bad, I didn't update csih to CVS.  I still think that's too much for
ssh-user-config.  But since we don't need the setfacl anymore, that's
a moot point now.

> >Additionally, given that Cygwin opens
> >files always with BACKUP_INTENT for a while anyway, and given that the
> >service account is a member of the administrators group, which has
> >backup user rights, there's not much reason anymore to add the service
> >account to the ACL.  I fear that's just old cruft in the ssh-user-script.
> 
> Well, that's up to you. I wanted to do something that was as close to
> equivalent as the existing ssh-[host|user]-config, with only those
> changes necessary to support a common service account whose name might
> not be 'sshd_service'.

And that was really very nice.  I'm not trying to critizise the general
approach.  I just think we (that is: I) should get rid of the entire
message and the setfacl in ssh-user-config.

> >The query "Do you want to use different name?" is a bit upside down,
> >IMHO.  The query should be rather phrased positively "Do you want to use 
> >t name?"
> 
> I already addressed this:
> http://cygwin.com/ml/cygwin/2008-03/msg00447.html
> 
> Phrasing that question in the opposite sense breaks postinstall scripts,
> where auto_answer="no". That is:
> 
> Do you want to use this name? 
> Enter the name you want to use: 
> 
> ...and that would be bad. Now, the openssh package does not invoke its
> config scripts from /etc/postinstall, but others do. So I need to take
> care that the auto_answer="no" case never hangs.

Ok, agreed.

> >  svc_user=$(regtool get 
> > '/HKLM/SYSTEM/CurrentControlSet/Services/$1/ObjectName')
> >  svc_user="${svc_user/\.\\/$COMPUTERNAME}"
> >  svc_user=$([ "$svc_user" = "LocalSystem" ] && echo "SYSTEM" || echo 
> > $(fgrep "${svc_user}" /etc/passwd | cut -d: -f 1))
> 
> (a) csih_select_privileged_username (in CVS) already optionally accepts
> the service name in addition to the -q option. Currently it is only used
> to customize the Info: messages (see ${opt_servicename}, above).  So
> this is even easier to add than you imagine -- if it is truly desirable
> to do so.
> 
> (b) You could also do 'foo=$(cygrunsrv -V -L ${service} | sed -n
> '/Account/p' | awk '{print $NF}'); foo=$(basename $foo)' which amounts
> to the same thing.

Urgh!  Isn't it embarassing that *I* missed to use cygrunsrv for that?

> (c) But what if ${service} has not yet been installed, even though [a]
> common service account exists [perhaps used by some other installed
> cygwin service]?  Then you'd still need the existing logic...

Right, but that should probably be a fallback.  If the service exists,
it could run under *any* account.  It might be interesting for csih to
check always for the user running the service, not only on 2k3 and
above.

> Furthermore, remember that these routines are shared between (the more
> common) install-a-service config scripts, and (less common) user config
> scripts like ssh-user-config.  In the former [common] case, assuming
> ${service} is not installed, you will always need the existing logic.

For the ssh-user-config script you won't need it anymore.  I have a 
hard time to see that a normal user should know or decide about stuff
like that.  Nothing of that is actually helpful or informative for a
"just-a-user" user.  And except for setting permissions (which isn't
necessary!) I really think we should not call this function from pure
user config scripts.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://

Re: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Charles Wilson]

On Wed, 9 Apr 2008 14:09:56 +0200, Corinna Vinschen wrote:
>Looks ok, but I have a few questions/comments.
>
>- When the script starts, the following text appears:
[snip verbose output]
>However, I think the whole message is too noisy and confusing for
>non-admins.  

That is odd. That particular text was mostly taken from ssh-host-config,
and should only appear if your script calls
csih_select_privileged_username() with no arguments (or if you are using
csih-0.1.3, instead of CVS csih) -- that is, the way ssh-host-config
calls it.  The older version of csih_select_privileged_username ignores
its arguments; the newer one honors the '-q' option that [my]
ssh-user-config gives it. In which case, what you should see is
something like the following (but only if nt2003 or
csih_FORCE_PRIVILEGED_USER):

*** Info: The following privileged accounts were found: 
*** Info: This script will assume that ${opt_servicename} will run under
the"
*** Info: '${username}' account."
*** Query: Will ${opt_servicename} run under a different account?" 
[yes/no], if yes, then:
*** Query: Enter the user name used by ${opt_servicename}:

Hopefully, that's more acceptable for ssh-user-config?

>The default user doesn't actually know which user name the
>sshd service is running under.

Well, maybe. But what if ssh-host-config hasn't yet been run? see below.

>Additionally, given that Cygwin opens
>files always with BACKUP_INTENT for a while anyway, and given that the
>service account is a member of the administrators group, which has
>backup user rights, there's not much reason anymore to add the service
>account to the ACL.  I fear that's just old cruft in the ssh-user-script.

Well, that's up to you. I wanted to do something that was as close to
equivalent as the existing ssh-[host|user]-config, with only those
changes necessary to support a common service account whose name might
not be 'sshd_service'.

Now, as to:

>The query "Do you want to use different name?" is a bit upside down,
>IMHO.  The query should be rather phrased positively "Do you want to use 
>t name?"

I already addressed this:
http://cygwin.com/ml/cygwin/2008-03/msg00447.html

Phrasing that question in the opposite sense breaks postinstall scripts,
where auto_answer="no". That is:

Do you want to use this name? 
Enter the name you want to use: 

...and that would be bad. Now, the openssh package does not invoke its
config scripts from /etc/postinstall, but others do. So I need to take
care that the auto_answer="no" case never hangs.

>But, here's a question:  Shouldn't the csih_privileged_accounts() function
>check the service itself, rather than testing possible names with `net
>user'?  It would be as simple as giving csih_privileged_accounts the
>service name as $1 argument, and then extract the user name with something
>along the lines of
>
>  svc_user=$(regtool get 
> '/HKLM/SYSTEM/CurrentControlSet/Services/$1/ObjectName')
>  svc_user="${svc_user/\.\\/$COMPUTERNAME}"
>  svc_user=$([ "$svc_user" = "LocalSystem" ] && echo "SYSTEM" || echo $(fgrep 
> "${svc_user}" /etc/passwd | cut -d: -f 1))

(a) csih_select_privileged_username (in CVS) already optionally accepts
the service name in addition to the -q option. Currently it is only used
to customize the Info: messages (see ${opt_servicename}, above).  So
this is even easier to add than you imagine -- if it is truly desirable
to do so.

(b) You could also do 'foo=$(cygrunsrv -V -L ${service} | sed -n
'/Account/p' | awk '{print $NF}'); foo=$(basename $foo)' which amounts
to the same thing.

(c) But what if ${service} has not yet been installed, even though [a]
common service account exists [perhaps used by some other installed
cygwin service]?  Then you'd still need the existing logic...

Furthermore, remember that these routines are shared between (the more
common) install-a-service config scripts, and (less common) user config
scripts like ssh-user-config.  In the former [common] case, assuming
${service} is not installed, you will always need the existing logic.

If csih_select_privileged_username() short-circuits the existing logic
when ${service} is already installed, then you can never change the user
under which  ${service} runs, without first de-registering ${service}. 
Maybe that's a good thing, but right now (and in the exising
ssh-host-config) I *think* you can run it "again" and choose a different
user, and cygrunsrv will happily modify the existing registered
${service}.  I didn't think it was my place to make that behavior
change.

But as I said, maybe it's a GOOD thing to disallow that, without
explicitly deregistering ${service} first.

--
Chuck

--
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: A FAQ regarding defrag and permissions of nonadmin files?

[Christopher Faylor]

On Tue, Apr 08, 2008 at 08:30:27PM -0700, Andrew DeFaria wrote:
> Dave Korn wrote:
>>> Actually HTML is text. It's surely not binary! Every character in an HTML 
>>> file is printable, for example.
>> That's very interesting, but surely a bit off-topic - I thought this 
>> mailing list was meant to be all about defragmentation software, not 
>> text-vs-binary file formats?
> Hmmm... somebody, other than me, decided to bring up the topic...
>> Or in other words, could this thread please be TITTTL'd?
> I don't subscribe to the "talk list". Now what?

Your subscription status is really off-topic for this list.  If you need
to discuss it further then, uh,...  Gee, I guess you're out of luck.

cgf

--
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/

File not found

[EnergizeMe]

I have installed and configured nfs. I have mounted a directory to /sfu/test
and put a few files in that directory. I also setup my /etc/exports file to
look like this:

/test rw

I can mount the drive on my XP client machine and open the directory but
when I typle ls I get the following error:

Volume in drive U has no label.
Directory of U:\

File not found.

If I try to create a new file on that directory, I get the following erorr
message:

Unable to create the file 'New File' 
The media is write protected.

Does anyone know what I am doing wrong? I can get to the location with no
problems, but I am unable to see or create any files. Please help!
-- 
View this message in context: 
http://www.nabble.com/File-not-found-tp16585780p16585780.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
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/

[ANNOUNCEMENT] Updated: git-1.5.5-1

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A new release of git, 1.5.5-1, has been uploaded, replacing 1.5.4-1 as
the current version.

NEWS:
=
This is a new upstream release.  See also the package documentation in
/usr/share/doc/git-1.5.5/, along with the attached upstream release notes.

When compiled out of the box, the upstream git maintainers cater to older
cygwin releases, and intentionally disable certain features that have been
reported on their mailing list, even though they work with the latest
cygwin.  Therefore, this build turns those features back on.  However, it
means that this version does assume that you are not using FAT or FAT32 to
hold your repositories, since they do not store file permissions very
accurately.

DESCRIPTION:

Git is popular version control system designed to handle very large
projects with speed and efficiency; it is used mainly for various open
source projects, most notably the Linux kernel.

Git falls in the category of distributed source code management tools,
similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary
world). Every Git working directory is a full-fledged repository with full
revision tracking capabilities, not dependent on network access or a
central server.

UPDATE:
===
To update your installation, click on the "Install Cygwin now" link on the
http://cygwin.com/ web page.  This downloads setup.exe to your system.
Save it and run setup, answer the questions and pick up 'git' from
the 'Devel' category.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake
volunteer cygwin git maintainer

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:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf8skkACgkQ84KuGfSFAYB/RgCdG41rVZDXcg+OHO+Vyyap47+j
QPEAn0PU42GkLSLgQF2sHE1j4IEhnmXC
=Yinw
-END PGP SIGNATURE-
GIT v1.5.5 Release Notes


Updates since v1.5.4


(subsystems)

 * Comes with git-gui 0.10.1

(portability)

 * We shouldn't ask for BSD group ownership semantics by setting g+s bit
   on directories on older BSD systems that refuses chmod() by non root
   users.  BSD semantics is the default there anyway.

 * Bunch of portability improvement patches coming from an effort to port
   to Solaris has been applied.

(performance)

 * On platforms with suboptimal qsort(3) implementation, there
   is an option to use more reasonable substitute we ship with
   our software.

 * New configuration variable "pack.packsizelimit" can be used
   in place of command line option --max-pack-size.

 * "git fetch" over the native git protocol used to make a
   connection to find out the set of current remote refs and
   another to actually download the pack data.  We now use only
   one connection for these tasks.

 * "git commit" does not run lstat(2) more than necessary
   anymore.

(usability, bells and whistles)

 * Bash completion script (in contrib) are aware of more commands and
   options.

 * You can be warned when core.autocrlf conversion is applied in
   such a way that results in an irreversible conversion.

 * A catch-all "color.ui" configuration variable can be used to
   enable coloring of all color-capable commands, instead of
   individual ones such as "color.status" and "color.branch".

 * The commands refused to take absolute pathnames where they
   require pathnames relative to the work tree or the current
   subdirectory.  They now can take absolute pathnames in such a
   case as long as the pathnames do not refer outside of the
   work tree.  E.g. "git add $(pwd)/foo" now works.

 * Error messages used to be sent to stderr, only to get hidden,
   when $PAGER was in use.  They now are sent to stdout along
   with the command output to be shown in the $PAGER.

 * A pattern "foo/" in .gitignore file now matches a directory
   "foo".  Pattern "foo" also matches as before.

 * bash completion's prompt helper function can talk about
   operation in-progress (e.g. merge, rebase, etc.).

 * Configuration variables "url..insteadof = " can be
   

Re: [ANNOUNCEMENT] Updated: csih-0.1.3-1

[Corinna Vinschen]

On Apr  8 10:12, Corinna Vinschen wrote:
> On Apr  8 01:21, Charles Wilson wrote:
> > Well, I'm waiting for answers to the questions here:
> >   http://cygwin.com/ml/cygwin/2008-04/msg00211.html
> > from Corinna and Yaakov, but in the meantime:
> >
> > Here's a version of ssh-user-config that works with CVS csih (what will 
> > become 0.1.4 very soon).
> 
> Cool, thanks!  
> 
> I'll have a look,
> Corinna

Looks ok, but I have a few questions/comments.

- When the script starts, the following text appears:

*** Info: You appear to be running Windows 2003 Server or later.  On 2003 and
*** Info: later systems, it's not possible to use the LocalSystem account
*** Info: for services that can change the user id without an explicit password
*** Info: (such as passwordless logins [e.g. public key authentication] via 
sshd).

*** Info: If you want to enable that functionality, it's required to create a 
new
*** Info: account with special privileges (unless a similar account already 
exists).
*** Info: This account is then used to run these special servers.

*** Info: Note that creating a new user requires that the current account have
*** Info: Administrator privileges itself.

*** Info: The following privileged accounts were found: 'cyg_server' .

*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will not be able to log on interactively, but will only
*** Info: be used by registered services.
*** Query: Do you want to use different name? (yes/no) no

The query "Do you want to use different name?" is a bit upside down,
IMHO.  The query should be rather phrased positively "Do you want to use 
t name?"

However, I think the whole message is too noisy and confusing for
non-admins.  The default user doesn't actually know which user name the
sshd service is running under.  Additionally, given that Cygwin opens
files always with BACKUP_INTENT for a while anyway, and given that the
service account is a member of the administrators group, which has
backup user rights, there's not much reason anymore to add the service
account to the ACL.  I fear that's just old cruft in the ssh-user-script.

But, here's a question:  Shouldn't the csih_privileged_accounts() function
check the service itself, rather than testing possible names with `net
user'?  It would be as simple as giving csih_privileged_accounts the
service name as $1 argument, and then extract the user name with something
along the lines of

  svc_user=$(regtool get 
'/HKLM/SYSTEM/CurrentControlSet/Services/$1/ObjectName')
  svc_user="${svc_user/\.\\/$COMPUTERNAME}"
  svc_user=$([ "$svc_user" = "LocalSystem" ] && echo "SYSTEM" || echo $(fgrep 
"${svc_user}" /etc/passwd | cut -d: -f 1))


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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/

Intrfacing USB-serial port

[Ahsan Qamar]

Hi

I am trying to interface a Pan tilt camera which comunicates serially. however 
I had to use a USB-serial adaptor because of not having a built in serial port.

According to my knowledge from Cygwin mailing list, USB-Serial COM2 should be 
accessed as /dev/ttyS1. I tried

1. echo test> /dev/ttyS1 and cat /dev/ttyS1 but it doesnt work (cat has to be 
interrupted)
2. echo test> /dev/ttyUSB1 and cat /dev/ttyUSB1 which works
3. I am not able to configure /dev/ttyUSB1 for baud rate etc

I use a library which communicates with the camera serially, and the library is 
giving me error of not being able to open the port in the following function 
either way

if(cam1->Open(1,"/dev/ttyUSB1") != 1) or
if(cam1->Open(1,"/dev/ttyS1") != 1)

How should I access the USB-Serial COM2 since I suspect the problem lies in 
port settings or configuration. Is it because of port number or port 
permissions?
---
Ahsan Qamar


_
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline

--
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: [ITA] xfig/xfig-lib: An interactive drawing tool

[Angelo Graziosi]

Dr. Volker Zell ha scritto:
I would like to adopt and maintain the 'xfig/xfig-lib' packages 
from Harold Hunt.


The procedure of installing 3.2.4-7 removes the previous 3.2.4-6, so the 
link


app-defaults -> /etc/X11/app-defaults

in /usr/X11R6/lib/X11/ is lost and the new postinstall script (xfig.sh) 
does not re-create it.


This causes a lot of problems because, currently, Cygwin-X has

XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults

(see startxwin.sh and startxwin.bat).

I understood your reasons that in the future the new XR7 will change the 
tree, but until that time it would be recommended to stay in the current 
scheme.



Cheers,
   Angelo.

--
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/

Cygwin/ssmtp-2.61-1/ssmtp-config fails to create /etc/ssmtp/ssmtp.conf

[Dmitry Semyonov]

Hello Chuck,

The script expects /etc/ssmtp folder to be created during package installation,
but current ssmtp package does not create it. Therefore, either
ssmtp-config or package installation script should be fixed to create
/etc/ssmtp folder.

$ cygcheck -c ssmtp
Cygwin Package Information
Package  VersionStatus
ssmtp2.61-1 OK

-- 
...Bye..Dmitry.

--
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: Many changed md5sum's between timestamps 1207665039 and 1207706406

[Brian Dessent]

Fergus Daly wrote:

> There seem to have been many changed md5sum's recently (timestamps above) 
> under _obsolete/ but also under GNOME/, automake/, jpeg/, pkgconfig/.
> The replacement *.bz2 files are identical (of size 46 with md5sum 
> c616cffee0f344c37fd4e045a7a87054).
> All ok?

Those were all dummy packages containing bzipped 0-byte files that were
replaced with bzipped empty tar files so as to avoid a setup.exe warning
about unknown tar format.  See
.

It shouldn't be an issue in the future due to
 and due to
the fact that the tar format checking stuff isn't in the released
version of setup.exe.

Brian

--
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/