Hi List,
is there any particular reason why x2goclient.exe will save session settings to the registry and will only use a "sessions" file when called with "--portable"? Using the "sessions" file is the default for Linux and AFAIK also for Mac OS X, so why the variation in x2goclient.exe?
IMO, using the sessions file by default simplifies handling across client operating systems (especially as there is no import/export option between the "sessions" file on Windows and the registry). That's why saving to the registry should be dropped if nobody uses it, or made optional ("--save-to-registry" or somehing like that) if there are a few users that need it.
So, to the Windows client users out there: Can anyone of you think of a reason that speaks against saving the settings in a file?
Until we have a decision on that, my workaround is a link with the following destination: X:\x2goclient.exe --portable --home=%USERPROFILE% (where X: is a read-only network drive, and %USERPROFILE% is a reserved variable on Windows that contains the path to the user's home directory) BTW, Alex will soon implement a change so that the sessions file can be stored on the read-only network drive as well.
-Stefan
So, to the Windows client users out there: Can anyone of you think of a reason that speaks against saving the settings in a file?
One possible reason would be the option to use Group Policy to distribute registry settings to users and predefine sessions for them.
However, I do not see any problems with using session files to do the same, in fact I would prefer it because of the portability (and transferability) of files vs registry settings. I haven't tried the --portable option in Windows, hopefully it allows you to start a session from the command line (or a shortcut) by specifying the session file. I used to do that with NoMachine and it worked like a charm.
Cheers, Daniel
Am 21.02.2012 16:14, schrieb Daniel Lindgren:
So, to the Windows client users out there: Can anyone of you think of a reason that speaks against saving the settings in a file? One possible reason would be the option to use Group Policy to distribute registry settings to users and predefine sessions for them.
However, I do not see any problems with using session files to do the same, in fact I would prefer it because of the portability (and transferability) of files vs registry settings.
AOL! Erm, I mean, "Me too".
I haven't tried the --portable option in Windows, hopefully it allows you to start a session from the command line (or a shortcut) by specifying the session file. That is independent of --portable, as far as I can tell from x2goclient.exe --help, so it *should* (IOW, I haven't tested it) be possible with settings saved in the registry as well: The parameter to do that is --session=<session>, where <session> is the ID-string of a session saved either in a sessions file or in the registry.
-Stefan
I haven't tried the --portable option in Windows, hopefully it allows you to start a session from the command line (or a shortcut) by specifying the session file.
That is independent of --portable, as far as I can tell from x2goclient.exe --help, so it *should* (IOW, I haven't tested it) be possible with settings saved in the registry as well: The parameter to do that is --session=<session>, where <session> is the ID-string of a session saved either in a sessions file or in the registry.
Yep, it does work with registry settings but you then specify the *name* of the session, that becomes impractical if you use files to store the session, you would have to parse through all session files to see which one contains the session you want to start. Not a problem if you have a few files stored locally, probably not ideal if you have a (slow) network folder with hundres of session files.
Using the name of the session file is a simpler approach, something like "x2goclient.exe --portable --home=<path> --session=<name of session file>". Might be confusing if the same parameter is used for registry and files, maybe they should be separate, i e "session=<registry>" and "sessionfile=<session file name>". That way the --portable switch becomes redundant, it's implied if you specify --home. If --home is specified and no --sessionfile you could let the user browse available sessions in the client.
Just my $0.02 ...
Cheers, Daniel
Am 21.02.2012 16:38, schrieb Daniel Lindgren:
I haven't tried the --portable option in Windows, hopefully it allows you to start a session from the command line (or a shortcut) by specifying the session file. That is independent of --portable, as far as I can tell from x2goclient.exe --help, so it *should* (IOW, I haven't tested it) be possible with settings saved in the registry as well: The parameter to do that is --session=<session>, where<session> is the ID-string of a session saved either in a sessions file or in the registry. Yep, it does work with registry settings but you then specify the *name* of the session, that becomes impractical if you use files to store the session, you would have to parse through all session files to see which one contains the session you want to start. Not a problem if you have a few files stored locally, probably not ideal if you have a (slow) network folder with hundres of session files. <snip>
Ah, sorry, I got that wrong: there is --session and --sessionid (this one gets used when you select the option to create a desktop shortcut from the drop-down menu)
IMO, there should be at most one "sessions" file per user.
-Stefan
IMO, there should be at most one "sessions" file per user.
OK, NoMachine uses one file per session, but x2goclient.exe will use one file for all the sessions? That would make it more difficult to have shared "corporate defautl" sessions together with user configurable sessions. If you'd need to update/add/remove default sessions you'd have to parse and edit the sessions file. If you have one file for each session, it's trivial to update/add/remove default session files without risking the user's personal sessions.
Either way, storing the session config(s) in files is preferable to storing it in the registry.
Cheers, Daniel
Am 21.02.2012 18:48, schrieb Daniel Lindgren:
IMO, there should be at most one "sessions" file per user. OK, NoMachine uses one file per session, but x2goclient.exe will use one file for all the sessions?
x2goclient (in all incarnations) currently uses exactly one "sessions" file per user. I guess that's why it's called "sessions" and not "session". ;-)
That would make it more difficult to have shared "corporate defautl" sessions together with user configurable sessions. If you'd need to update/add/remove default sessions you'd have to parse and edit the sessions file. If you have one file for each session, it's trivial to update/add/remove default session files without risking the user's personal sessions.
It will soon be possible to specify a different location for the sessions file that is outside the --home directory. Also, in about three weeks from now, it will be possible to provide a list of published applications directly on the server.
I have already forked over the first batch of €€€ to Alex for these feature requests.
-Stefan
Hi Stefan, hi Alex,
On Di 21 Feb 2012 18:56:50 CET "newsgroups.mail2@stefanbaur.de" wrote:
Am 21.02.2012 18:48, schrieb Daniel Lindgren:
[...]
It will soon be possible to specify a different location for the
sessions file that is outside the --home directory. Also, in about three weeks from now, it will be possible to provide
a list of published applications directly on the server.
@Alex: could we please discuss the communication protocol for this
application provider? I have already thought about this earlier and I
would love to come up with something that is freedesktop.org compliant
(i.e. that uses .desktop files and .destop categories).
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 21.02.2012 19:03, schrieb Mike Gabriel:
It will soon be possible to specify a different location for the sessions file that is outside the --home directory. Also, in about three weeks from now, it will be possible to provide a list of published applications directly on the server.
@Alex: could we please discuss the communication protocol for this application provider? I have already thought about this earlier and I would love to come up with something that is freedesktop.org compliant (i.e. that uses .desktop files and .destop categories).
.desktop files are what Alex is planning to use :-)
Hi Mike,
Am 21.02.2012 19:03, schrieb Mike Gabriel:
@Alex: could we please discuss the communication protocol for this application provider? I have already thought about this earlier and I would love to come up with something that is freedesktop.org compliant (i.e. that uses .desktop files and .destop categories).
The idea was based on .desktop files, but they should be placed/linked inside a special directory. The major idea of this is not to offer all installed application, but a selection.
As this is a ordered function, please discuss your ideas with Stefan.
Regards,
Heinz
Hello Stefan,
Am 21.02.2012 15:51, schrieb newsgroups.mail2@stefanbaur.de:
Hi List,
Using the "sessions" file is the default for Linux and AFAIK also for Mac OS X, so why the variation in x2goclient.exe?
The "registry db" is the official recommended place to store application settings on this platform.
This means that people (and applications) working with this system are looking for such information inside the registry - not an ini file.
As this option is already is introduced I think a second option can only be introduced as "optional".
Regards,
Heinz
Am 21.02.2012 22:09, schrieb Heinz-M. Graesing:
Hello Stefan,
Am 21.02.2012 15:51, schrieb newsgroups.mail2@stefanbaur.de:
Hi List,
Using the "sessions" file is the default for Linux and AFAIK also for Mac OS X, so why the variation in x2goclient.exe? The "registry db" is the official recommended place to store application settings on this platform.
This means that people (and applications) working with this system are looking for such information inside the registry - not an ini file.
There is no way to "preseed" a user profile, though, aside from some hacks using reg.exe and a login script, as everything gets written to HKEY_CURRENT_USER. You cannot set a domain- or machine-specific default/template (the User named ".Default" does not what one might think it does ;-)) . Also, once it is written to HKEY_CURRENT_USER, the user can change it at will, there is no way to set it to read-only (while there is --no-session-edit, there's nothing to stop the user from clicking on x2goclient.exe directly).
Then again, the problem should become moot in about three weeks time, when selectively publishing applications becomes available. ;-)
As this option is already is introduced I think a second option can only be introduced as "optional". Or, you could add an autosensing capability: If there's a sessions file present, pick that, if not, write to the registry. That way, copying a sessions file / touching an empty file in the default location would tell x2goclient that it should refrain from storing data in the registry.
-Stefan
On Tue, 2012-02-21 at 22:19 +0100, newsgroups.mail2@stefanbaur.de wrote:
Am 21.02.2012 22:09, schrieb Heinz-M. Graesing:
Hello Stefan,
Am 21.02.2012 15:51, schrieb newsgroups.mail2@stefanbaur.de:
Hi List,
Using the "sessions" file is the default for Linux and AFAIK also for Mac OS X, so why the variation in x2goclient.exe? The "registry db" is the official recommended place to store application settings on this platform.
This means that people (and applications) working with this system are looking for such information inside the registry - not an ini file.
There is no way to "preseed" a user profile, though, aside from some hacks using reg.exe and a login script, as everything gets written to HKEY_CURRENT_USER. You cannot set a domain- or machine-specific default/template (the User named ".Default" does not what one might think it does ;-)) . Also, once it is written to HKEY_CURRENT_USER, the user can change it at will, there is no way to set it to read-only (while there is --no-session-edit, there's nothing to stop the user from clicking on x2goclient.exe directly).
Then again, the problem should become moot in about three weeks time, when selectively publishing applications becomes available. ;-)
As this option is already is introduced I think a second option can only be introduced as "optional". Or, you could add an autosensing capability: If there's a sessions file present, pick that, if not, write to the registry. That way, copying a sessions file / touching an empty file in the default location would tell x2goclient that it should refrain from storing data in the registry. <snip> I'm a Windows ignoramus but is this something that could be set with a GPO? - John
I'm a Windows ignoramus but is this something that could be set with a GPO?
I'd like to use the "Ask the Audience" lifeline on that one... ;-)
If we're talking about setting registry settings via GPO the answer is yes, you can with Group Policy Preferences.
http://technet.microsoft.com/en-us/library/cc771589.aspx
Cheers, Daniel
-
Daniel Lindgren -
Heinz-M. Graesing -
John A. Sullivan III -
Mike Gabriel -
newsgroups.mail2＠stefanbaur.de