We now actually have an even better workaround for the IP address problem I talked about last time. Near the top of any PHP page, include the following line:
After that, the normal IP address variable $_SERVER[‘REMOTE_ADDR’] will hold the actual IP instead of one of the four load-balancer addresses. $_SERVER[‘HTTP_WOU_REAL_IP’] will continue to hold the real IP as well, but you should use the normal variable whenever possible.
By the way, the patch is already included in the WOU standard template, so if you are using those topinclude and bottominclude files, you only need to include the above code if you need the IP address before you call topinclude. Since it uses require_once(), there will be no conflict when the topinclude calls the patch again.
In PHP, the standard way to get the user’s IP address is from the $_SERVER[‘REMOTE_ADDR’] variable. Unfortunately, that doesn’t work on our main webserver. That’s because that server is really several servers sitting behind a special server called a load-balancer. When anyone goes to wou.edu, they are really going to the load-balancer, which hands off the request to one of the actual webservers. This is a fairly common setup in the web world, because it means the whole website will no longer go down if a single webserver fails.
Unfortunately, there’s a drawback. Because of some peculiarities of our network setup, when the load-balancer passes a request to one of our webservers, that server sees the load-balancer’s IP address instead of the actual user’s. If you code in PHP on our server, you may have noticed that $_SERVER[‘REMOTE_ADDR’] always has one of four specific IP addresses. (Though you might expect only one from my oversimplified description just now.)
Luckily, we now have a workaround. Dave McEvilly figured out how to have the load-balancer include the user’s actual IP in a new, custom variable when it hands the request to whichever actual webserver it chooses. So the normal ‘REMOTE ADDR’ variable still has one of those same four addresses, but you can use $_SERVER[‘HTTP_WOU_REAL_IP’] to get the IP of the user who made the actual request.
I know this was a pretty technical post, but as always you can contact me with questions at email@example.com.
It’s already added to the standard template, so after you have called the topinclude file, you can
When we upgraded to WP 3.8 right around the new year, I noticed that it promised to automatically apply security updates. Sure enough, we now have 3.8.1 without any of us having to lift a finger. It’s always nice when something works like that.
If any of you still have WordPress sites on our server that are not part of the main install at wou.edu/wp, please be certain that they are upgraded to the latest version! Un-maintained WP sites are a serious security hazard, and unfortunately we’re going to need to be a little tighter about separate WP installations. If you have a site like this and want to move it to the central installation, we can help you with that; just contact me at firstname.lastname@example.org. Also, if you know of one of these separate WP sites that isn’t needed anymore, let me know and I’ll remove it for you safely.
Yeah, whenever anybody says that, they actually mean they *are* going to brag about something, I know. I think I just did something kinda cool, though. See, one of the departments has a few pages of their website on a third-party webhost, due to a long and complicated story that I’m not going to get into because this is already going to be a long explanation.
This hosting company is flexible enough that Danielle could make our template work over there, but there really wasn’t any way to include the departmental navigation files from our site. They’d just have to edit both the local copy for their pages on our servers, and the hardcoded version on every page on the other web host. Making it worse was the fact that the webhost only allows a certain number of edits before they start charging every time a file is changed (which still boggles my mind.)
Ordinarily we could just use curl() or the like to fetch the file from our server, but this company doesn’t use PHP. They still run ColdFusion, of all things. If ColdFusion has a way to fetch and include offsite files, I don’t know it. But I figured out a way to use jQuery and JSONP to have the pages on the other host talk to our webserver and get the sidebar include file they need. They just need to source a JS script from our site, and it reads variables from the page to know which navigation files to include. I could’ve hard-coded it for this one department, but I hate doing that when I can make a tool that can be used again.
If you want more detail, email me. That’s all for now.
Recently we moved the WOU forums server to a better machine, but then we noticed that Internet Explorer was no longer accepting the server’s SSL certificate, so it couldn’t make a secure connection. Firefox, on the other hand, was perfectly fine with the cert and established a perfectly valid SSL connection.
Those of you who are all up on modern web security practices probably recognize this problem already, but I didn’t have the relevant information and was completely boggled.
When I looked at our certificate vendor’s support site for the third or fourth time, I found a certificate installation checker. It was right there on the support homepage all along, but I guess you tend to miss things if you’re only focusing in on your latest guess rather than keeping the main problem in your mind.
Anyway, this checker lets you enter a hostname and port and it will tell you if the cert on that connection is valid, and if not, what’s wrong with it. That told me that the forums server was missing two intermediate CA certs. I didn’t understand what was up with that, but it gave me the certs to install, so I shrugged and dropped them into the webserver’s cert DB and voila– IE quit complaining and reported a valid secure connection.
I still didn’t understand what was going on and why that solution worked, so I did a bit of digging around.
Apparently in recent years, certification authorities have moved from signing customer certs directly with a root certificate, to signing them with an intermediate certificate which is signed by the CA’s root (or possibly by a higher-level intermediate cert that is signed by the root). All modern browsers come with root certs from many different certification authorities, but that is no longer enough by itself because most site certs are no longer directly signed by the CA root.
Firefox has a bunch of intermediate certs installed in it by default, so it can validate certs from sites that don’t provide the whole chain. IE on the other hand only has the root certs, so unless a webserver provides the intermediate certs, IE users are out of luck (insert obligatory firefox-is-better assertion here.)
I suppose at some point I could explain about SSL and certificates and signing and all that, but maybe later.
(As of July 2011, this entry has been updated for use with Contribute CS4. If you are still using CS3, see Danielle or I for help with updating.)
This is another in an occasional series of instructional entries.
Most people who edit pages on the WOU website use Macromedia Contribute. (Well, OK, technically it’s adobe now, since they bought out Macromedia.) Before you can get started editing, though, you need to connect to your site. Here’s how to do that:
- First, you need to know your website folder. For example, if your website is https://wou.edu/test/example/index.php, then your website folder is test/example.
- Open Macromedia Contribute. You probably don’t have it installed on your machine, so you will need to use Remote Desktop to log into ts.wou.edu. Once there, look in the Start Menu, All Programs for Contribute CS4. Important: do not go to “ts9.wou.edu” as before; just use “ts.wou.edu”.
- In Contribute’s address bar, enter “X:\(your web folder)\_mm\publisher”. Continuing the example above, you would enter “X:\test\example\_mm\publisher”. Be sure to use backslashes (above the enter key on most keyboards) rather than normal slashes. Take a moment to thank Bill Gates for making this more complicated than it needs to be.
- After hitting Enter on that address, you should see a purple and grey icon in the main window of Contribute. Double-click it. If you are warned about an unsafe system action, click Yes to continue. A dialog box should pop up, asking for your name, email address, and a connection password.
- If your personal info is not automatically entered, put it in. For the password, use “publisher4” instead of your own password. Don’t worry about this password being insecure; the real security on the website works at a deeper level.
- The dialog box should disappear, and you should be taken to your site’s home page. From there, you can navigate to any page within your site and use the Edit button to begin editing. That’s all! Next time you start Contribute, it should remember your connection, but if you ever start up Contribute and it doesn’t show your connection, just go through these steps again.
One more thing: After clicking Edit and making changes on a page, make sure you either publish it, cancel it, or save it for later. If you quit the program without doing any of these things, the page will be locked and you will get an error the next time you try to edit the page; Contribute will think that you are already editing it on another machine and not let you in. Call or email me to get that lock cleared.
If you want training with Contribute or about Web design, contact Scott Carter in the Technology Resource Center, at email@example.com or extension 88848. I can answer basic questions and help if anything seems to be wrong, but Scott handles any training beyond that.
A few people are reporting that they make web edits on the X: drive, save the file, but the changes never actually show up on the web.
If this is happening to you, the first thing to check is the label on your X: drive in My Computer. It should say “wouwebsite$ on ‘Samba 3.3.4 (firefly)’ (X:)”. If your X: drive says ‘sundown’ instead of ‘firefly’, it means that your X: drive was set up manually at some point, and so it couldn’t get changed automatically when we changed everybody else’s.
Right-click the drive and choose Disconnect, then log out and back in to your computer, and whether you see an X: drive and that it says firefly instead of sundown. If you see that, everything should be fine now, except that if you use the Terminal Server, you need to make sure to check there too.
If you don’t see an X: drive after logging back in, let me know. You can reconnect it by going to the Tools menu at the top of the My Computer window and choosing “Map network drive” which should pop up a dialog box. Choose X: from the Drive menu, and type “\\firefly\wouwebsite$” in the Folder box. (Don’t type the quotes, and make sure you use backslashes \ rather than normal slashes /.) Make sure the “Reconnect at logon” box is checked, then click Finish and you should be all set.
EDIT: We have now changed things so that you can no longer make changes if your X: drive is connected to the wrong place. If you went into your X: drive and saw only a text file that told you to come here, that’s why. If you go through the above process (remember to do it on the terminal server too, if you use it) and it does not fix anything, please let me know!
All recently changed files in the old server (sundown) have been moved to the new server (firefly) as of 1:00 AM on Monday August 30. Again, please let me know if anything is missing or looks wrong.
As of a bit after 5:00 PM Friday, our main webserver is running on Apache, rather than Sun’s Java Enterprise System Webserver as it has been for years. Originally this change was meant as a test, but by late Friday night (AKA Saturday morning) things looked good enough that we decided to run with it.
Unfortunately, what looks good at 4:00 AM isn’t always so great by the light of day. Ever since then I’ve been running around putting out fires.
Here’s a brief list of the problems we’ve seen (most are already solved.)
Cold Fusion (.cfm) pages don’t work on the new server. All those sites I’ve found have been redirected back to the old server where they do work.
Blog admin didn’t work. I had to point that back to the old server too, for now.
Portal single-signon links weren’t all working. The link for blog admin is fixed. The WOUAlert link isn’t fixed yet, but at least I know the problem and am working on it.
PHP pages using old-style code block tags didn’t work. Some people were coding PHP using the old, deprecated tags to delimit blocks of PHP code. The correct way to do this is . I had to tell the new webserver to allow the old-school code, but we really need to get rid of it because it can get mixed up with other languages. BTW, this is what caused the quick links on the homepage not to work, so I’m not totally innocent here myself.
Old-style PHP database calls didn’t work. I replaced the PEAR/DB module so some of this stuff will work again, but there might be other stuff made without PEAR/DB and with obsolete database tags that won’t work until it is rewritten.
Overly tight security settings. Some pages weren’t able to get external files that they needed and so were erroring out.
There’s more, but I need to get back to that WOUAlert problem.
Prettymail is now in place for both faculty/staff and students. Now I’m hard at work gettinr ready to move our main webserver onto Apache (woo-hoo!). More on that later…
OK, I take back everything I said about Adobe’s tech support after the first time the Contribute server failed on us. What? You say you didn’t hear what I said about them? That’s probably a good thing, considering some of it was unprintable.
Anyway, this time I actually got a competent support engineer, and I didn’t even have to battle my way up the hierarchy for more than a few hours (let alone three days like last time, grumble grumble.)
What impressed me the most about her was not just that she knew what she was talking about, but that she kept after the problem. We had one possible solution that would have taken a couple of days to implement, and instead of just sitting back and waiting, she kept working on our issue. That floored me; maybe I’ve just had bad luck with corporate tech support, but I’ve never yet dealt with someone who would do that.
Anyway, she came up with a simple solution that I hadn’t tried because it didn’t seem to make any sense… but it worked like a charm. You may have noticed that the login delay is now much shorter, too.
So, tech support saved the day!