I'm facing an odd problem with Trac's authentication. I have it installed in other servers and never had problem to install it, but now I'm trying to install it on a shared linux server where:
don't have access to httpd.conf;
only available scripts are php and python (wsgi);
no dev tools at all (so no chance to use gcc to compile something);
.htaccess is okay.
Well, trac is installed and working in anonymous mode and I can not find a way to make it private. It looks like it only relies on Apache basic authentication but I can not do this without httpd.conf access.
On my other instalations I use <Location> inside httpd.conf, but I can't use this tag inside .htaccess. I know that I can simply put <Location>'s content inside a .htaccess file and put this file in any www subdirectory to protect it. But since this is a wsgi script in another directory outside www I have no place to put that .htaccess.
I'm looking for a way to solve this by:
still using apache auth with any other .htaccess configuration that I've missed;
any other way Trac could be used in privative besides relying on apache;
any other issue/project tracking similar to trac is an option too.
I'm using AccountManagerPlugin on a shared Linux server machine of mine without issues.
Related
I've just reset my Ubuntu 14.04 LAMP server hosted with digital ocean. Could someone tell me the 'proper' way to do server configuration. My goal is to do everything as clean as possible (and hopefully well structured).
I intend on using the server mainly for programming and data analytics, however I do plan on hosting my website in /var/www/html. I also plan on using letsencrypt/certbot to get an easy SSL. With this in mind, these are the main goals I would like to accomplish:
1) Redirect the website to ALWAYS be served through https AND www.
2) Enable HSTS for the entire website.
3) Enable clean url's (remove .php extensions and what not).
Since I would like all of these properties to be used across the entire website, should the configuration be done inside of the /etc/apache2/ folder? Or should it be done inside of .htaccess?
And if it should be done inside of apache2 configuration, which file should I add it to? And finally, how exactly should it be added? (for example vhost 80/443, inside of a mod_something section, etc).
Thank you in advance, I would appreciate and consider any advice about Apache and htaccess!
I'm running apache 2.2.24 on Max OS X 10.9.1. Currently, we have a network drive that we access all of our Git repos on at /Volumes/GitWebsites. I would like to configure Apache to serve our PHP based repos from that directory. So, localhost (or 127.0.0.1)/phpsite1/ or /phpsite2? etc. will serve sites from /Volumes/GitWebsites/phpsite1/ or /phpsite2/ in the browser. My two questions are:
Do I simply modify the server root or do I need to use the mod-alias in the httpd.conf file?
What are the permission setting I need to in order for apache to access /Volumes/GitWebsites ?
I've done configuration changes like this in IIS 7.5 and set up a NodeJS dev environment but still new to make large scale changes to Apache. Thanks for any help given.
If you are happy with serving the contents of /Volumes/GitWebsites as it is then it should be fine to point the document root at it. It's also makes it easy to add sites later.
However this could be troublesome later if you want to manage php configuration later on for the sites separately.
(LAMP server configuration)
As a workaround for another problem, I need PHP to be able to access local files, but prevent these files from being served over http by Apache.
Normally, I would just use .htaccess to accomplish this, however due to institutional restrictions, I cannot. I also can't touch php.ini, although I can use php_ini_set within php.
As a creative solution, I thought that if php executes as its own linux user (not as apache) I could use normal chown's and chmod's to accomplish this.
Again, the goal is simply to have a directory of files that apache will not display, but php can access.
I'm open to any suggestions.
Put the files outside of your web accessible root (DocumentRoot), but keep them accessible via PHP.
Suggestion:
/sites
/sites/my.site.com
/sites/my.site.com/data // <-- data goes here
/sites/my.site.com/web // <-- web root is here
Here's a thought. Set the permissions on the files to be inaccessible to even the owner, then when PHP needs them, chmod() then, read them, then chmod() them back to inaccessible.
I have a really irritating problem with PHP on Windows Server 2008 R2. IIS and Apache are running on the same machine (Apache is embedded with another product and it being there is not my choice).
IIS is configured to be able to use multiple versions of PHP, and none of the PHP versions on there were installed with the Windows installer (so php.exe does not exist in the path).
Apache uses one particular version of PHP (5.2.5 Thread-safe - again I can't change this as a 3rd-party application has PHP extensions compiled against this version).
If I check phpinfo() in my Apache site it doesn't have an entry for MySQL, even though php_mysql.dll is enabled in php.ini and it exists in the \ext directory. If I (temporarily) add this version of PHP (same directory, same php.ini) to IIS and set up a test site with phpinfo() it correctly lists MySQL. I know this is not just some strange issue with phpinfo because I have a MySQL-based PHP site running in Apache and it fails with Call to undefined function mysql_connect()
It was suggested that I copy libmysql.dll from the PHP directory to C:\Windows\System32 but this made no difference. As there are multiple versions of PHP on the server I suppose it's possible that the wrong version of libmysql.dll is being loaded, but the PATH doesn't include any directories containing libmysql.dll.
IIS and Apache are looking at exactly the same PHP installation, php.ini, and ext directory, but only IIS can load the MySQL extension. Apache is on the default System account as it looks like System has access to all the DLLs.
The Apache logs say nothing about any DLLs failing to load. I'm logging PHP errors in the event log but nothing is reported about those extensions.
After Googling around the issue I found other suddenly-occurring issues in PHP on Windows server but the usual resolutions - rebuilding php.ini, restarting IIS, restarting the server - haven't helped.
Any suggestions on where to look next are much appreciated!
I know this might not ultimately answer your question but, did you try configuring Apache to execute PHP through FastCGI (mod_fcgid) and use the same binary as IIS does ?
I know you are using mod_php, but calling it via FastCGI will abstract PHP from the webserver process. If extensions are loading fine under PHP called via FastCGI, there is no reason it won't work on a different web server.
Also, I personally beleive that it is a better idea this way since PHP is only called when a *.php file is requested. This way, Apache will not load PHP in memory for every request, which will give you better performance for serving static files, for example.
Update
To do this, you need to download mod_fcgid from http://httpd.apache.org/mod_fcgid/, load the module in your Apache configuration this way,
LoadModule fcgid_module modules/mod_fcgid.so
And then, just specify what binary you want to call when PHP pages are requested:
AddHandler fcgid-script .php
FcgidWrapper "c:/php/php-cgi.exe" .php
Then, files with a .php extension will now be executed by the PHP FastCGI wrapper. Just be sure to specify the same php-cgi.exe binary as IIS is using.
All extensions that were previously available in IIS should now be available in Apache since the PHP installation behind is the same in both environment.
Keep me updated.
1.- check php.ini path in phpinfo.
2.- add php folder to the windows path
http://www.computerhope.com/issues/ch000549.htm
3.- add directive PHPINIDir to apache conf
http://php.net/manual/en/install.windows.apache2.php
4.- uncomment mysql extension in respective php.ini
5.- reload apache
6.- check mysql extension in phpinfo
and please don't copy any files to system32
You will generally need different library dlls for the different versions of PHP you are running. It's best to keep these in their own directories.
There's a few different things that could cause a module not to load, including the PHP version whether you're running a thread-safe or not-thread-safe version and also if the binaries were compiled as VC6 or VC9 †. Usually the easiest way to debug if you're getting any module loading errors is running php.exe from the command line as it will spit out any startup errors (also ensure these are enabled in your php.ini and you're loading the correct php.ini file when you do so).
† IIRC VC6/VC9 is to do with which version of Visual Studio PHP was compiled with.
Ultimately this issue came down to a missing PATH reference. Although IIS doesn't seem to require PHP or PHP modules to exist in the path it seems that Apache (or perhaps my version of PHP?) does. I am lucky in that I only need to run one version of PHP outside IIS, as I have no idea what would happen if I had multiple Apache instances referencing different versions of PHP and multiple PHP directories in the path - presumably one would always fail.
So far it looks like adding Apache's version of PHP to the path hasn't affected the IIS versions of PHP, but I will swear loudly if it suddenly does.
I have an existing web application which I have been building with an ant script and deploying as a .war file to Tomcat.
I am trying to add Drupal to my current technology stack to provide CMS and general UI-related functionality so that I don't have to write my html pages by hand and rather use templates.
During the installation of Drupal7, some of the instructions suggest that I go to this directory:
/etc/apache2/sites-available
and change the DocumentRoot to
/home/myuser/drupal/drupal7
If I make the docroot a basic directory on the file system, how will this impact how the application will work? In addition to Apache, I also have Tomcat server. My goal is to get them to all play nice together. How is this best accomplished?
If I make the docroot a basic directory on the filesystem
I'm not sure what you mean by this. There's no qualitative difference between /var/www and /home/mysuser/drupal/drupal7. The latter is longer and in the user's home directory, but assuming this user would be administering the service anyway that doesn't matter.
Next, the best way to make Tomcat and Apache get along is probably to run one of them on different subdomains. You could use the same domain, but that'd mean you had to run one of the daemons off a nonstandard port and that looks strange and might run into firewall trouble with some users.