BobS

HAH! I got a "maybe" clue from this post: http://stackoverflow.com/questions/1555145...r-email-library This fix was related to the CHARSET specified. Instead of UTF-8, try iso-8859-1. Check out the link for additional info. Regards, BobS

Wow. this is waaay beyond my knowledge base. I have NO experience with programming for SSL transactions. I don't know the extent of Ric's knowledge in this area, either. Since you're working with Google's app, you might be able to tap them for some help (maybe) Hey, it's worth a try. Other possibilities for help are php.net or openssl. I suggest that you map out the transaction as well as you can, perhaps using a packet logger, so that you can be sure just what's being passed. Sorry I can't be more help. Regards, BobS

AHA!!! So the key here is that there are two different steps. First, install Perl. That's taken care of by following the "standard" Perl install. THEN, install AWStats. This includes getting the config set to the proper domain and directories. Very nice. Thanks! Regards, BobS

You're right! That's Uuuuuugly! There's another bug lurking that we need to track down as well. Might be they're related, but maybe not. I think there are problems with picking up the right dlls. I regularly copy around UniServer subdirectories, so I don't think that has much bearing on it. Nevertheless, we'll have to do some more testing and research. Regards, BobS

Thanks for including all the details! It makes it easier to correlate with our own experiences. I, too, have noticed certain situations where Apache failed. As I recall, there was one of the 8-coral rc's that was consistent at crashing on server-info and server-status. Your crash data points to php5ts.dll as the failed module, and I'm wondering if the winsxs is getting dlls confused (it shouldn't), or if{not related} there's a mismatched dll in The Uniform Server package. That would certainly account for strange behavior. More study needed.... Regards, BobS

Then again... There SEEMS to be a BUG in the vhosts setup. Looks like a bad regression when we went to version 8.2.0. A problem we had with the port-setting routines has MAY have crept back in. More checking in progress.... {edited} This isn't related to vhosts. Sorry, red herring. Regards, BobS

Great question! I haven't a clue yet as to why. If it's only phpMyAdmin that gives you the quirky problem, I'd say that something got messed up when the location edits were done during your transfer to the USB stick. It's more likely that you have a config file error. Take a look at lines 569-576 in core_functions_inc.vbs. It calls us_get_apache_port(), which reads the httpd.conf file (lines 218-222) to get the port number. The port number is identified by the "Listen" directive. If you have more than one "Listen" line active in the httpd.conf, this could be the trouble. Regards, BobS

This isn't enough information to solve your situation. When you say "localhost cannot be accessed", it's not clear exactly what IS happening. Do you see The Uniform Server splash screen? I assume you see the Unicontroller panel in order to start the servers. What does the Server Status screen show? If you click View www, what happens? Here are three possible reasons for similar problems: Windows firewall. This should have created a popup and you should have selected "allow access". IPv6 vs IPv4 address. Your "localhost" will resolve to ::1 by default. It's possible that the .htacess file or the httpd.conf has been changed and this address is NOT being allowed. Normally, though, you would get a 403 error. Check the HOSTS file (\Windows\system32\drivers\etc\hosts) for additions or deletions that should NOT be there. The last portion should be: # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost Regards, BobS

Well, yeah, but you're missing out on security updates and a lot more. Don't even THINK of putting Nano open to the Internet! There are too many security holes that need to be filled. Regards, BobS

That's essentially what we have in The Uniform Server documentation! If you have a copy of 8-Coral loaded, go to UniServer/docs/English/apache_free_server_cert.html , or go to http://wiki.uniformserver.com/index.php/Co...ree_server_cert (they're essentially the same). As we engineering-types like to say, RTFM! We also suggest using startssl.com as the supplier. A free certificate will get you past the problem of browser security alerts, but doesn't offer any deep assurance to your users about your site. In other words, don't use this type of certificate for a server that's going to be doing e-commerce or working with the general public. It's fine for your small circle of friends, or for side development and software testing. Regards, BobS

Hot DOG!! I just love it when something works as it was intended! I now have a new instance of WordPress running on https://localhost/wordpress/ See the picture: Clarke's Third Law: "Any sufficiently advanced technology is indistinguishable from magic." There's actually nothing magic about it when it's been explained. Regards, BobS

Okay, SSL has been available in The Uniform Server since 4-Mona, so this applies to all versions. If you look at the directory tree, you'll see that there is a www folder AND an ssl folder. A request for http:/mysite/index.html (on port 80) to Apache is directed to the www folder, and if the file is there, it is used for the reply. Similarly, a request for https:/mysite/index.html (on port 443 )is directed to the ssl folder, and if the file is there, it is used for the reply. Look at this article in the Wiki: http://wiki.uniformserver.com/index.php/Coral:_apache_ssl and the following articles for much more detail. It's what you should have read first. BTW, ALL this information is included in the docs directory distributed with Coral. But who needs/reads the manual? The ONLY difference between these two is that the ssl traffic requires a secure connection on port 443, which is automatically handled by the browser and the server. So you've got me into test mode. Normally I don't set up ssl on my test servers, but to prove this out, I'm going to install a copy of WordPress in ssl instead of www, and see just what results I get. If what I see and say are valid, then the ONLY difference will be that this particular copy of WP will ONLY be available via https:// on port 443. Stay tuned.... Regards, BobS

