
BobS
Super Moderator-
Posts
331 -
Joined
-
Last visited
Everything posted by BobS
-
I'm amazed you are having these problems, since they're not normal. First, let's clarify that a fresh, CLEAN install of The Uniform Server Orion 7.1.2 does NOT have a start up screen with a login requirement. That also goes for phpMyAdmin, even if you changed the MySQL root password. IMHO, you MUST have changed something, or combined the new version with some old files. Secondly, phpMyAdmin isn't the right tool for changing my.ini, the MySQL config file. It's designed for managing the DATA and STRUCTURES (although future versions may adjust the configuration). Also, I have had NO problem using notepad to view or change the my.ini file, even though a text editor would be better. Finally, I have no idea what library files you refer to as being in your my.ini, but the default my.ini has NO references to any libraries. Regards, BobS
-
Thanks for the comments. It's always a problem to know just how to uninstall or get rid of interference from other WAMPs. The Uniform Server is self-contained by design, so that deleting the main directory will erase ALL of it. Regards, BobS
-
What would be BEST is if you just used the eAccelerator version ALREADY AVAILABLE in 7-Orion, instead of reinstalling things that already exist. Use the CURRENT version of PHP and don't change anything until you get the baseline running. "If it ain't broke, don't fix it!" Regards, BobS
-
Thanks for the heads-up on this attack format. Just love those 'bots. Seems to point out how difficult it is to REALLY secure your server. So far as putting in IPTABLES, my first take (after doing some homework), is that this is NOT the level where The Uniform Server sits. IPTABLES is at the network-firewall level, and interacts with packets before the get picked up by to Apache. The Uniform Server would need to put something into Apache, IMHO, in order to stay within its logical boundary. It also depends more on the philosophical and practical cut-off point for where the developers of The Uniform Server want to stop and "leave the rest as an exercise for the user." I would suggest that this be developed into pages on the Wiki, with some detailed analysis of what's needed to counteract attacks. Regards, BobS
-
If you're going to reinstall, why not use a CURRENT version of The Uniform Server? I highly suggest you download and install Orion_7_1_2.exe and use that. No eAceelerator problem, the latest security fixes, VC9 libraries, etc., etc. That's far easier than having to deal with out-of-date code and re-debug fixed problems. Regards, BobS
-
I'm not sure I'd be comfortable moving items from Mona forward. Mona used PHP 5.2.x and 5.3.1 but Orion is at 5.3.6. That may or may not be important. Also, Orion series uses VC9 compiler, whereas Mona was VC6. I don't know if that figures in here or not, but better to realize it may have an effect. Regards, BobS
-
Absolutely not! I was trying to de-confuse you, but there seems to be much more work to do. InnoDB is a feature of MySQL; it's the type of engine inside. PHP has access methodologies for many databases, and works just fine with all of MySQL's features. InnoDB is a more advanced engine than MyISAM, and is designed for high transaction volume. It requires a bit more care when tuning, and it has the necessary controls. A possible analogy: MyISAM to InnoDB and 707 to 747 airplanes. Now, DON'T confuse phpMyAdmin with my.ini, which is the configuration file for MySQL. That's why it's in the UniServer\usr\local\mysql directory. phpMyAdmin is a great tool, but it only changes the contents of MySQL, not the configuration parameters. Regards, BobS
-
HOW-TO: XSL Extension Installation for UniServer Nano 5.6.5
BobS replied to page2pagepro's topic in Programming & Web Design
This procedure is valid for all 5-Nano series servers. Note that 6-Carbo and 7-Orion series already include the proper version of php_xsl.dll and you do NOT need to download anything for these servers. The Test files listed above are still available as of this date. Regards, BobS -
First off, tuning a server is quite complex, and requires setting a lot of different aspects that are, quite frankly, beyond our scope here. The default number of "workers" is 250. You can see more by using Apache Status (see Apanel). It invokes this: http://localhost/server-status Most of the tuning parameters are NOT specified in US, because they need to be set for a specific situation. It's also important to note that your slowness may come from the requests to MySQL, since it's using the same machine. Regards, BobS
-
Remember, innodb is a MySQL feature, and not one of phpMyAdmin: UniServer\usr\local\mysql\data\mi.ini
-
Actually, that's not quite right. My first point was that for learning purposes, running as a program was simpler, since there are less interconnected configuration problems. Running as a service is just as easily done, but you MAY have other problems to contend with. I cited the name difference as one of them. There really isn't a "fix" to running as a service. Just choose to RIGHT-click on the tray icon. I suggest you take a look at this Wiki article: http://wiki.uniformserver.com/index.php/5....Install_and_Run This has pictures and detailed information about starting as a service. Regards, BobS
-
Will not run in Windows Server 2008 R2 Datacenter
BobS replied to oktam's topic in Uniform Server - Windows
Thanks for the info. My thought is the shellexecute error comes from the administrator rights not being passed to the editor. Or maybe the permissions on the directories, although that seems unlikely. Just some paths to check.... Regards, BobS -
Heinz, Actually, phpMyAdmin has all those features, but probably not in the same places. The menus and structure of the UI are just different. I find it easy to use now, but when I started, it was Greek (or maybe geek). NOTE: Inno.db can be made available by a change in the my.ini file. Look for: # Note: The innodb block is enabled/disabled using a single line # Uncomment the next line to disable innodb tables. Comment line to enable innodb tables skip-innodb If you create multiple databases, all the data is mixed together in the innodb tables. So under mysql\data, you'll have dbA and dbB folders (for example), but the inno tables will all be in the innodb files. This makes life a bit harder to separate off applications. As a consequence, the US developers decided to stick to myISAM instead. While that may be confusing now, after gaining some experience, it will become clearer. Regards, BobS
-
Heinz, Like Megan, I'm still confused as to why you want to use MySQL Workbench with The Uniform Server. It's never mentioned in The Uniform Server docs. Perhaps because it's usually available with MySQL? But phpMyAdmin is also usually available as well. In any case, the easiest installation of US is to the root of a drive. The extraction creates the UniServer folder for you, which makes life quite simple. This avoids the problems of paths with spaces in the name. Secondly, as you now know, the Start.exe program shows as the tray icon, and this has two action screens depending on whether you right- or left-click. By right-clicking, you show the install-as-service menu, which is announced by the graphic UService on the left. However, I suggest you NOT use this to start. As a beginner, you're much better off doing a left-click and using the UStandard menu, running the servers as programs. Another reason for doing this is that for various good reasons, UniServer changes the names of the server programs, so that mysqld is NOT the name of the running process. This will definitely confuse MySQL Workbench (and you), even though there's an easy way of resolving this, as well. The third problem you ran into concerns the search order MySQL uses to find the "correct" my.ini file. It is too easy to get confused with this (personal experience speaking). The BEST spot (IMHO) is in the mysql directory. This allows for running multiple copies of MySQL, while any other location creates tremendous problems. While the Wiki may not be the most organized (as of now; I'm starting major revisions), it has a wealth of information for beginners. Regards, BobS
-
UniServer Orion 7.1.0 to 7.1.2 - How to Upgrade?
BobS replied to stream's topic in Uniform Server - Windows
Quick answer: No Sorry, one of the problems with auto-update is that there are many customizations that cannot be anticipated. On the other hand, you know best what you have done to your installation. I suppose there could be a procedure created to do the update, but I don't think anyone has tried to design this feature yet. I use TreeComp to compare two directories and merge the files as required, but it's NOT a push button affair. Regards, BobS -
I assume you're specifically referring to using ffserver, which is a multimedia streaming server for live broadcasts? BobS
-
The problem is that your old database is not transferable just by copying. You need to create an SQL extract on the old site using phpMyAdmin and then import that to your new site using phpMyAdmin. This is a fairly detailed task, but is not difficult. Remember that you can do it over with different coding parameters if you don't like the results. Regards, BobS
-
1. Run PHP/MySQL/Apache on Windows startup. See the alternative_control directory for Start_Server.bat and place it in the Startup folder (for XP), or make a Run entry for it in the registry (HKCU\Software\Microsoft\Windows\Current Version\Run). 2. Do not show "Press key to continue..." - just automatically close console window after server started. Use a refresh command. See home\admin\www\redirect.html for an example. 3. Open Google Chrome browser (which could not be default browser) at system startup and redirect immediately to my application instead opening APanel. This is more complex. Go to PortableApps.com and download Chrome. Check out some of the Wiki pages concerning PAC and following: http://wiki.uniformserver.com/index.php/Virtual_Hosting:_PAC These will at least lead you in the right direction. 4. Do not show UniServer splash screen before redirect at startup. One way is to change the redirect.html page. In any case, you'll need to do some research and testing. I suggest you consult the Wiki a lot. Regards, BobS
-
The latest version of UnServer, Orion-7.1.0, resolves several causes of this problem, which is likely due to IPv6 localhost address. Instead of only 127.0.0.1 it also allows for ::1, the IPv6 localhost address. Regards, BobS
-
Host file for Orion 7.0.3 on Win 7 - Error 403
BobS replied to peteradie's topic in Uniform Server - Windows
Please note that you can include multiple addresses and address ranges on a single "Allow from" line. Allow from 127.0.0.1 ::1 works just fine. Also, for your local LAN, you can add 192.168 to cover any of the addresses in typical home DHCP ranges. Allow from 127.0.0.1 ::1 192.168 You'll want to edit \UniServer\user\local\apache2\conf\httpd.conf to enable the Apache status and info commands. These are lines 980 and 991. Just modify them as above. Regards, BobS -
Host file for Orion 7.0.3 on Win 7 - Error 403
BobS replied to peteradie's topic in Uniform Server - Windows
Note that instead of $unisecure this should read $us_secure. This needs to be updated in English.php. In reality you should NOT get this warning when using localhost. The code in secure.php needs to be updated so that both IPv4 AND IPv6 entries are accepted. Specifically, line 15 should be: if ( !($us_ip == "127.0.0.1" | $us_ip == "::1" )) { Regards, BobS -
Host file for Orion 7.0.3 on Win 7 - Error 403
BobS replied to peteradie's topic in Uniform Server - Windows
So let's go back to the start. What changed? According to the Change Log, the version of Apache was updated to 2.2.18 r2. This is pretty significant, since it's the emitter of HTTP 403. In addition, there were two small changes in the httpd.conf file, and both relate to what is returned to the caller: apache2\conf\http.conf: --------- # The following lines prevent .htaccess and .htpasswd files from being # viewed by Web clients. Order allow,deny Deny from all Satisfy All --------- # ServerTokens # This directive configures what you return as the Server HTTP response # Header. The default is 'Full' which sends information about the OS-Type # and compiled in modules. # Set to one of: Full | OS | Minor | Minimal | Major | Prod # where Full conveys the most information, and Prod the least. ServerTokens Prod (vs Full in 7.0.2) --------- There's nothing specific that tells us exactly what triggered the 403 error, but I have typically seen this in relation to the .htaccess file, so let's check that change out. Look at this reference in the Apache documentation: http://httpd.apache.org/docs/2.2/mod/core.html#satisfy So when the "Satisfy All" was added, it required the IP address to match the "Allow from 127.0.0.1" in the .htaccess files. I'll bet this is the change that "created" your 403 error. You can validate this by temporarily commenting out the "Satisfy All" But why do we get an IP mismatch? The other thing I'd like to know is what your Windows 7 is returning when you ping localhost. I'll bet that it is an IPv6 loopback, and that's what generates the IP mismatch, since we're expecting only IPv4 loopback for this. Just a few suggestions; you'll have to prove them out, since I could be wrong! Please post your results! Regards, BobS -
Elaborating on that affirmative... I suggest that you look at the Wiki information for installing WordPress (http://wiki.uniformserver.com/index.php/Installing_WordPress_on_5.0-Nano). While it references version 5-Nano, it will also work with 7-Orion series. I also suggest you use the WordPress plugin to start with, since it will get you going quickly. You'll still want an Internet connection periodically in order to use WordPress' auto-update to get the latest versions of the core, themes and plugins. This system gives you a private workbench for developing your site contents. Then you can copy the new content from the edit window of a given post to the target site (basically a cut-and-paste), or use a database export/import to transfer the site content. This latter method requires knowledge about the database contents, and some tweaks to merge it into a running site. I have used this method for about 3 years, so I can vouch for it being "the way to go." It also acts as a proven backup of all the contents. Regards, BobS
-
I think you may be out of luck on this one. This is most likely a 32-bit limit problem, and I'd be surprised if the ActivePerl Win32 version would allow addresses past the 2^31 limit. But I may be wrong.... In any case, there may be other parts with 32-bit limits as well that keep things from running as you wish. The real question is why you need to have all 2 Go in memory at once. Is there a way you can break up the data into smaller blocks? Regards, BobS
-
Yes, it is possible. You can have as many as 9 different instances. The simplest way to effect this is through the UniTray icon. Click on the icon, select Advanced > Move Servers multi-server operation. This will open a command window, which will prompt you to acknowledge the changes to the ports and other items required. Do a test of this so you understand what changes are made. You'll see that the number on the icon will change as well. Note that each time you do the Move Servers, everything increments by one; running it four times, for example, will move the servers to the fourth port set. You will need to create multiple separate copies of UniServer, and I suggest you do them as UniServer1, Uniserver2, etc. Then run each instance of the UniTray (Start.com) beginning with the highest numbered first. Execute Move Servers as required for that number. You can look at http://wiki.uniformserver.com/index.php/5....:_Multi-Servers for more info, and although it's a bit dated, it still is valid through 7-Orion. Regards, BobS