Bug - DSM administrator account not able to make changes.

[dpuryear]

I've found that DSM will always default to the first domain in its list when trying to perform most administrative action other than adding an account or domain. Here is an example.

1. I log in as the DSM administrator (ADMINUSER in /etc/dsm.conf) or as root.
2. I click on Web.
3. I choose some website from the pull-down list, but make sure to not pick the first one.
4. DSM refreshes and displays "Basics Settings for Not-First-Website.com".
5. Under Virtual Host Aliases I click [change] for "/cgi-bin/ is aliased to"
6. DSM comes back with a text field for First-Website.com and now I have "Basic Settings for First-Website.com"

That is either broken behavior, or the DSM administrator account is useless. :)

Is there a fix for this bug? Or a work-around? I have tested this across machines and it is consistent and reproducible.

[LeeJ]

as stated in the support request ticket that you put in set the time on your machine (your server).

rdate -s clock.psu.edu
hwclock -w

Also submit suspected bugs to bugs@zervex.com posting possible bugs within the forum will not help you get a resolution.

[dpuryear]

I post to this forum anything that I think may affect others. That way they can easily and quickly find a resolution. Also, if I think someone else may have had this problem I figure I might as well post to the Q&A forum. Information sharing works great for this kind of stuff.

Anyway, our time is correct as we are using ntpd:

[root@www root]# ps -aux | grep ntp
ntp 840 0.0 0.1 1888 1884 ? SL Apr08 0:11 [ntpd]
root 25098 0.0 0.0 1484 464 pts/0 S 09:23 0:00 grep ntp
[root@www root]# date
Fri Apr 11 09:23:43 CDT 2003
[root@www root]# rdate -s clock.psu.edu
[root@www root]# date
Fri Apr 11 09:23:50 CDT 2003
[root@www root]# hwclock -w
[root@www root]# date
Fri Apr 11 09:23:56 CDT 2003

What is the expiration time you have on the cookies?

(I just replied to the ticket response as well. You don't have to reply here. I will post the resolution.)

[dpuryear]

This turned out NOT to be an issue necessarily with DSM. When logged in as a DSM administrator you have to ensure everyone has their browsers supporting cookies. We have these turned off as a standard policy because of privacy issues. In order to support DSM our solution is to manually allow cookies for the DSM sites by going to:

IE->Tools->Internet Options->Privacy->Edit.

We then add each site.

If your organization doesn't allow cookies you can use this method. Alternatively, you can set cookie acceptence to a manual method and pick and choose allowing cookies as you visit each site.

Thanks to support at Zervex for a quick resolution to this issue.