Geeklog Forums

I'm hoping this is an easy fix. I have several sites hosted on a machine in my garage connected via FIOS. Verizon blocks port 80 in our area (despite the salescreature swearing that they did not), so I have dyndns mapping incoming connections to port 8080, and then the router maps it back to port 80.

So, "http://www.christianfamilywebsite.com" resolves to "http://christianfamilywebsite.iswizards.com:8080", then the router forwards this to "http://christianfamilywebsite.iswizards.com" on a local machine on port 80.

This was geeklog 1.4.0sr5-1. Recently I upgraded to 1.5.2SR2. Everything looked fine and I thought the upgrade was successful, but then trying to access the website from outside my network, I notice that the static content is not displaying and links are pointing at URLs that will not resolve from outside.

So, for instance, the path to the mail gif is:

http://christianfamilywebsite.iswizards.com/layout/family/images/mail.gif

The url "christianfamilywebsite.iswizards.com" will resolve from my internal network (which is why I didn't immediately know that something was wrong) but it will not resolve from outside. If it were either

http://christianfamilywebsite.iswizards.com:8080/layout/family/images/mail.gif

or

http://www.christianfamilywebsite.com/layout/family/images/mail.gif

...it would display correctly from the outside.

In my own experience, this is an indication of a mis-set site_url. I've been using the trick of setting the site_url to null (two single quotes with nothing in between) and this has worked both inside and outside my network. It doesn't work anymore, and setting it specifically to "http://www.christianfamilywebsite.com" or "http://christianfamilywebsite.iswizards.com:8080" has no effect.

Interestingly, the embedded gallery works fine.

For awhile I couldn't figure out how I'd messed up. But then I tried a website that I'm hosting on the same machine which I have not upgraded yet, and it still works! (Check for yourself: http://strawyurt.com) So it looks like something changed during the upgrade.

So, what's different about 1.5.2sr2? Does it handle site_url differently? How do I fix this? Thanks in advance, O Geeklog wizards.

Ok, I read through the change notes and discovered that with 1.5 config.php is no longer used. That explains why my changes were no longer having effect.

So I looked at siteconfig.php and it didn't seem to have the setting I was looking for. Which probably means it's in the database and accessible from the configuration menu option. Which, parenthetically, seems like it could result in a chicken-and-egg problem if you can't get to the configuration page because of something mis-set in the configuration page.

I find that the configuration page won't display because my layout isn't compatible with 1.5. So I have to fix that first before I can proceed. Stay tuned.

Here's the solution.

This assumes that you have some way to get to the "configuration" page. This presupposes two things -- (1) your default profile supports the new 1.5 configuration page, and (2) the configuration is set close enough so that you can at least get to the page.

The former can be fixed by (a) making a backup of your layout, (b) copying the new "professional" layout into your layout directory, and (c) copying your files back into your layout directory. This will put any new files in your layout, and hopefully the configuration page will be one of them. Fix ownership and permission as necessary.

The latter... Well, I got lucky, because the site URL was set during the upgrade to something that would not resolve from the outside world, but I maintain my own servers, and it so happens the site URL *would* resolve from the inside. Else I would probably have had to hack the MySQL table directly.

Specifically, the site is "www.christianfamilywebsite.com" which due to Verizon policy needs to resolve to "christianfamilywebsite.iswizards.com:8080". Either will work, but instead the site URL was somewhat arbitrarily set, during the upgrade process, to "christianfamilywebsite.iswizards.com" (no port number) which is just wrong.

Changing the site URL fixed the first three of ten websites I need to upgrade. I consider this a "luck-out" but I'll take anything at this point. Will continue with the rest of the upgrades tomorrow.

Turns out that wasn't the solution, and changing the site url to the advertised name of the site (in this case "www.christianfamilywebsite.com" now prevents me from logging into the site as admin. As I feared, having critical settings accessed through the web site presents a chicken-and-egg problem if something mis-set prevents you from logging into said site. Investigating other ways to change that setting.

I see I'm just talking to myself here.

Restored the database from a backup, managed to browse to the config page.

The situation as it currently stands:

The website is accessed from the outside as http://www.christianfamilywebsite.com

This is translated to http://christianfamilywebsite.iswizards.com:8080 to get around Verizon blocking port 80

It gets translated again by the router to http://christianfamilywebsite.iswizards.com (on port 80)

The site url was set by the configuration process to http://christianfamilywebsite.iswizards.com, which doesn't resolve on the outside. I set it to http://www.christianfamilywebsite.com and the static content (the original problem) now displays correctly from the outside.

The new problem is one of authentication. I can log into the site from inside my own network, but not from the outside. (I VPN into work, bring up a browser, and point it at my website to test this.)

I tried changing the cookie url setting, and locked myself out of the website. Since it's not obvious where these settings are in the database, I had to restore from backup to change the setting back.

Trying to decide how to proceed. I had this working under 1.4, but the settings I used to use don't work the same.

Still broken, still don't know how to proceed still looking for a response from any knowledgeable person.

Last night I mapped out the Geeklog database structure, tonight I'll delve into it and try to find the right entries. I currently can't get to the configuration page because of settings on the configuration page.

My process has been, try a site url or cookie url setting, discover that I either can't navigate to the page or can't authenticate (or both), restore the entire freaking database, and then try again. :banghead: This is a silly way to proceed, and I don't see how people do it who rent space, rather than maintain their own servers. How many database restores can you request before your hosting service tells you to get lost?

As a practical matter, you will never change the site_url on the configuration page, because if it's correct you don't need to change it, and if it's wrong, you won't be able to get to it. Command line access to MySQL is imperative. One should keep that in mind when one talks to hosting services. Often, command shell is an extra cost.

What is your question? :kickcan:

I only have shared webspace without SSH and no problems with updating, well, hardly any :wink:

Soemtimes it is more tricky the more you can adjust.

My mood is "confused" because "depressed" wasn't available.

I guess it's possible I've been unclear. Let's try again.

Firstly, it's really nice to hear another voice.

Immediate question:

My site_url is set wrong on the configuration page. Because of this, I can not navigate to the configuration page to change it. Thank you, developers. :banana: :banana: :banana: Besides giving it all up for a loss and taking up rice farming in Hai Phong, what do I do?


The larger, but less immediate question:

Because my ISP blocks port 80, I have "www.mysite.com" forwarded to "mysite.otherdomain.com:8080". I have it hosted on a server-class machine in the garage. (Actually, it's hosted on an instance of Fedora 10 running on ESXi, but that's not important.) (I used to do port forwarding from 8080 back to 80 on the router, but that was too confusing so the website actually runs on port 8080 now.) (While we're playing with parentheses, I have three Geeklog sites on this server running 1.5.2 that are behaving as described, and seven others still running 1.4 which are working fine.)

In order to be able to (a) have the site render correctly and (b) also be able to log into the site and make changes, what do my configuration settings need to be? Possible candidates include the site url, the admin url, and the cookie url. The settings I used in 1.4 demonstrably do not work in 1.5.2. Using "www.mysite.com" demonstrably does not work. I tricked it into working, once, by putting www.mysite.com in my local /etc/hosts, which allowed me to log in and navigate to configuration.php and make changes, once. Using "mysite.otherdomain.com:8080" doesn't appear to work either, but I can't be certain because I can't get back to the configuration page to see if maybe I made a typo.

That will do for now. I have an extra credit question which I will save for later.

I have no idea if GL can be configured to swallow things like that christianfamilywebsite.iswizards.com:8080 Can`t you try to sort this out first?

You can use the old variables like $_CONF['path'] in siteconfig.php it overrides the settings in MySQL.

BTW a server may look more impressive than a car in a garage but have you ever thought about reseller webspace?

I did not know you could override the settings in siteconfig.php. That might be the key bit of data which gets me back on the air. I can only hope that the variable names are the same.

I actually have a rack of servers in the garage, with cooling and redundant power and so forth. Mostly scavaged from here or there, or purchased at scrap sales. For many years I had a commercial, static internet connection going to the house, but have recently switched to a consumer circuit to cut down on expenses.

I am serving 10 non-commercial websites (including gigabytes of file space) and a security system from my garage. It'd cost me a fortune to host that externally.

I maintain my own servers because I can provide disk space for myself far cheaper than anyone else can. I have over 3000 photos online (no, they're not porn) and the price of disk space is important to me. So is having complete control of my environment. It allows me to provide a degree of customization that I can't easily get from an external company, (using virtual hosts, for instance) and is a learning experience besides. I recently switched to a bare-metal virtualizer so I could consolidate some of my servers. It was a positive experience. I wish I could say the same about this Geeklog upgrade.

Serving your own website from an alternate port is not unusual. It's the second most common thing to do, right after registering with a dynamic dns service.

This all used to work under Geeklog 1.4, so it jolly well ought to work under 1.5.2.

I think I have a solution. I know I said that before, but I really think I have it this time. :-)

To recap, the domain www.christianfamilywebsite.com was redirected to christianfamilywebsite.iswizards.com:8080 by dyndns.org (because Verizon blocks 8080). My router translated it back to christianfamilywebsite.com:80.

This worked in 1.4. I could log in as admin from my private network and from the outside. Part of this, I think, is that I had both site_url and cookiedomain set to null, (a trick I had read in the forum) and somehow it got set to whatever was appropriate to get to it from both inside and outside.

Upgrading to 1.5.2 immediately busted it. Static content (graphics and images) would not display and I couldn't log into the site. I was able to "trick" the configuration.php screen to come up exactly once, with some ugly additions to a hosts table, made the changes I thought I needed, and locked myself out of the site. When either site_url, admin_url or cookiedomain is set wrong, you will either not be able to navigate to configuration.php, or not be able to authenticate, or both.

After a lot of hue and cry, I have the site back the way it was; IE, static content displays correctly and I can log in from both outside and inside. There are still a few things broken, mostly to do with the menu plugin, which causes the menu links to point to urls that no longer resolve, but I can fix that later.

The first step was to simplify my setup. I configured the router to not translate from 8080 back to 80, and httpd.conf to expect traffic on 8080. This made the URL the same both inside my network and outside. This left finding values for site_url, site_admin_url and cookiedomain that worked, and figuring out how to change them.

I have read that you can override variables in siteconfig.php, but that leaves "wrong" values in the database which worried me enough that I rooted through mysql until I found the values, and made the changes there.

I have 10 websites on this server, and they all share the same instance of MySQL. So each instance of Geeklog has it's own database. For the purposes of this article, the database in question is gl_db_family.

The interesting table is gl_conf_values

The columns are name, value, type, group_name, default_value, subgroup, selectionArray, sort_order, and fieldset.

The only interesting columns are name and value.

You want to change the string in the "value" column for each of the three rows who's corresponding names are "site_url", "site_admin_url" and "cookiedomain".

There is a gotcha: The "value" is itself three fields delimited by colons. The first is always "s" (for string, I guess) the second is the number of characters in the string not counting the quotes, and the third is the url surrounded by quotes. The string is followed by a semicolon. Why they didn't use is_string, sizeof and sscanf... ok whatever.

So when you replace the string, you have to carefully format the replacement as follows:

s:size_of_myURL:"myURL";

In my case, I had to set the site_url to "http://christianfamilywebsite.iswizards.com:8080". (You must include the port number if it is not 80.) This worked out to:

s:48:"http://christianfamilywebsite.iswizards.com:8080";

The mysql code is:

mysql> use gl_db_family;

mysql> update gl_conf_values set value = 's:48:"http://christianfamilywebsite.iswizards.com:8080"'; where name = 'site_url';

Test by:

select * from gl_conf_values where name = 'site_url';

Do the same thing for site_admin_url, but add /admin to the string and increment the character count by 6.

"cookiedomain" only wants the domain, not the port or full url. In this case, I had to set cookiedomain to:

s:36:"christianfamilywebsite.iswizards.com";

I hope this helps someone. As I said, the situation is mostly stable at this time. I still have some changes to make in the menu plugin, and then I have to make these same fixes to the two other websites I had upgraded, and then I have to decide whether upgrading the other seven websites is worth it. But at least the website is accessible now and I can scribble on it.

Have you tried to write
$_CONF['site_url'] = 'http://christianfamilywebsite.iswizards.com:8080';
into the siteconfig.php ? It should have overwritten the settings in MySQL

No I didn't, although I believe you that this works. I decided to fix it in the database mostly because it bothered me that it was set wrong in the database. Silly, perhaps.

Still, I have two other sites to fix, and it's a worth experiment.

Would be good to define the variables which make GL hang up or inaccessible.

FYI: That's the format used by the PHP serialize function.

bye, Dirk