forum.excito.org

Hi,

I have a domain that points to my bubba2, so if I surf to http://www.mydomain.com or simply http://mydomain.com I reach the bubba default web site.

I would like to move this default web so that it answers only on http://bubba.mydomain.com instead.

I have modified the "bubba" site in sites-available and added ServerName bubba.mydomain.com to both the virtual hosts there, and that seems to work. But the old names are still enabled even though there should be no site listening to them?

Is there some other place I need to fiddle to remove that?

/Tompa

PS. Really like the new forum look, it's fresh!

Hi there,

All you need to do is to assign a new port the bubba2 ie say port 8082

1st you need to Create a Port Forward Rule to forward the port 8082 to the bubba2s firewall (accept all ip on port 808 Protocol TCP)

2nd Create an Rule on your Router side setup - Open a Port 8082 to your Wan Bubba2 ip address and Create another rule through NAT to port forward that port 8082 to the bubba2 wan ip address in your routers setup.


This will move your bubba webpage to that port ie www.yourdomainname:8082 and leave your normal www Address to view as normal

This will allow you to run a private web-access page at port 8082

Thanks
steeler

Hi and thanks for your reply.

Your solution would probably work but it's not exactly what I'm looking for.

I would like to run all my web sites on port 80 so that clients out there don't have to know what port to surf to, and instead use subdomains to have Apache transfer them to the corresponding site.

There is an howto for this and it actually works, but I don't know how to configure Apache to stop listening to the default names, in other words:

http://bubba.mydomain.com -> should reach the bubba default site.
http://forum.mydomain.com -> should reach another site (like phpbb3 forum).
http://www.mydomain.com -> should give a 404-error
http://mydomain.com -> should give a 404-error

Anyone has a clue?

Thanks,
Tompa

First you have to add your subdomains in your dns-server, pointing to your bubba ip. Then maby create a 404-page in your bubba.

Hi

Did anyone ever manage to do this?
I am looking for the same setup as Tompa suggests, but on B3.

Basically I want to run the B3-application (/admin and /album) as a virtual host. I want any other virtual host to reply 404 on http://somehost.mydomain.com/admin.
Since the aliases for /admin and /album are defined as general Apache2-rules in /etc/apache2/conf.d I simply tried to move these configurations into a virtual-host definition under /etc/apache2/sites-available instead. (I think that made sense anyway; the admin-application is, in my mind, rather a site than a general Apache ruleset).
That solution worked.... almost. The main admin-application seemed to work fine on that domain (and ofc gave 404 on any other domain), but some portion of the ajax-login-function on /album didnt run within the virtual host.
The result was that any login-attempt in /album failed and the successful login in /admin wasnt shared in the album-page. Also, the login-call made from /album wasnt logged in the virtual-host specific access-log, but instead in the general /var/log/apache2/access.log.

That's as far as I got last night before giving up. I didnt have the heart to debug the javascript/ajax-portion of the album-login-functionality. Nor do I want to edit those scripts either since that would only break upon any future updates of the frontend.

If anyone have successfully done this, I'd appreciate any suggestions.

read the apache logfiles and you see to what host each request is directed and to what file it is sent. This will answer your problems

Thanks for your reply. I'm glad someone read my ramblings.
As I wrote in my previous post, I already had looked in the access-logs to find which virtual host the request goes to: the default host.
My problem, otoh, was regarding why/how it ends up there.

Despite better judgement and even though I promised myself to simply let it go... I, of course, couldn't. I started looking at the php-pages of the album-application and I, lo and behold, found the culprit:

All the calls for the admin-url in album/models/admin.php are actually hardcoded to "http://localhost/admin/ajax_session/*". I am far from a php-expert, but I dared as much as replace the host-part ("localhost") of the url-strings to "$_SERVER['SERVER_NAME']" and it seems to work just fine now. As I typed in my previous post, I really didn't want to mess with the frontend logic, since it will get overwritten by the next update (unless that update includes this fix, of course).

Excito can consider this a bugreport, though I would of course set the lowest prio for it. Despite the low prio, the fix is easy enough that it could be worth doing anyway. If they (or anyone else) decide they want to fix this, I'll be glad to help if anything regarding this issue is unclear.

Harris wrote:All the calls for the admin-url in album/models/admin.php are actually hardcoded to "http://localhost/admin/ajax_session/*". I am far from a php-expert, but I dared as much as replace the host-part ("localhost") of the url-strings to "$_SERVER['SERVER_NAME']" and it seems to work just fine now.

Good grief. This has to be the worst form of web coding I've seen in years. Well done in finding and hacking it. I won't go as far as calling it a fix as I'd say routing internal calls from PHP by using apache as a parser is such an abomination it should be removed using hazmat suits. In what excellent piece of coding brilliance did you discover these gems?

Ubi

Ubi wrote:I won't go as far as calling it a fix as I'd say routing internal calls from PHP by using apache as a parser is such an abomination it should be removed using hazmat suits. In what excellent piece of coding brilliance did you discover these gems?

*sigh*
My lack of php-experience is actually the reason why I intended not to call my hack a fix. I'm sorry if it was interpreted that way. It was a hack with the pure intent of testing if those hardcoded urls were the sole reason for the malfunction of the application. Feel free to clean it up using the correct methods as I'm sure the Excito developers will if they intend to fix this.