Where do you set the $web var used in /bin/fog.checkin

[g.chanaud]

Hi,

my fog server is running in a virtual domain.
Until then it was working fine.
I just recently updated to latest rev and the /bin/fog.checkin script seems to use a $web var everywhere to execute the .php scripts…
This var is set to my webserver IP adress, but i want it to be set to the subdomain name for which the webserver bind to the correct virtual domain.
I didn’t find the source of this var. Where can i change this var ?

Thanks,
Guillaume

[Tom Elliott]

It’s set as a kernel argument. Particularly if you look at BootMenu.class.php -> setTasking() it should have an area where you’ll see plain text in the format of web='.$web or something like that.

It get’s the $web from the database under FOG Configuration->FOG Settings->Web Server->FOG_WEB_HOST.

[g.chanaud]

It’s what i thought but it’s not working like that apparently.
My FOG_WEB_HOST is correctly set (since ages) yith the domain name, but if i echo the $web var in the shell or in the fog.checkin script it’s always the ipaddress which echo.

I found the bug here
in BootMenu.class.php line 17

$webserver = $this->FOGCore->resolveHostname($this->FOGCore->getSetting('FOG_WEB_HOST'));

has to be changed to

$webserver = $this->FOGCore->getSetting('FOG_WEB_HOST');

The $this->FOGCore->resolveHostname() replace the hostname with the ipaddress

[Tom Elliott]

So what is the reasoning it has to be changed?

See I attempt to resolve it to IP because I don’t know what kind of DNS/Hostnames are going to be assigned to an individual host.

[g.chanaud]

Ok i understand.
You let the server resolves the hostname for the client because they may not know how to resolve by themselves.
But which are the condition where the client does not know how to resolve ?
If i put an ipadress in the FOG_WEB_HOST it’s not necessary to resolve -> i want to force this particular ip for all clients, so it’s ok to not resolve on the server
If i put a domain in FOG_WEB_HOST and server and clients are binded to the same dns and both will resolve to the same ip, , so it’s ok to not resolve on the server
If i put a domain in FOG_WEB_HOST and server will resolve to an ip X and clients to an IP X or Y or Z depending of their dns configuration. If i have those kind of configurations, that’s mean that i divided my network and want everybody to get informations from their relative DNS, so the client has to resolve, not the server.

I don’t see any case where the server should resolve for the client. If my client hosts gets different DNS, it’s for a reason isn’t it ? Maybe i didn’t see a special case.
The only special case i see is that my clients doesn’t have any DNS server set at all and can’t resolve by themselves. Is it possible to send the DNS server set for the eth card to the php script with the POST/GET vars ? If not set, server resolve for the client, if set, it let the client resolve ?

[g.chanaud]

Hi any news on this ?
Was it a user request to let the server resolve the hostname ? It’s a so strange behavior…it breaks all client network intelligence. I don’t find any usefull behavior with a server-side name resolution.

[Tom Elliott]

You really should look at the commits. I removed the resolvehostname over the weekend and even further removed it from all instances in the file.

That being said, I don’t understand why it can’t be the ip directly sent. Just because it doesn’t make sense doesn’t necessarily mean it’s a bug. I purposefully had it resolving it and it worked in doing what it was told to do and how it was expected to work. How is that a bug?

[Tom Elliott]

To further add on the resolveHostname method works by attempting to resolve a hostname and returning the ip back. If the hostname is an IP it won’t attempt resolving it and simple return the ip. The reason for passing it through the method for everything is so the method handles whether or not to resolve and returns the ip without having to continuously recreate the wheel when/where needed.

[g.chanaud]

Hi, you’re right it’s not litterally a “bug”. It’s more a strange behavior (that’s why i posted in General section).

Sorry ! it’s right i didn’t checked the last commit because i’m working with fog only in a special environment and i was on others things last days.

It can’t be the ip directly because when you’re hosting the fog webservice in a VirtualEnv environment, you must pass the complete subdomain/domain for your webserver to redirect accordingly. So the client as to send his POST/GET commands to the hostname not the ip !
Hosting services in VirtualEnv is common.
Sure, it’ll work if your fog virtualenv is configured as the default one (pointing to the ip will redirect the webserver to the default virtualenv and it’ll will works), but if you host several webservices on the same webhost (or webhost farm) AND fog is not the default one, you must pass the domain name and not the IP. If you don’t do this, the webserver will answer back with your default virtualenv which can be anything but fog.

BTW, in my opinion, resolving a hostname is a client behavior.

Thanks for your time !

[Tom Elliott]

While I agree when a system is in it’s typical environment, that a client should resolve the hostnames, during the imaging process the client knows nothing about it until it boots in. Because of this, the server is ultimately handling the resolving anyway. I was just making an attempt to direct specifically to the IP as there’s no extra steps needed to resolve where the hostname actually lies.

Hosting in a virtual environment is common, and it’s how my development systems are setup. I have NO issues even with a multiple Virtual Host http environment on top of multiple VM systems redirecting all the way across.

I suppose it does no good to gripe/complain, as I already did as you requested anyway.