No access to //hda

[mciv]

I could use a little guidance in sorting this out. My hda has been running great but now I cannot access it from a web browser. I get "Firefox can't establish a connection to the server at hda". I've tried the IP address. I've tried from the HDA box itself as well as multiple other computers and all return the same result. Share points mount fine and internet access is working.

I did run hda-install -fn INSTALLCODE and I've restarted the machine but still no change.

[moredruid]

try clicking this link: http://hda
if it doesn't work, please check if your client is using a DHCP address, if not, configure it manually.
also make sure your router isn't giving you a lease, but Amahi is. Amahi will sort out DNS for your internal network.

[rgmhtt]

try clicking this link: http://hda

Per /etc/hosts this should resolve to 127.0.0.1, ie localhost. So as long as networking is working and /etc/hosts is not hosed this should work.

Unless /etc/resolv.conf points to a DNS that has an entry for hda.<your resolv.conf search here> that is a different address than what your hda is running at.

Thus:

check out the contents of:

/etc/resolv.conf
/etc/hosts

and

service network status
ifconfig eth0

[mciv]

Router isn't the problem as DHCP is off and everything was working fine.

Here is contents of hosts file
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost localhost
::1 localhost6.localdomain6 localhost6


Resolv.conf just contains my domain plus the HDA IP address.

Very odd is that running service or ifconfig both return the error that the command cannot be found. I'm not at the server but doing it through VPN but it should still work, right?

[rgmhtt]

Router isn't the problem as DHCP is off and everything was working fine.

Here is contents of hosts file
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost localhost
::1 localhost6.localdomain6 localhost6

This is a problem. It should say:

127.0.0.1 localhost.localdomain localhost localhost hda

I can't guess why, perhaps cpg can comment.

Resolv.conf just contains my domain plus the HDA IP address.

Assume your domain is 'home' and your IP address is 198.168.0.20 Then your resolv.conf SHOULD be:

search home
nameserver 198.168.0.20

Thus the URL of http://hda will resolve as http://hda.home to 198.168.0.20

Test this with the commands:

host hda
host hda.home <or whatever your domain is in that search entry>

Very odd is that running service or ifconfig both return the error that the command cannot be found. I'm not at the server but doing it through VPN but it should still work, right?

No. if you log in as a user, /bin is not in the path. You have to edit ~/.bash_profile and add it to your path and log in again. Even if you SU to root, root just inherits the path of the user, not the path you would get directly logging in as root. I have fought this 'oddity' in RHEL/Centos/Fedora for a long time and just make the profile change...

[moredruid]

Elevating or changing your privileges to a different user always has this issue.
However, there's an easy fix for that instead of modifying it in /etc/profile or in /etc/bashrc
To become root with all the paths, aliases etc. associated with root run the following command:

Code: Select all

user@localhost $ su -

or - if you're in the sudoers group - the following command:

Code: Select all

user@localhost $ sudo su -

Note the hyphen! This tells the shell to run the .<shell>rc of the user you are sudoing to. In case no username is given the shell interprets this as sudoing to the root user (first match in /etc/passwd = the lowest uid = root).

You can do this with all users on your system. Say you have a hardcore developer (username: harddev) on your system who has known UNIX forever and is used to the Korn shell (ksh) and has this setup as his default shell sudoing to his account with the hyphen (-) will give you all his privileges and the Korn shell including his paths, aliases etc. as your working shell.
Here's the command:

Code: Select all

sudo su - harddev

So now you're user harddev with a Korn shell and all his preferences set. If you're like me you don't like the Korn shell you can issue the following command:

Code: Select all

sudo su harddev

this gives you all the privileges of user harddev BUT a regular Bash shell, however you will need to type in the full path of an executable.
hmmm but we don't like that... so we do a "sudo su - harddev" and run the command "bash" afterwards, this gives us the Bash shell with all the paths and aliases for that user.

Please note that for the sudo command it's easier if you're in the sudoers file. If you want to know how to put your account in the sudoers file, just ask and I'll explain.

[mciv]

This thread has been very informative and I appreciate it but unfortunately no change.

I added "hda" to the hosts file.
I also ran these two tests,
host hda
host hda.home <or whatever your domain is in that search entry>

and both resolved to the correct IP.

I am really enjoying Amahi except for this issue plus an issue with DNS while connected to the VPN.

[cpg]

we really need a troubleshooting guide for networking.

from your hda itself (via ssh or at the desktop in a terminal), can you:

0.- ping hda
1.- ping router
2.- ping 68.180.206.184
3.- ping yahoo.com

from one or more the clients:

4.- ping hda
5.- ping router
6.- ping yahoo.com

how is that?

[mciv]

from your hda itself (via ssh or at the desktop in a terminal), can you:
0.- ping hda
yes
1.- ping router
yes
2.- ping 68.180.206.184
yes
3.- ping yahoo.com
yes

from one or more the clients:

4.- ping hda
yes
5.- ping router
yes
6.- ping yahoo.com
yes

Everything works fine except loading HDA webapps or the HDA setup page.

[mciv]

Just thought I'd pass on that I figured this out. The problem was the apache was not running and I didn't figure it out until I rebooted and watched the messages. The problem was a configuration error in "/etc/httpd/conf.d/1016-phpMyAdmin.conf" that seems to have only become a problem after the auto upgrade. The path for the the root files and log files was incorrect.

Thanks for the support.