Twinky

Please see my topic over in the plugins forum:

Using Uniservice.exe to install my ZeroXIII Apache as a service creates a big problem. In httpd.conf, you have this: # Environment variable ${PHP_SELECT} has a value of php52, # php53, php54, php55 or php56. It is used in the following # five define statements to select a PHP version to # load as a module. Define ${PHP_SELECT} <IfDefine php56> Include ${US_ROOTF}/core/apache2/conf/extra_us/php56.conf </IfDefine> <IfDefine php70> Include ${US_ROOTF}/core/apache2/conf/extra_us/php70.conf </IfDefine> <IfDefine php71> Include ${US_ROOTF}/core/apache2/conf/extra_us/php71.conf </IfDefine> <IfDefine php72> Include ${US_ROOTF}/core/apache2/conf/extra_us/php72.conf </IfDefine> <IfDefine php73> Include ${US_ROOTF}/core/apache2/conf/extra_us/php73.conf </IfDefine> <IfDefine php74> Include ${US_ROOTF}/core/apache2/conf/extra_us/php74.conf </IfDefine> Well when installing, that then changes.. ${PHP_SELECT} is replaced with 'None' so you see "Define None" at the top... instead of removing the Define.. (or actually defining a php version). But it gets worse.. because included is php versions 7.2 and 7.3 with these contents in the .conf files respectively - php72.conf: LoadFile ${US_ROOTF}/core/php72/libsasl.dll LoadFile ${US_ROOTF}/core/php72/icudt64.dll LoadFile ${US_ROOTF}/core/php72/icuin64.dll LoadFile ${US_ROOTF}/core/php72/icuio64.dll LoadFile ${US_ROOTF}/core/php72/icuuc64.dll # Load PHP module and add handler LoadModule php7_module "${US_ROOTF}/core/php72/php7apache2_4.dll" AddHandler application/x-httpd-php .php # Configure the path to php.ini PHPIniDir "${US_ROOTF}/core/php72/${PHP_INI_SELECT}" php73.conf LoadFile ${US_ROOTF}/core/php73/libsasl.dll LoadFile ${US_ROOTF}/core/php73/icudt64.dll LoadFile ${US_ROOTF}/core/php73/icuin64.dll LoadFile ${US_ROOTF}/core/php73/icuio64.dll LoadFile ${US_ROOTF}/core/php73/icuuc64.dll # Load PHP module and add handler LoadModule php7_module "${US_ROOTF}/core/php73/php7apache2_4.dll" AddHandler application/x-httpd-php .php # Configure the path to php.ini PHPIniDir "${US_ROOTF}/core/php73/${PHP_INI_SELECT}" Neither of these files are updated at all. None of those ${} variables are changed (Notepad++ confirms this). So you don't preserve the selected version of php from the UniController and then you fail to include the correct php config file. Obviously PHP then doesn't run its magic on any php files. Even in your online manual you state: Clicking Install service button (A) initiates a backup of the following configuration files: ◦ httpd.conf ◦ httpd-autoindex.conf ◦ httpd-dav.conf ◦ httpd-manual.conf ◦ httpd-multilang-errordoc.conf ◦ httpd-sni.conf ◦ httpd-ssl.conf ◦ httpd-userdir.conf ◦ httpd-vhosts.conf ◦ php_production.ini - Selected configuration file ◦ phpxx.conf - Selected PHP version ◦ php-cli.ini But you don't back up the php72 or php73.conf files - because you've completely forgotten to update them in the first place (or use the selected option from the unicontroller). This needs fixing. Although you do have pretty extensive documentation, you fail to mention in it anywhere how you are setting all of these ${tags} such as ${PHP_SELECT} and where they are all located in the files and what files they are used in. As apache.org no longer offers downloads because of websites like this one offering an all in one download, it's tricky to unpick your work when you screw it up and make apache unusable as a service.

No not really, later versions above 5.3 require some stupid runtime to be installed which can't be installed on every computer (eg my windows 7 machine won't install it). Further rotatelogs version 2.4.2 is the last version that you can use that doesn't require it too. Uniformserver is no longer truly portable. If you want a US that is, you need to go back to the v7 Orion range or the early v8 Coral range. Those don't require the stupid runtime dependencies.

I'm using US 7.0.1 Orion with php 5.3.6.. this bug is not fixed at all from 5.3.1 I've noticed php crashes via EAACCELERATOR many times per day and it's always from my phpbb forum. I've commented out eaccelerator in php.ini and restarted apache so that i can carry on without it. It's been too much of a pain lately with apache crashing daily.

It's not a virus, this is the way that uniformserver creators have designed the uniformserver setup. Even inside the archive the apache webserver .exe file is always called httpd_z.exe instead of Apache.exe. This seems to go back to when older versions would allow you to create and run multiple apache instances (for whatever reason I have no idea - virtual hosting has been around for years so this was never going to be a big feature). It just seems odd to rename it.