The key here is httpS. That implies that the page is secured via SSL (or its other name, TLS). I see that we probably should create a Wiki article on this.... Assuming that you have already set up your ssl certificates, either by creating the "fake" self-signed cert or by actually obtaining a cert from a third party. By running the certificate installation procedure, you will have activated the secure vhost (which is actually what it is). This makes it so that http requests are served from www directory and https request are served from the ssl directory. Now all you need to do is put your secure goodies in the ssl directory tree, and the non-secure in the regular www tree. Clear? Simple? Yeah... One potential annoyance is with mixed content pages. If you can keep everything in the ssl tree, you'll avoid this. The hit on processor usage nowadays is nominal (you've retired the old Pentium III host?). Last point: I have "cleaned up" the index.php files for www and ssl for Coral-8.1.1, and they look almost the same internally as well as externally. You might want to download these. They'll be included in the next Coral update, but for a while I'll have them available here. Coral_811a.7z.txt Be sure to delete the .txt before un7zipping. Regards, BobS

Great! I see that this actually works, but OTOH I'd like to see the source of your fix. It may be that there is an "official" fix that does this with a bit more finesse. In the meantime, I'd recommend that users who wish to apply this "quick-fix" for the problem do so. Regards, BobS

The general structure is essentially the same. What has changed are the branches for control (uni_con, alt_diag) and support (home\us_phpMyAdmin, us_pear, etc). The www, user\local and others are still in their same places. Regards, BobS

Yes, I see your point. The reason it was changed was....now what was that reason? Oh well, it was Ric's decision and I didn't see any reason to complain at the time (about 8 months ago). Now I can see what you mean. OTOH, it might be a good time to re-start the discussion on "How to update The Uniform Server," since we do want everyone to be updated with the latest security and bug fixes. I normally lay down a new base server and then port over my apps, rather than try to copy in a new server over an older one. (I think that's clear.) The primary problem I've run into in the past is breaking a working app when PHP or MySQL changes are incompatible with the older system. Regards, BobS

Are these supposed to be new topics for the Wiki? Please note that we aren't working with the 5-Nano series any longer. In addition, exeoutput for php is a specialized product that is out of our range of interest for The Uniform Server. The term "automatically" as you use it is not clear. I suppose you mean, when starting Apache, is there a way to start MySQL at the same time. If you use the current 8-Coral version, that is done with one button. You can also use the alt_diag\run_as_program bat files. Earlier versions require the use of the alternative_control bat files to start both at once. Regards, BobS

I'm not sure I understand your question. Non /www implies that you want to use another directory name for the server root as a development environment. Usually, The Uniform Server IS the development environment, a tool to experiment with the concepts and configuration of a WAMP stack. There's really no magic with the name www, except it's rather entrenched. Other stacks use htdocs. OTOH, you might want to look at setting up a vhost with another directory name. This will do essentially what I think you're asking to do. Regards, BobS

The very first thing that pops into mind is .htaccess restrictions. Just how do you have the server configured? Is the name still "localhost"? Did you set the .htaccess files for full access? Regards, BobS

Did you look in the msmtp LOG file? Did you get a popup telling you it sent a message? Did you set the default to gmail? Note that the account specified in the msmtprc.ini is the FROM account,, and you're sending to ANOTHER email address. Regards, BobS

The key is to look for the mshta process that's probably still running and kill that. I think there are some malingering gotchas with this process, and we need more information about when it doesn't perform properly. Regards, BobS

Ain't new code great? I've seen this as well, but I haven't had time to check into this. I would guess that it's a "feature" of the latest formatting for phpMyAdmin. Now, one thing you might try is to use another skin. (EDIT: This doesn't resolve the problem.) Update: I looked at this for several different DBs, but couldn't see either a fix or a clear pattern of just what is happening. I think it's just faulty coding of the combining code for that column. Which is as far as we go. Our role with The Uniform Server is to put together the pieces so that you can use them easily. If there are bugs in the pieces, we don't have the resources to fix them, but must rely on the respective developers. Regards, BobS

More likely, the version of php5ts.dll you copied in is not compatible with the version in the 8.1.0 package. More study needed.... Regards, BobS

You need to adjust the php basic configuration. Use 40M for both Maximum post size and Maximum upload size. The script time is 300 secs, but you may want to change it to 600, just to be sure. This is true for any version of The Uniform Server. Regards, BobS

Yoni's right. Be sure to read the prompt. It absolutely removes the directory if you tell it to do so! Sort of like "del *.*" Regards, BobS