These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Changing webmin port on the new forum.
Hey Joe,
I'm trying to setup VMPro on a new server with CentOS 4.2 (4.4 after VM.sh upgrades it, yes Joe finally ;-) but you're never given the option for an alternate port ( as I don't use 10000). After the install and I go into webmin, I change the port and hit save then the server stalls instead of attempting to reload with the new port. Then it won't recognize either of the ports.
Is this just me??
The port you are wanting to use is free as well?
If the port is in use by another program it wont work. And I would manually restart webmin after the port change.
If you want to see what ports are in use try netstat -a -p
Yes, the port is free,]25000. This has been normal protocol for me until I've moved into CentOS 4.X . The only difference is that I installed CentOS with SELinux. Where do I find the file to manually go in and change it if needs be.
I reinstalled the whole thing again and checked ports and it's not in use, this is my standard port that I use as port 10000 is known as the default (20000 for usermin). Not that I don't trust anybody, just making another hoop for the bad guys to jump through.
I've reinstalled a couple times now and it doesn't matter what IP address I put in, if it's not 10000 it fails to return and can't be accessed by the port that's been assigned.
Hey Dan,
I dunno what to make of that. It runs fine for me on any port. I'm betting it's a firewall issue.
What show up in /var/webmin/miniserv.error when you try to start it on a different port?
And if you need to change ports from the command line, you can edit the port and listen directives in the /etc/webmin/miniserv.conf file and restart. I don't remember what each of those does, off-hand, but if you change them both you'll be fine. ;-)
--
Check out the forum guidelines!
Are there changes in the firewall setups between CentOS 3 and 4? I'm trying to do this right out of the box, if you will.
This has been pretty frustrating as the only way I've been able to fix it has been to to a clean OS install and reinstall VM as it won't go backward. Question, is the newest install.sh supposed to take so bloody long? It's hard to figure out except to run it and walk away by faith as it gives no real activity prompts. This AM it's been sitting at the " INIT: version 2.85 reloading" prompt for the last 3 1/2 hours but, there is faint HD activity so I assume somehing's still working. Is this supposed to be? Or are the license checks starting to take effect? Otherwise I'll get over there right away and upgrade to unlimited. To date I'm still playing on boxes, but this should be the real thing now to get a real working model of spamassassin.
Imagine that, the first time you could say spam did some good ;-)
thanks,
Dan
Er hmmm,
I'm wondering if it's taking so long because the server is out of the box @ 512meg RAM. I'm burning it in while I'm waiting for the memory to arrive.
this was odd, or just the newer CentOS. I got it to work by disabling the firewall on OS install. VM puts it's own iptables in during install anyway.
Is this one of the reasons that VM was generating it's own bootloader? I'd had a conflict because I just let the machine reboot and it kept failing due to logical volume errors, then I'd noticed the .sh had created it's own centOS cd boot as opposed to the centOS server cd boot.
Hey Dan,
Nope. We don't have anything to do with the bootloader. At all. We don't touch, don't look at it, don't care one whit about it. We don't come into the picture until after you have a running OS. So, if you have additional bootloader configuration files, we definitely didn't do it. ;-)
The firewall rules we add are only to allow things--not to block things, and so if you were only running our rules you wouldn't be blocking anything. You can use the Linux Firewall module to add deny rules, but the installation doesn't do it for you (and it would be impossible for us to accurately predict the right kind of firewall for your needs). The firewall configuration that happens during our install assumes that the OS configured firewall is running, and so we go through and open up the ports needed for hosting services, Webmin and Usermin. If you move Webmin, you'll need to open the port you move it to, as we only open 10000 during install. It's worth noting that we add this to the system firewall. When you shut down iptables, you shut down our rules, as well. They are not separate.
So, the firewall is the source of your trouble. Opening up a port is easy. On Red Hat based systems, you'd do this to open 10001:
iptables -I INPUT -p tcp --dport 10001 -j ACCEPT
service iptables save
Or on others you could save the rules with:
iptables-save
This won't work on SUSE because they've made up their own very limited save file format...you have to use YaST to add new rules.
--
Check out the forum guidelines!
Thanks for the update Joe. THat's why I'm going through all this before I move to the real deal. I had run the IPtables script after the fact but didn't realize there's no blocking. So what I really want to do is install that firewall, then BEFORE changing the port add an allow rule, then change the port in the webmin/usermin config?
Oh also, I used my original VMPro install.sh and it flew through with staus, making the whole install in just over an hour. ;-)