This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Apache how-to for cygwin

On 14 January 2007 21:30, Jay Abel wrote:

I must have googled the wrong terms,

Going to google in the first place was wrong. Cygwin comes with documentation, you only had to look as far as your own hard drive!


Got it thanks. I first looked in /usr/share/doc/apache-1.3.33.README and didn't notice the above until later. Notwithstanding, I couldn't get the service to start as advertised, even after changing the user name in httpd.conf.

I did get the service to start as a regular user, and XP just prompted to ask me if I wanted to allow it to listen on port 80, so I said yes, and problem solved. Now the service just runs as `apache' from the start.

I'll try to get it running as system again tomorrow when I'm fresh, now that I know how it's supposed to work. I'll be sure to delete any old logs / pid files before I try again.

You don't actually say what you did in your experiments to get it running,
but you've probably mangled the perms on important files in the process. (If
a file doesn't exist when you run apache for the first time, it creates that
file. If it's running as an unexpected user, it may end up creating that file
with perms that prevent it from re-accessing the file when you later try
running apache as a different user). Pid and log files are particularly
vulnerable to this problem, so be aware you may need to delete or chown some
of them to get it up and running when you follow the README instructions.

I didn't have to do much once I figured out what was wrong, I just had to ensure that the server ran as a regular user, and that the user (`apache' in this case) had appropriate access to /var/www/, /var/run/, /var/log/apache/, and I moved the default log location in the config file to /var/log/apache/. Then it worked. But it didn't like running as system, or perhaps, windows didn't like it running as system, and/or wouldn't let it switch to a limited user, in this case `apache'. I assume the default procedure has worked for at least one other person, so I suppose it's just something weird with my machine.

BTW, a process needs to run as a user. Trying to run it as a group
("Administrators, Users, or None") doesn't make sense. I don't know if giving
write access to /var/run for users is a good thing either, but it's the way my
installation runs: /var/run has rwx for user and group, the user is my
username and the group is 'Users'.

Of course. The process runs as a user but the user's group membership can also determine what directories the process may access. It obviously wouldn't have made sense to chown /var/run/ to the user `apache', so the only other possibility was to be sure the group access to /var/run/ was a group to which `apache' belongs; /var/run/ used to have the group `Administrators' so apache couldn't write its pid file. I thought that I might be able to create a group to allow access to /var/run/ without granting that right to all users -- I just left a step out in my explanation.

As you suggest, ensuring that /var/run/ is rwx by group, and chowning it to <someone>:Users, and ensuring that apache is a member of Users, that got things working. The reason it took so long for me to figure that out (besides my obvious lack of skill) is because (I suppose) it tried to write its pid file before it had opened the log file and failed before it could say what was wrong (or wrote it somewhere else and I just missed it).

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]