"VNC Session Manager" is not perhaps a very good name, since VSM does more than
keeps track of VNC. Perhaps VSM should be renamed to "ThinLinc Session Manager":
TSM or TLSM.
Another idea from Roke and Daniel is that we keep VSM, but change the meaning of
the V: It could mean "Virtual" or something like that, instead of VNC.
Another suggestion from Roke: Versatile Session Manager.
I still think Peters suggestion - "VSM Session Manager" is the best one so far :-).
These days we've started using the terminology master/agent. We should get rid of all the vsm references in favour of these as the old naming is just confusing to new users.
The term "server" might be allowed in certain end-user places as that is the term they expect when comparing with similar products. The master/agent distinction is something only the administrators should have to know about.
Might also want to purge ctc references at the same time.
If we're moving log files around, consider bug 4961.
A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some time.
(In reply to comment #7)
> A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some
A new search gives 1243 matches, after filtering out things such as the auto tests.
There are several challenges to solve this bug:
1) Decide on new names. The general idea of replacing "VSM Server" with "Master" and "VSM Agent" with "Agent" is probably good. But as always, the devil is in the details. If you consider, for example, /var/log/vsmserver.log, there are many possible alternativs:
master.log and server.log are poor names, though, but there are still many options. In general, we need to select between "master" and "server", multiplied with the prefixes "tl", "tl-", and "thinlinc". We are not consistent:
IMHO, I think we should avoid the "thinlinc-" prefix, since that's the least used variant. Selecting between "tl" and "tl-" is more difficult since "tl" is the most common log file prefix, while "tl-" is more common for binaries etc. The web administration service is called "tlwebadm", and has a matching log file, but the setup program is called "tl-setup" and the log file is called "tlsetup.log". But since it's probably not a good idea to have a dash in a service name, and to follow the earlier services, I think we should go for:
(Still thinks we should rename tlsetup.log to tl-setup.log though.)
As comment #6 says, we could consider bug 4961. IMHO, this should not affect the file names though.
2) Should we only change all user/admin visible parts, or even internal things such as variable names? I think we should change even internal things,
to avoid confusion and also make it easier to search for missed "vsm" strings.
3) Configuration issues. On the positive side, "vsm" is only used in a few places in the configuration name space:
vsm_server_port = 9000
vsm_agent_port = 904
logfile = /var/log/vsmagent.log
vsmagent.extcmd = INFO
vsmagent.xmlrpc = INFO
vsmagent.session = INFO
(plus corresponding stuff for vsmserver)
One problem is the /vsm folder, which is common for both the master and agent. There's no obvious new name for this folder. Perhaps "tl"? From a machine wide Hiveconf perspective, we would get a folder called /thinlinc/tl, but that's no big issue. "tl" would match "tlmaster" and "tlagent" service names. Another idea would be "server". That would better match the package name suggestion (see below).
Then we also have "vsm" in the configuration file names. Even if there are only a handful places, the fact that the service "top" folders have "vsm" in the name means that all VSM configuration parameters are possibly affected by a name change. Our options are:
1) Do nothing - keep the old names. But that is no "solution" according to this bug description
2) Rename. No special handling - let the administrators deal with the name change.
3) Rename. Introduce code that helps with the name changes.
For the latter approach, we could in principle automatically rename .rpmsave files into their new name, and also replace "vsm" strings in them. This could be done before the new config migrate dialog, to make sure all 3 options in that dialog works. But the question is, should we do this kind of replacement, and should it be automatic and silent?
4) Package name. We have a package called "thinlinc-vsm". If it should contain both services, we again need to find a new "common" word for the master and the agent. One idea is "thinlinc-server".
To summarize: My conclusion is that getting rid of "vsm" is not easy or simple, but possible.
I deem this sufficient to be a decision basis.
> 3) Configuration issues. On the positive side, "vsm" is only used in a few
> places in the configuration name space:
> Even if there are only
> a handful places, the fact that the service "top" folders have "vsm" in the
> name means that all VSM configuration parameters are possibly affected by a
> name change. Our options are:
> 1) Do nothing - keep the old names. But that is no "solution" according to this
> bug description
> 2) Rename. No special handling - let the administrators deal with the name
> 3) Rename. Introduce code that helps with the name changes.
Note that for option 3), there are multiple solutions:
3a) Replace strings in our config files. This could be easily done in the config migrate step in tl-setup, since we only need to do this for "conflicting files"; only if the admin has actually done some changes that needs to be preserved. I have a patch that is ~60 lines that does this. The drawback is that we are not processing custom config files, such as "alocal.hconf" or /usr/share/example.com/global.hconf.
3b) Extend the Hiveconf API with a "rename" operation. This would allow us to change the names in other config files as well. Note that this will still not be a 100% solution, since it's possible to have hconf files which "masks" parameters in other hconf files (say, local.hconf overriding /usr/share/example.com/global.hconf). Besides, /usr/share/example.com/global.hconf could be on a read-only file system.
(In reply to comment #13)
> 3a) Replace strings in our config files. This could be easily done in the
> config migrate step in tl-setup, since we only need to do this for "conflicting
> files"; only if the admin has actually done some changes that needs to be
> preserved. I have a patch that is ~60 lines that does this. The drawback is
> that we are not processing custom config files, such as "alocal.hconf" or
> 3b) Extend the Hiveconf API with a "rename" operation. This would allow us to
> change the names in other config files as well. Note that this will still not
> be a 100% solution, since it's possible to have hconf files which "masks"
> parameters in other hconf files (say, local.hconf overriding
> /usr/share/example.com/global.hconf). Besides,
> /usr/share/example.com/global.hconf could be on a read-only file system.
An additional solution would be to basically use 3a), but do the search-and-replace in all files in /opt/thinlinc/etc/conf.d. With the examples above, this would correctly
handle "alocal.hconf" but not /usr/share/example.com/global.hconf.
See bug 5066, related
We have to remember to double check documentation images. We suspect that some PNG files have been edited directly instead of using the .dia-files.
A suggestion for file structure in vsm/ can be found here:
And a suggestion for packaging everything as simply thinlinc-server can be found here:
(solves what to do with the thinlinc-vsm rpm/deb)
*** Bug 60 has been marked as a duplicate of this bug. ***
Bug 5532 is probably interesting as part of this. It might also help with some of the /vsm config entries.