Comment 1 Peter Åstrand 2005-01-18 14:47:01 CET

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. 

Comment 2 Peter Åstrand 2005-02-10 09:50:54 CET

Another suggestion from Roke: Versatile Session Manager. 

Comment 3 Erik Forsberg 2005-02-10 10:00:59 CET

I still think Peters suggestion - "VSM Session Manager" is the best one so far :-).

Comment 4 Pierre Ossman 2012-01-23 13:30:40 CET

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.

Comment 5 Pierre Ossman 2013-08-13 15:23:45 CEST

Might also want to purge ctc references at the same time.

Comment 6 Karl Mikaelsson 2014-01-17 12:32:00 CET

If we're moving log files around, consider bug 4961.

Comment 7 Peter Åstrand 2015-08-25 09:37:41 CEST

A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some time.

Comment 8 Peter Åstrand 2016-01-18 14:15:00 CET

(In reply to comment #7)
> A "grep" for vsm in the ctc tree gives 1500 matches, so this might take some
> time.

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:

/var/log/master.log
/var/log/tlmaster.log
/var/log/tl-master.log
/var/log/thinlinc-master.log
/var/log/server.log
/var/log/tlserver.log
/var/log/tl-server.log
/var/log/thinlinc-server.log

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:

tlclient
tlsnd
tl-setup
thinlinc-login

/var/log/thinlinc-install.log
/var/log/tlclient.cgi.log
/var/log/tlsetup.log
/var/log/tlwebaccess.log
/var/log/tlwebadm.log

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:

/var/log/tlmaster.log

(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/ 
    vsm_server_port = 9000
    vsm_agent_port = 904

vsmagent/
    logging/
        logfile = /var/log/vsmagent.log
        levels/ 
            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.

Comment 9 Samuel Mannehed 2016-01-20 12:24:11 CET

I deem this sufficient to be a decision basis.

Comment 13 Peter Åstrand 2016-02-29 14:17:52 CET

> 
> 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
> change. 
> 
> 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.

Comment 14 Peter Åstrand 2016-02-29 14:20:40 CET

(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
> /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.

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.

Comment 27 Samuel Mannehed 2016-03-07 14:36:18 CET

See bug 5066, related

Comment 32 Samuel Mannehed 2016-03-16 16:24:17 CET

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.

Comment 33 Pierre Ossman 2016-03-21 13:41:04 CET

A suggestion for file structure in vsm/ can be found here:

http://git.cendio.se/cgit/~ossman/thinlinc.git/log/?h=restructure

And a suggestion for packaging everything as simply thinlinc-server can be found here:

http://git.cendio.se/cgit/~ossman/thinlinc.git/log/?h=packaging2

(solves what to do with the thinlinc-vsm rpm/deb)

Comment 34 Karl Mikaelsson 2016-10-07 16:26:54 CEST

*** Bug 60 has been marked as a duplicate of this bug. ***

Comment 36 Pierre Ossman 2018-10-08 10:55:47 CEST

Bug 5532 is probably interesting as part of this. It might also help with some of the /vsm config entries.

Comment 41 William Sjöblom 2024-08-07 15:32:31 CEST

The VSM references in the TAG has gotten a separate bug: bug 8407