jack strenkowski

I am running the cluster master on RHEL 6 Linux 2.6.32-754.23.1.el6.x86_64 on x86_64 the cluster clients are a mix of version 6 (same as cluster version) and version 7 Linux 3.10.0-957.el7.x86_64 on x86_64. Yes, All our webmin instances are running 1.941. we made this upgrade about 2 weeks ago. Be glad to turn on a debug switch to capture some data with respect to updating user data. At the time of the failure the change was to perform a passwd reset for one user and update group membership for several...

Somehow i stumbled onto the network config page and determined that the hostname is set manually. Appears webmin uses the hostname entry to perform the lookup based on the resolution order. I suppose that this field is populated during webmin install just seems odd that it would have found the vmware hostID vs the system hostID. It did take a while for the DNS entries to show up once the build was completed. I also found the setting for document title page and changed that to show hostname first......

How can i determine where the sysinfo page is collecting the host name for display? several new installations are showing the hostname used as a result of the original build. YET the hostname was updated on the system and changed prior to the webmin install, Yet, it still insists on reporting the old name.

I seem to have a problem getting email entries to 55378@discussion.webadmin.p.re.sourceforge.net or even replies to other trouble discussions to post to the system. is there something missing in my account settings to allow updates via email?

When attempting to update user passwds on specific server group webmin reports the updates are successful. But the resulting passwd and group entries are corrupting the file. The user name becomes user^@user and this happens within all 3 files passwd, shadow, and group membership. Furthermore, when this entry affects the wheel group. Sudo fails for all users. The only fix is to use webmin to copy in a replacement group file (ie backup). Has anyone else experienced this behavior? It started with the...

Anyone experience http-monitor failures when attempting to communicate with IIS applications when the SNI (system name identification) setting is active? we have several instances of webmin V 1.89 and 1.92 running on Redhat centos 6 that all fail to read the cert info when the SNI is on. However, I have 1 CentOS 7 running webmin 1.90 that has no problem with communicating with our IIS systems regardless of the SNI setting. This seems very strange. Also, when I run openssl with SNI on I always get...

Jamie - i found a sample Net:SSLeay script and was able to verify exactly what webmin was getting. It seems to immediately recognize that a user / passwd is required and given those fields are empty it returns the not authorized 401 code. Webmine http-monitor is not programmed to treat the 401 return as an UP status so in the end i added it to our script. Checking for the login screen is exactly what we want. Will keep an eye on this URL to see if it shows any offline activity. Perhaps an option...

In our case the status is 401 unauthorized probably because the the login screen is not getting satisfied. However, it would be nice to see more efficience of the full conversation. In this case a unauthorized does tell us that the websight responded vs say the 404 not available. So should the 401 return code be included in the "good return list" currently it is not. Also, when i run the same url through curl and a perl script using HTTP:tiny or LWP:Simple functions the return is complaining about...