Can't comment on automating the firewall, I don't think windows allows this easily as you'd have all the trojans etc adding their own firewall rules.. However, apache, mysql and even filezilla can indeed be controlled as services (including installing and uninstalling) via a batch file. On the command line you need to CD into the apache / mysql folders and with apache; "apache -k install" BUT uniformserver often renames apache to httpd_z.exe for reasons unknown that they are unwilling to answer. It will still install if you use "httpd_z.exe -k install" but you will not be able to use the -k restart command - which instructs all oif the listening child threads to reload their configurations from the main configuration files (eg, if you create a new virtual host instead of restarting apache and causing downtime you can just run "apache -k restart" and all the threads will read the config files again - instantly enabling any new virtual hosts you've created while all other activities -user browsing or downloads - to continue without disturbance). Unfortunately though, apache is hardcoded internally to only work with it's official name when using the restart command - so if it's installed as Apache2.2 for example, the restart command will work. If it's installed as ApacheS1 (which is how uniformserver installs it as a service when the exe is called httpd_z.exe) then the restart command will not work - the service must be installed as Apache<version>. This indicates that apache is hard coded with the version number internally and will only work with that. With mysql, installation is all over the place. Some versions allow -install, others have to be one manually via the service controller on the command line - sc.exe Last night I was moving my two US installs from one server to another. The older one I had no problems getting mysql installed and running - it just does it. When I went to install MariaDB, I had hell. Nothing works, --defaults-file was ignored... the only thing that would work for installing it was "sc.exe MariaDB binPath=<path> MariaDB" - note the extra reference to MariaDB which shows in the windows service controller. For whatever reason, that works and somehow it knows where to find the right config file and use it (no idea how). FileZilla FTP server also has a slightly quirky install too - can't remember what but this is what I eventually managed to crack it with (in a batch file but you can run these commands one at a time on the command line): "filezilla server" /install auto sc start "filezilla server" Note that you do need auto on that first line - I couldn't get /install to work without it from memory (been a few years). In the days of Apache 1.3 I did come up with my own WAMP setup similar to uniformserver and I had everything scripted from batch files - it was beautiful - but then apache2 came out and I couldn't be bothered to go through it all again so switched to US. US is great but it does have quirks in its configuration and setup - as mentioned the renaming of apache.exe to httpd_z.exe for no apparent reason which breaks an apache fundamental of being able to reload configurations without downtime. Then there are variables all over the place that make no sense - eg AP_PORT - you won't find it defined anywhere and yet somehow everything knows how to use that variable. As much as I love US, I do think that they've bloated it a bit. A good clean install of apache, mysql and php would be great but you can't download apache from apache.org anymore. What I will say is that from my point of view, you are right to want to control it via the command line. It gives you more flexibility and control than the tray utility program (which to be fair is designed reasonable well feature wise but it is rooted into all the config files in such a way that it's a pain).

What do you think uniformserver actually uses? lol

Removing a windows service can be done by the command line using the service controller tool - sc.exe - for example sc.exe delete <service name> In my case, "sc.exe delete Apache2.2" However US does a quirky thing with the apache name because it allows you to create and run multiple apache servers - I had to deliberately rename mine to 2.2 to install and run it as s service so yours may be different. You can see how it is named via the service controller - services.msc from the start menu run command. Once you have successfully run the delete command, you will not see it disappear from the service controller - even if you hit refresh it will still be there. It's a microsoft bug. Close the service controller and reopen it again - you will see the service has gone. Oddly when you install a service you can just click the refresh button and it shows up - no need to close and reopen it.

Some versions of US are 32bit while the newer ones are 64. If you're using a 32bit install of US then it won't work with the 64bit install of the c++ redistributable - and vice versa. You just need to have the right version installed for your US bit version.

You'll need to download an earlier version of uniformserver then. They are still available on sourceforge. Once you've got that, you can pick n mix the bits you want. For instance in my US setup I have mysql but I also have a newer version of mariadb running on a different port for a database that I couldn't downgrade - I got that by downloading a newer version and copying it out into my older version. You can do that with php, the email servers etc. Nothing about my original uniformserver is the same as it was - I've customised all of it. For what its worth, you're not the only one who prefers the older versions. I still use an old 5.2 installation myself. The reason being is that te newer versions require the c++ distributable and if you're using US portably on another computer, you might not have permissions to install it. The older version of US just runs - no dependencies, no registry dust, no installs nothing - it just works.

Port redirection is only needed for computers accessing apache from the outside world through the network router. The op has asked how to make virtual hosts available from INSIDE the network to other computers on the network internally. With respect, none of you have understood this problem correctly and thus you are providing the wrong answers.

I've been using uniformserver since 7.0.1 Orion (infact that is my preferred version which i still use along with a later version on a different port). For reasons unknown, you always rename apache.exe to something else - such as httpd_z.exe in the latest versions. Why is this? In Orion there was no easy way to create virtual hosts without restarting. By using "apache -k restart" all of apaches child threads will reload their configurations from httpd.conf when they have finished their current task - without apache itself being restarted. In short, you don't need to restart apache each time you create a new vhost. However.. this fails with a renamed apache executable. Also you seem to install it into the service manager with a different name too - i had to uninstall mine and reinstall it as apache2.2 and then the reload option worked a treat. So why do you always rename apache? - I'm not criticising, I love US (xampp is trash) but this I find it odd that you do this.

Should have mentioned thius in my previous reply years ago lol.. An easier way would be to use the domain extension of .lan - No need to recompile anything in lazarus, just use .lan. It indicates it's local on your network and meets the 3 characters. I've been doing it for years.

That will do nothing. When a browser requests a website it needs an ip address to send it to. Once it connects to that IP it then sends a text request of the hostname / website it is requesting. Configuring apache will allow it to accept those requests. It will not tell other browsers where to send their requests in the first place. Read my reply above yours.

Is there a reason why we're having to rely on these VC runtimes now? - We never used to.