problem with hostname.php when i migrate 1.3.4 => 1.3.5.

[Tom Elliott]

I really believe you just need to change the wget command to read as:
hostinfo=$(wget -U '' -qO --post-data="mac=$mac" - "http://${web}service/hostname.php 2>/dev/null)
You could also try:
hostinfo=$(curl -A '' -fkq --data "mac=$mac" "http://${web}service/hostname.php" 2>/dev/null)

[jc35]

@Tom-Elliott Hello, I try this, with 1.4.0-RC3, I have the same problem, I think we have a problem with database, but I don’t know how to find this problem.

[george1421]

@jc35 I’m running 1.4.0-RC3 on my dev system and when I key in

http://<fog_server_ip>/fog/service/hostname.php?mac=b8ca3ace1d1a
I get:

#!ok=b8ca3ace1d1a #AD= #ADDom= #ADOU= #ADUser= #ADPass=

(in my case the host name is the same as the mac address by intent)

The same for wget from my mint laptop

wget -q -O - "http://192.168.112.24/fog/service/hostname.php?mac=b8ca3ace1d1a"
#!ok=b8ca3ace1d1a
#AD=
#ADDom=
#ADOU=
#ADUser=
#ADPass=

I wonder if the variable ${web} points to something other that what you think.

[jc35]

@george1421 It’s work with the database is local, but it doesn’t work with the database is on another server.

[george1421]

@jc35 How (precisely) do you have fog setup? All fog master fog servers (not storage nodes) have local databases.

[jc35]

@george1421 I install fog with a local database, after I change the config.class.php for use with a database on another server.

[Tom Elliott]

@jc35 So the problem is likely authentication with the other database?

[george1421]

@jc35 said in problem with hostname.php when i migrate 1.3.4 => 1.3.5.:

I change the config.class.php for use with a database on another server.

Understand I have to be that guy and also know I’m talking as a Moderator and not part of the core FOG Project team.

You are running in an unsupported configuration. I (personally) don’t understand how/why fog is current able to function with this setup. Yes I know it can be done, but the question is should it be done, we have not tested this setup so there is no guaranty it will work with future releases.

[jc35]

@Tom-Elliott I don’t know, I have just the message “#!ng” since 1.3.5.
The web web interface it work fine.

[jc35]

@Tom-Elliott

@Tom-Elliott said in problem with hostname.php when i migrate 1.3.4 => 1.3.5.:

@jc35 So the problem is likely authentication with the other database?

the authentication is it different that web interface ?

[Tom Elliott]

#!ng = Not enabled globally.

Is the value enabled in Services->Hostname Changer?

[jc35]

@Tom-Elliott said in problem with hostname.php when i migrate 1.3.4 => 1.3.5.:

#!ng = Not enabled globally.

Is the value enabled in Services->Hostname Changer?

Hello,
thank you very much.
It’s work fine.

what is better wget or curl ?

what is better hostname.php or hostinfo.php ?

[george1421]

@jc35 said in problem with hostname.php when i migrate 1.3.4 => 1.3.5.:

what is better hostname.php or hostinfo.php ?

It depends on what data you need? If you just need AD info then hostname.php is the answer, if you need to know more about the image and host then hostinfo.php is the answer. Just understand the output of both are intended for different purposes. So you will have to parse the data differently for each page.

[Tom Elliott]

@jc35 For wget or curl either or, matter of preference really.

I’d recommend hostinfo.php though it would mean sourcing the returned data to have access to the variable. That said, i already pass the hostname in with the kernel args, so I think you can simply do a lookup with:

echo $hostname

[jc35]

@george1421
OK,
How to do mark this post as solved ?

[jc35]

@Tom-Elliott
ok.