Attempts to access the control panel at https://our.hostmachine.org:10000
are failing.
I restarted webmin on the box via ssh: /etc/init.d/webmin restart
I got the prompt back with no errors reported and no status reported. I assume it restarted (but I don't know enough to investigate further. But if I run top, I see the occasional python process kicking off mailman... I believe this is Virtual min (not sure really as we don't use mailman at all)
In Fire fox I simply get this (see below). Perhaps it is a DNS issue?
What are the next step to trouble shoot this?
The connection was interrupted
The connection to sat.gurudeva.org:10000 was interrupted while the page was loading.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
Howdy,
The Mailman/Python processes you're seeing aren't related to Virtualmin... that's all part of the Mailman service, which is one of the Virtualmin dependencies that's installed during the Virtualmin installation process. But seeing that running doesn't mean Virtualmin is running.
One way to tell if Virtualmin is running is to use netstat to see if anything is listening on port 10000:
netstat -anlp | grep :10000Try accessing port 10000 in your browser by using the IP address, rather than a domain name, and see if that does the trick.
-Eric
Netstat returns:
[root@sat ~]# netstat -anlp | grep :10000 tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1781/perl
udp 0 0 0.0.0.0:10000 0.0.0.0:* 1781/perl
So, since I think VirtualMin is written in perl that means at least it is listening on port 10000.
using the IP I gets the same behavior: no response.
What next?
Yeah, that definitely appears to be listening.
Is your server on a LAN, and are you also accessing it from the same LAN? That kind of setup could cause the issue you're seeing -- if that's the case you may want to use your server's internal IP address.
Also, is there a firewall setup on your server that might be blocking it? You can determine that by running "iptables -L -n".
-Eric
It's not on our LAN here here in Hawaii, its in GoGrid's data center in San Francisco (Formerly "ServePath)
IPtables are showing
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:10000 ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:10000 ACCEPT tcp -- 75.109.138.39 0.0.0.0/0 tcp dpt:10000
hmmm... we just got a new internet connection and the above IP's are from our old gateway here... But this doesn't make sense.. my developer in Brazil has authorization to use our control panel and he's always roaming down there, so his IP is always changing. But we are not block 10000 explicitly in the firewall/iptables.
Hmm, could you show the full output of "iptables -L -n"?
It sounds like you may be dealing with a firewall issue of some sort, seeing the full output would help with the troubleshooting of that.
-Eric
Full output below... but I changed nothing recently... other than to run yum updates. I will put a ticket into ServePath/GoGrid and see if they implemented anything farther out from our box...
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:20
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:21
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8333
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8444
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:25
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:25
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:21
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:21
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:587
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:587
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:10000
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:10000
ACCEPT tcp -- 75.109.138.39 0.0.0.0/0 tcp dpt:10000
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:20000
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:20000
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:5432
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:5432
ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:3306
ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:3306
ACCEPT tcp -- 174.59.203.162 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:30000
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:1:65535
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:1:65535
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Howdy,
Well, I can't speak to why your developer from Brazil is able to access the system... but I can offer that, according to the firewall rules you're using above, all access to Webmin/Virtualmin is being blocked, unless it's coming from one of three IP addresses.
There's fancy SSH tunnels and such that your developer could by using to bypass the firewalling you have there.
My recommendation would be to make sure there's a firewall rule on your system explicitly allowing your IP address.
Or, to allow all access to port 10000.
-Eric
OK, this makes sense now... we recently got a shiny brand new internet connection and I suspect the IP's changed for outgoing and our local net/LAN admin did not tell me.
so what is the proper way to edit the iptables by hand via terminal? Can I just VIM on some file and save it?
OK that was easy... I did a look up for our domain from outside, got the IP...
nano iptables,
changed it then ran
service iptables restart
and I'm in.
thanks!
Odd.. when I edited the table I see my comments right there:
for access from to webmin from our gateway:ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:10000
but when I did
iptables -L -n
it does not show comments..
Case closed....
Iptables itself does not retain those comments, they're only in the configuration script you've been editing.
That would explain it -- not that I really understand how "nano iptables" is not actually editing "iptables" unless the latter is some binary thing that is not actually exposed in /etc/sysconfig (just guessing)
Yeah I can't really tell how the nano command knew what file to edit. But what I know is that "nano" is a text editor, and "iptables" indeed is a binary (which you therefore cannot edit per se), which usually has a startup script to configure it.