[opensuse] Disabling updater applet
Hi, how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway? Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi,
how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway?
Christoph
Right click on applet, configure applet, you can disable it there. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 11:00 -0400, ka1ifq wrote:
how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway?
Christoph
Right click on applet, configure applet, you can disable it there.
AFAIK, that does not work for all users and all desktops. All of them would have to do the change themselves. I would think of changing the ownership of the daemon: - -rwxr-xr-x 1 root root 287448 2010-04-23 02:38 /usr/sbin/packagekitd* Remove the allow execute for all, perhaps. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky0jlkACgkQtTMYHG2NR9XuYACeLrwH68vvMdXogIuNe2QIoYsL g/MAoImr39JrF+cM5mzBhlZb5oxeXTKm =iF4r -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 12 October 2010 14:31:10 Christoph Bartoschek wrote:
how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway?
Generally, review the Autostart spec: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html Identify the applet's autostart desktop file (rpm -ql the applet's package) and hide it. In concrete steps, for the KDE update applet: Add Hidden=true to /etc/xdg/autostart/kupdateapplet-autostart.desktop HTH Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 12 October 2010 06:46:51 am Will Stephenson wrote:
On Tuesday 12 October 2010 14:31:10 Christoph Bartoschek wrote:
how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway?
Generally, review the Autostart spec:
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
Identify the applet's autostart desktop file (rpm -ql the applet's package) and hide it.
In concrete steps, for the KDE update applet:
Add Hidden=true to
/etc/xdg/autostart/kupdateapplet-autostart.desktop
HTH
Will
-- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex
Will, not trying to start a war or anything, but, this is a typical little crappy issue that aggravates too many of us with ...ok, i will say it...kde4, if kde4 is the cause, or with the new versions of shtuff in general, if kde4 is not the cause. WHY is something as basic as this so contorted and so difficult to accomplish? And, the really maddening shtuff, WHY is the apparent straightforward process still allowed to proceed without error messages, thus giving one the false security that the task has actually been accomplished? at the absolute very minimum, let the default be such that only if one changes it and then tries to change it back the issue arises. sometimes even when things are not right, simple common sense can still avoid problems. all, please do *not* build on this another kde4 basher thread. all i tried to do is point something that is too general for a bug report, yet it needs fixing asap. d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/12/2010 11:41 AM, kanenas@hawaii.rr.com wrote:
WHY is something as basic as this so contorted and so difficult to accomplish? And, the really maddening shtuff, WHY is the apparent straightforward process still allowed to proceed without error messages, thus giving one the false security that the task has actually been accomplished? at the absolute very minimum, let the default be such that only if one changes it and then tries to change it back the issue arises. sometimes even when things are not right, simple common sense can still avoid problems. all, please do *not* build on this another kde4 basher thread. all i tried to do is point something that is too general for a bug report, yet it needs fixing asap. d.
Well first, I think there are two problems here. One is lack of documentation. Two is the installation of tools like this by default on accounts that can't use them. I don't think this second bit is entirely a KDE4 issue. But consider that Opensuse (and kde in general) has no way of knowing which users are to be eligible to use these tools, and at what level (Notify only, silent install, or download but don't install). There is no why to know in advance which users have roots password tucked away in their head. The vast majority of linux installs have exactly ONE user anyway. Ubuntu assumes the first user account should be added to the sudoers list to manage the machine. (This can be over-ridden, and many argue that the assumption is a trap for the unwary, but there it is anyway). Unless or Until OpenSuse embraces sudo as the normal way of doing system tasks and integrates this into the normal installation and requires that each new user added to the system is explicitly added to the sudo list, there doesn't seem to be an easy way out. In the absence of consistent use of the sudo, and sudoers, there is no way for KDE to know which users should or should not be allowed to run updater or file manager super user mode, or konsole super users mode. So I don't think you can blame KDE entirely when it has no method of determining which passwords a user might hold. You might want to suggest a multi-user install option with some mechanism for KDE to hook into when start up options and menus are constructed. Perhaps management of this type of install could be better integrated into yast. -- _____________________________________ At one time I had a Real Sig. Its been downsized. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Well first, I think there are two problems here.
One is lack of documentation.
That's a general problem.
Two is the installation of tools like this by default on accounts that can't use them.
Yes.
I don't think this second bit is entirely a KDE4 issue.
No, it is not. Gnome has the same problem.
But consider that Opensuse (and kde in general) has no way of knowing which users are to be eligible to use these tools, and at what level (Notify only, silent install, or download but don't install). There is no why to know in advance which users have roots password tucked away in their head.
It is very simple, in fact: just list them in a file. A variable in a file in /etc/sysconfig/updatenotifier.
Unless or Until OpenSuse embraces sudo as the normal way of doing system
No, I disagree. I hope openSUSE never embraces sudo as the normal way of doing things. And it is not needed for this at all. There are several methods. One, is change the permissions of the applet or the underlying daemon, so that a normal user, unless he belongs to a certain group, can not run it. Another is listing in a file which users can use some special tools. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky04CIACgkQtTMYHG2NR9V59gCeJp1wwSs100ngef6sw/KZSsmO y8gAni1Km59GfqDKF7ziNZuOS6pJiS3v =QIYh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/12/2010 3:24 PM, Carlos E. R. wrote:
Content-ID:
There are several methods. One, is change the permissions of the applet or the underlying daemon, so that a normal user, unless he belongs to a certain group, can not run it. Another is listing in a file which users can use some special tools.
Seriously Carlos? You want someone to create yet another nonstandard file to list people? There are standards for this already, some followed, some not. Wasn't that what the Wheel group was for? Isn't that what sudoers was for? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 16:14 -0700, John Andersen wrote:
On 10/12/2010 3:24 PM, Carlos E. R. wrote:
There are several methods. One, is change the permissions of the applet or the underlying daemon, so that a normal user, unless he belongs to a certain group, can not run it. Another is listing in a file which users can use some special tools.
Seriously Carlos?
Yes, seriously.
You want someone to create yet another nonstandard file to list people?
Why not? We are only talking of PackageKit, not of any standard.
There are standards for this already, some followed, some not. Wasn't that what the Wheel group was for?
That's what I'm using >:-)
Isn't that what sudoers was for?
Sudoers is not configured in default opensuse system, it would be impossible to start now, just for one program, by the distro. It is up to you, the admin, to do it. Say, how would you configure sudoers to make the updater applet not appear? Which is the main question here. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky08cQACgkQtTMYHG2NR9WDlACgifNsk0BXQuvr3kvrx+JWq6vg qjcAnA+oLFFGCTwo6lpMOJQMHdEott54 =sRxh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/12/2010 4:39 PM, Carlos E. R. wrote:
Say, how would you configure sudoers to make the updater applet not appear? Which is the main question here.
I would have updater check if user is in the list, and exit immediately of not. But I'm sure it could be made more complex and obtuse than that. ;-) -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 20:05 -0700, John Andersen wrote:
On 10/12/2010 4:39 PM, Carlos E. R. wrote:
Say, how would you configure sudoers to make the updater applet not appear? Which is the main question here.
I would have updater check if user is in the list, and exit immediately of not. But I'm sure it could be made more complex and obtuse than that. ;-)
I know that. But that does not solve the OP problem: he is an admin, not a dev. He can not rewrite the updater. And even for a future version of the distro, that would need a complete generation of the sudoers file, a change of policy... on which I do not agree. This is not ubuntu, and I like our ways. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky1JvoACgkQtTMYHG2NR9XPXQCgj5r74kByU7V7zT4BiyZKKGdY /zgAnjkCtilFrt2pEj7WVi3YNMBajoJr =g271 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am 12.10.2010 18:46, schrieb Will Stephenson:
On Tuesday 12 October 2010 14:31:10 Christoph Bartoschek wrote:
how can I disable the updater applet for all users of the system. They are not allowed to install packages anyway?
Generally, review the Autostart spec:
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
Identify the applet's autostart desktop file (rpm -ql the applet's package) and hide it.
In concrete steps, for the KDE update applet:
Add Hidden=true to
/etc/xdg/autostart/kupdateapplet-autostart.desktop
Thanks for the information. It seems as if Packagekit is responsible for the messages. Would it be sufficient and recommended to deinstall all packages related to Packagekit? Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2010-10-12 at 23:42 +0200, Christoph Bartoschek wrote:
Am 12.10.2010 18:46, schrieb Will Stephenson:
Thanks for the information.
It seems as if Packagekit is responsible for the messages. Would it be sufficient and recommended to deinstall all packages related to Packagekit?
That would be: rpm --erase PackageKit libpackagekit-glib12 kupdateapplet-packagekit gnome-packagekit kupdateapplet I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky04w0ACgkQtTMYHG2NR9UQDgCfe2eyDEsTO9biKOSaHY6e6IL8 SpIAnjnZfO6qcRRQvQlUjFJfNxlYHwl5 =jDC+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages. This can easily disrupt the work of other users. Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 00:48 +0200, Christoph Bartoschek wrote:
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
Who said anything about giving permission? I did not. I removed permissions. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky06joACgkQtTMYHG2NR9UwnQCdGF88zyKChW145UfmxYyBzyGZ 9uwAmwXT2pPNzRYVpx3jdyJfm+4KeE4j =qHQG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am 13.10.2010 01:07, schrieb Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2010-10-13 at 00:48 +0200, Christoph Bartoschek wrote:
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
Who said anything about giving permission? I did not. I removed permissions.
Sorry. I misunderstood your post. Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 10/12/2010 03:48 PM, Christoph Bartoschek wrote:
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
This can easily disrupt the work of other users.
Christoph
How is anyone going to install anything without root permission? Steven -- Sent from my Linux box. Regards de KC6KGE. A very happy Flex-3000 user. Skype flamebait Gmail flamebait at gmail dot com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Steven L Hess said the following on 10/12/2010 07:25 PM:
On 10/12/2010 03:48 PM, Christoph Bartoschek wrote:
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
This can easily disrupt the work of other users.
Christoph
How is anyone going to install anything without root permission?
Obviously not. The question you _SHOULD_ be asking is how to restrict access to root, yet grant it in limited circumstances. Which is what SUDO and PAM are about. See pam_sepermit(8) pam_wheel(8) pam_listfile(8) Oh, and the concept of the "wheel group". Oh, and judicious use of group permission and setuid :-) -- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 12 October 2010 01:49:27 pm Anton Aylward wrote:
Steven L Hess said the following on 10/12/2010 07:25 PM:
On 10/12/2010 03:48 PM, Christoph Bartoschek wrote:
Am 13.10.2010 00:37, schrieb Carlos E. R.:
I think it is better to just change the daemon permissions; I have done that, but it's early to know if it works, but we'll see.
I do not want to give any user the permission to install packages.
This can easily disrupt the work of other users.
Christoph
How is anyone going to install anything without root permission?
Obviously not.
The question you _SHOULD_ be asking is how to restrict access to root, yet grant it in limited circumstances.
Which is what SUDO and PAM are about. See pam_sepermit(8) pam_wheel(8) pam_listfile(8)
Oh, and the concept of the "wheel group".
Oh, and judicious use of group permission and setuid :-)
-- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
Forest... trees...forest...trees... this is getting off track. of course, only root should be by default allowed to update. The issue is control of *automatic* updates. ideally, root should be able to fully control that, to the point of allowing even a regular user to do one. can't there be a *simple* and easily verified method for that? d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 08:45 -1000, kanenas@hawaii.rr.com wrote:
Forest... trees...forest...trees... this is getting off track. of course, only root should be by default allowed to update. The issue is control of *automatic* updates. ideally, root should be able to fully control that, to the point of allowing even a regular user to do one. can't there be a *simple* and easily verified method for that?
You are asking something different from the original question, which was simply make the updater applet not appear for plain users. (Changing the permissions of "/usr/sbin/packagekitd" does not work - I tried.) Now you are asking something different, which is allowing some users to update. Now, notice that any of the updates procedures will ask for the root password before actually doing any update - so the answer to your question, at present, is that only those users that know that password can run updates. Otherwise, in order to allow some users without giving them the root password, you have to configure sudoers, and tell the users to run the updaters with sudo - which is not what the applet does, at present. They have to call YOU via sudo, which has to be configured differently than the default suse config. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky2ArsACgkQtTMYHG2NR9UIngCePRJSA+9ZykZjoR4aDb2ks+zH CbsAn0u0J8n5JcrAAaYn70Ryz0As1cMV =8Zev -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday, 2010-10-13 at 08:45 -1000, kanenas@hawaii.rr.com wrote:
Forest... trees...forest...trees... this is getting off track. of course, only root should be by default allowed to update. The issue is control of *automatic* updates. ideally, root should be able to fully control that, to the point of allowing even a regular user to do one. can't there be a *simple* and easily verified method for that? You are asking something different from the original question, which was simply make the updater applet not appear for plain users.
(Changing the permissions of "/usr/sbin/packagekitd" does not work - I tried.)
Now you are asking something different, which is allowing some users to update.
Now, notice that any of the updates procedures will ask for the root password before actually doing any update - so the answer to your question, at present, is that only those users that know that password can run updates.
Otherwise, in order to allow some users without giving them the root password, you have to configure sudoers, and tell the users to run the updaters with sudo - which is not what the applet does, at present. They have to call YOU via sudo, which has to be configured differently than the default suse config.
- -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) Actually, this is what PolicyKit was written for - to enable administrators to delegate specific tasks to users without giving them root/sudo privs. Look at the PolicyKit configuration (KDE SC4 System Settings has a module for it) and see if you can configure it correctly (I'm not sure of the correct incantation for this, but it is definitely
On 13/10/10 20:04, Carlos E. R. wrote: possible since that's the whole point of it) such that certain users have full PackageKit permissions. Then, when the update applet wants to update, if you are a sufficiently privileged user, it should only ask for the user password and then just work. Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 20:26 +0100, Tejas Guruswamy wrote:
Actually, this is what PolicyKit was written for - to enable administrators to delegate specific tasks to users without giving them root/sudo privs. Look at the PolicyKit configuration (KDE SC4 System Settings has a module for it)
I'm using gnome, so I can't. Any YAST module?
and see if you can configure it correctly (I'm not sure of the correct incantation for this, but it is definitely possible since that's the whole point of it) such that certain users have full PackageKit permissions. Then, when the update applet wants to update, if you are a sufficiently privileged user, it should only ask for the user password and then just work.
The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question. The polkit config is this: # package kit # org.freedesktop.packagekit.package-install auth_admin_keep_always org.freedesktop.packagekit.package-install-untrusted auth_admin org.freedesktop.packagekit.system-trust-signing-key auth_admin org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.package-remove auth_admin_keep_always org.freedesktop.packagekit.system-update auth_admin_keep_always org.freedesktop.packagekit.system-rollback auth_admin_keep_always org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep And no idea what it means. Where is this all documented - for opensuse? - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky2GFQACgkQtTMYHG2NR9WhdgCfQO323f5Rg14Tsai60X68rq2P KsUAoI555k+keT0Pvu9GqJZvVew49ZYt =84l0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-10-13 Carlos offered the following: <snip>
The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question.
<snip>
Wouldn't it be just as easy to ask the devs to modify the applet so that it won't
run
for anyone that isn't 1) UID=0 or 2) GID = a)root b)wheel c)trusted
d)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2010-10-13 at 19:47 -0400, Richard Creighton wrote:
On 2010-10-13 Carlos offered the following:
<snip>
The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question.
<snip>
Wouldn't it be just as easy to ask the devs to modify the applet so that it won't run for anyone that isn't 1) UID=0 or 2) GID = a)root b)wheel c)trusted d)
??? and identified in the config file for the updater or by the dev kinda like the vboxuser has to be set in order to run virtual box....????
Obviously. But that will take years... and we'd like a temporary solution while they do. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky2R1AACgkQtTMYHG2NR9XN/wCeLw1Nyp7xwcvEU4QqpO4qcyWT gTIAnRKNYg//7gQI2jzU9B+P2EFkNNyD =pvAf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-10-13 Carlos offered the following:
On Wednesday, 2010-10-13 at 19:47 -0400, Richard Creighton wrote:
On 2010-10-13 Carlos offered the following:
<snip>
The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question.
<snip>
Wouldn't it be just as easy to ask the devs to modify the applet so that it won't run for anyone that isn't 1) UID=0 or 2) GID = a)root b)wheel c)trusted d)
??? and identified in the config file for the updater or by the dev kinda like the vboxuser has to be set in order to run virtual box....???? Obviously. But that will take years... and we'd like a temporary solution while they do.
I would then submit that until that time that a SCRIPT could be written and put in the login script or autostart scripts that stop/purge such programs according to the UID/GID per above pending the program(s) doing it as it should. eg, a workaround. I'm pretty sure that KDE and Gnome and probably the others have 'autostart' or startup scripts/programs that run when a user first logs in that could test the list of programs it is attempting to startup and proactively skip/kill/ignore the ones not matching the UID/GID requirements. Then, IF the root operator gives that user extended privileges by making them members of the 'correct' group(s), then the associated program(s) can run, ala vbox, updater, etc. Richard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Oct 13, 2010 at 07:47:45PM -0400, Richard Creighton wrote:
On 2010-10-13 Carlos offered the following:
<snip>
The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question.
<snip>
Wouldn't it be just as easy to ask the devs to modify the applet so that it won't run for anyone that isn't 1) UID=0 or 2) GID = a)root b)wheel c)trusted d)
??? and identified in the config file for the updater or by the dev kinda like the vboxuser has to be set in order to run virtual box....???? Then, there doesn't have to be any "list" and the root operator can select any user to be 'special' and allowed to have installs delegated to him/her.
The permission handling between the updater applet and the PackageKit daemon is actually done via PolicyKit. You can adjust its rules if necessary. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-10-14 at 08:49 +0200, Marcus Meissner wrote:
The permission handling between the updater applet and the PackageKit daemon is actually done via PolicyKit. You can adjust its rules if necessary.
Documented where? It looks like chinese to me. I did: Telcontar:~ # chmod o-x,g-x /usr/sbin/packagekitd Telcontar:~ # l /usr/sbin/packagekitd - -rwxr--r-- 1 root root 287448 Apr 23 02:38 /usr/sbin/packagekitd* But it is still running, and as the root user. You say that the control is this: # package kit # org.freedesktop.packagekit.package-install auth_admin_keep_always org.freedesktop.packagekit.package-install-untrusted auth_admin org.freedesktop.packagekit.system-trust-signing-key auth_admin org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.package-remove auth_admin_keep_always org.freedesktop.packagekit.system-update auth_admin_keep_always org.freedesktop.packagekit.system-rollback auth_admin_keep_always org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep # How does this work? The names look arbitrary to me, no guessing what they do, no guessing what names are available. I don't see there how to deny a user to run the daemon and learn there are updates. That's chinese to me. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky24k8ACgkQtTMYHG2NR9XNXQCfRQPtg6OID3h2hUFKFOOsPvlJ 9AgAn3WFblknxjI9/sXdAZIGhCibrUGI =JqgV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, Oct 14, 2010 at 12:58:13PM +0200, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 08:49 +0200, Marcus Meissner wrote:
The permission handling between the updater applet and the PackageKit daemon is actually done via PolicyKit. You can adjust its rules if necessary.
Documented where? It looks like chinese to me.
I did:
Telcontar:~ # chmod o-x,g-x /usr/sbin/packagekitd Telcontar:~ # l /usr/sbin/packagekitd -rwxr--r-- 1 root root 287448 Apr 23 02:38 /usr/sbin/packagekitd*
But it is still running, and as the root user.
Well, it is started as "root", so you need to remove its root access permissions if you never want to run packagekit at all.
You say that the control is this:
# package kit # org.freedesktop.packagekit.package-install auth_admin_keep_always org.freedesktop.packagekit.package-install-untrusted auth_admin org.freedesktop.packagekit.system-trust-signing-key auth_admin org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.package-remove auth_admin_keep_always org.freedesktop.packagekit.system-update auth_admin_keep_always org.freedesktop.packagekit.system-rollback auth_admin_keep_always org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep #
How does this work? The names look arbitrary to me, no guessing what they do, no guessing what names are available. I don't see there how to deny a user to run the daemon and learn there are updates.
That's chinese to me.
auth_admin will ask for admin privileges. auth_admin_keep_always will keep it after you have netered them once. Having all lines with "no" at the end will probably disable them, like: org.freedesktop.packagekit.package-install no CIao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2010-10-24 at 22:54 +0200, Marcus Meissner wrote:
On Thu, Oct 14, 2010 at 12:58:13PM +0200, Carlos E. R. wrote:
-rwxr--r-- 1 root root 287448 Apr 23 02:38 /usr/sbin/packagekitd*
But it is still running, and as the root user.
Well, it is started as "root", so you need to remove its root access permissions if you never want to run packagekit at all.
I'm logged as user, so if it runs as root it means that another process which is running as root (not me), or SUID, is calling it.
You say that the control is this:
# package kit # org.freedesktop.packagekit.package-install auth_admin_keep_always org.freedesktop.packagekit.package-install-untrusted auth_admin org.freedesktop.packagekit.system-trust-signing-key auth_admin org.freedesktop.packagekit.package-eula-accept auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.package-remove auth_admin_keep_always org.freedesktop.packagekit.system-update auth_admin_keep_always org.freedesktop.packagekit.system-rollback auth_admin_keep_always org.freedesktop.packagekit.system-sources-configure auth_admin_keep_always org.freedesktop.packagekit.system-sources-refresh auth_admin_keep_always:auth_admin_keep_always:yes org.freedesktop.packagekit.system-network-proxy-configure auth_admin_keep_always org.freedesktop.packagekit.cancel-foreign auth_admin:auth_admin:auth_admin_keep #
How does this work? The names look arbitrary to me, no guessing what they do, no guessing what names are available. I don't see there how to deny a user to run the daemon and learn there are updates.
That's chinese to me.
auth_admin will ask for admin privileges. auth_admin_keep_always will keep it after you have netered them once.
I see.
Having all lines with "no" at the end will probably disable them, like: org.freedesktop.packagekit.package-install no
But which is the process that searches for updates in the first place? That's the one that should not run, that's the one we need to remove - and I don't see it there. This is a process that never asks for permissions. It runs and tells the users that there are updates. Only the user that also is the admin should be informed. An example. I log as me normal user in Gnome. After a while, I'm automatically informed that there are some updates, and I choose to not install for the moment (close window). Then I choose to also log in on another graphical user, another user, in gnome or kde. And this user is also informed that there are updates! This is absurd. In this case it is the same person, but it could be guest, a child, an employee... whoever. Only those users that do maintenance of the machine should have the applet running that checks for updates, and there is no known method to control this. I tried using permissions on packagekid, but no success. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAkzEuJsACgkQtTMYHG2NR9WYDgCdEcOU+Sndfx/L34jqs+J2YlgL GWwAnRGxlhZnArwGCB+hxDubG4Pfo5kV =c86z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday, 2010-10-13 at 20:26 +0100, Tejas Guruswamy wrote:
Actually, this is what PolicyKit was written for - to enable administrators to delegate specific tasks to users without giving them root/sudo privs. Look at the PolicyKit configuration (KDE SC4 System Settings has a module for it) I'm using gnome, so I can't. Any YAST module? Dunno. and see if you can configure it correctly (I'm not sure of the correct incantation for this, but it is definitely possible since that's the whole point of it) such that certain users have full PackageKit permissions. Then, when the update applet wants to update, if you are a sufficiently privileged user, it should only ask for the user password and then just work. The question remains, how to impede the applet that tells there are updates pending to not even start. THAT's the main question. Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially
On 13/10/10 21:36, Carlos E. R. wrote: the X-KDE- bits. To enable for only specific users: 1 - remove that file entirely (though this will get overwritten by kupdateapplet package updates) and copy it back into ~/.config/autostart for only the desired users -- or -- 2 - Add a file in /etc/kde4/share/config/kupdateappletrc with the contents: [General] Autostart=false then modify ~/.kde4/share/config/kupdateappletrc to have "Autostart=true" for only the desired users or, if you want to disable for only specific users In the user's ~/.kde4/share/config/kupdateappletrc, add a key "Autostart=false" to the "[General]" section as above. which BTW is the same behaviour as clicking "Configure Applet" in the kupdateapplet right-click menu and unticking "Automatically start updater on login". Easy! Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-10-14 at 11:16 +0100, Tejas Guruswamy wrote:
Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially the X-KDE- bits.
That doesn't work for all desktops.
and copy it back into ~/.config/autostart for only the desired users
I don't have it there and it runs. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky245EACgkQtTMYHG2NR9UOggCfVLUfrqFjPZsA4IJbkfGIiQPc ChYAn1ExENSky3KFNAJo/QzlPqOn4kaJ =uA55 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 14/10/10 12:03, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 11:16 +0100, Tejas Guruswamy wrote:
Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially the X-KDE- bits. That doesn't work for all desktops. What doesn't work for all desktops? Are you trying to say you're running kupdateapplet not under KDE? Could you be a bit more verbose instead of saying just "no"? and copy it back into ~/.config/autostart for only the desired users I don't have it there and it runs. Yes, because it's started from /etc/xdg/autostart ... ?
Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 14 October 2010 13:26:56 Tejas Guruswamy wrote:
On 14/10/10 12:03, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 11:16 +0100, Tejas Guruswamy wrote:
Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially the X-KDE- bits.
That doesn't work for all desktops.
What doesn't work for all desktops? Are you trying to say you're running kupdateapplet not under KDE? Could you be a bit more verbose instead of saying just "no"?
The headers in the autostart file with X-KDE are extensions ("X-") valid only to KDE that introduce conditions on the autostart (eg evaluating the value of a field in a config file). These were proposed to be standardised at freedesktop.org, like most proposals from KDE there, they stalled. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 14/10/10 13:00, Will Stephenson wrote:
On Thursday 14 October 2010 13:26:56 Tejas Guruswamy wrote:
On 14/10/10 12:03, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 11:16 +0100, Tejas Guruswamy wrote:
Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially the X-KDE- bits.
That doesn't work for all desktops.
What doesn't work for all desktops? Are you trying to say you're running kupdateapplet not under KDE? Could you be a bit more verbose instead of saying just "no"?
The headers in the autostart file with X-KDE are extensions ("X-") valid only to KDE that introduce conditions on the autostart (eg evaluating the value of a field in a config file). These were proposed to be standardised at freedesktop.org, like most proposals from KDE there, they stalled.
Will
Yes, I'm aware of all that, but the file also has a "OnlyShowIn=KDE" so anything but KDE should be irrelevant anyway. Assuming that the problem is "make kupdateapplet to start/not start for certain users": If running KDE, you can use the autostart conditions as discussed. I've tested it, it works. If not running KDE, kupdateapplet shouldn't be running by default anyway. If it is, surely that's a bug in the DE. That's why I can't understand Carlos's "That doesn't work for all desktops". What does he mean? Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 14 October 2010 14:30:51 Tejas Guruswamy wrote:
On 14/10/10 13:00, Will Stephenson wrote:
On Thursday 14 October 2010 13:26:56 Tejas Guruswamy wrote:
On 14/10/10 12:03, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 11:16 +0100, Tejas Guruswamy wrote:
Look at /etc/xdg/autostart/kupdateapplet-autostart.desktop, especially the X-KDE- bits.
That doesn't work for all desktops.
What doesn't work for all desktops? Are you trying to say you're running kupdateapplet not under KDE? Could you be a bit more verbose instead of saying just "no"?
The headers in the autostart file with X-KDE are extensions ("X-") valid only to KDE that introduce conditions on the autostart (eg evaluating the value of a field in a config file). These were proposed to be standardised at freedesktop.org, like most proposals from KDE there, they stalled.
Will
Yes, I'm aware of all that, but the file also has a "OnlyShowIn=KDE" so anything but KDE should be irrelevant anyway.
Good point.
That's why I can't understand Carlos's "That doesn't work for all desktops". What does he mean?
I guess he wants a generic solution for their updater applets too. Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-10-14 at 15:26 +0200, Will Stephenson wrote:
I guess he wants a generic solution for their updater applets too.
Obviously :-) - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky3vxIACgkQtTMYHG2NR9Vq1QCfd1T6lRJWMGNlZm78e66F1NXX je4AnRB8WZVqrTcmavdAwlZiqsLHe6d0 =Wrm3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-10-14 at 13:30 +0100, Tejas Guruswamy wrote:
That's why I can't understand Carlos's "That doesn't work for all desktops". What does he mean?
Simple: that I'm not using KDE. I get the applet from my desktop, of course, not the kde applet. What it is wanted is a solution to automatically disable all updater applets for all users - except those that the administrator decides that they get it. As the common part is the "packagekitd" daemon, I tried making it runable only by root, but that does not work. Instead, it has to be done adjusting policy kit, but this is not documented or I have no idea where. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky3BlUACgkQtTMYHG2NR9V4WwCfY+UiiejW58yhe+QJpU2+mhxV peQAnjTKXW1x7n0o0RmIYHcU8uwkKZwo =wyvf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
That's why I can't understand Carlos's "That doesn't work for all desktops". What does he mean? Simple: that I'm not using KDE. I get the applet from my desktop, of course, not the kde applet. Fair enough. What it is wanted is a solution to automatically disable all updater applets for all users - except those that the administrator decides
On Thursday, 2010-10-14 at 13:30 +0100, Tejas Guruswamy wrote: that they get it. Each updater application is independent; you'll just have to figure out a solution for each one individually. At least you know how to do it for kupdateapplet now. As the common part is the "packagekitd" daemon, I tried making it runable only by root, but that does not work. PackageKit is simply an abstraction layer to make writing cross-distro
On 14/10/10 14:31, Carlos E. R. wrote: package managers easier, it's not specific to update applets. Disabling it only means that any packagekit-based application will still run as a user, but be unable to actually do any package management tasks. It'll probably just lead to more errors.
Instead, it has to be done adjusting policy kit, but this is not documented or I have no idea where. PolicyKit will help you make the update applets work for other users by granting them extra permissions, but it won't help you disable the update applets from starting in the first place. Sorry for the misdirection :) - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2010-10-14 at 14:45 +0100, Tejas Guruswamy wrote:
On 14/10/10 14:31, Carlos E. R. wrote:
On Thursday, 2010-10-14 at 13:30 +0100, Tejas Guruswamy wrote:
That's why I can't understand Carlos's "That doesn't work for all desktops". What does he mean? Simple: that I'm not using KDE. I get the applet from my desktop, of course, not the kde applet. Fair enough.
What it is wanted is a solution to automatically disable all updater applets for all users - except those that the administrator decides that they get it.
Each updater application is independent; you'll just have to figure out a solution for each one individually. At least you know how to do it for kupdateapplet now.
Not good enough. Anyway, your solution only hides the applet, does not impede a user from running it manually. An administrator has to force things. Forbide users from running an applet they have no business to use. No simply request.
As the common part is the "packagekitd" daemon, I tried making it runable only by root, but that does not work.
PackageKit is simply an abstraction layer to make writing cross-distro package managers easier, it's not specific to update applets. Disabling it only means that any packagekit-based application will still run as a user, but be unable to actually do any package management tasks. It'll probably just lead to more errors.
No, if nobody can run "packagekitd" then the applet can not run either. At worst, it will error out, "unable to run packagekitd". No info about updates.
Instead, it has to be done adjusting policy kit, but this is not documented or I have no idea where.
PolicyKit will help you make the update applets work for other users by granting them extra permissions, but it won't help you disable the update applets from starting in the first place. Sorry for the misdirection :)
Which is the way. How is it granting users those permissions? How do we modify it so that it doesn't grant any permissions to anybody, or better, only to those I say so? The binary "/usr/sbin/packagekitd" is running with root permissions, even though users can not run it, because it is "-rwxr--r--". Thus, PolicyKit is running it. How? I do want to allow it. The only current posibility we know is deleting the binary. Or perhaps, changing the running permissions of some or all these binaries: Telcontar:~ # rpm -ql PackageKit libpackagekit-glib12 kupdateapplet-packagekit gnome-packagekit kupdateapplet | grep bin/ /usr/bin/packagekit-bugreport.sh /usr/bin/pk-debuginfo-install /usr/bin/pkcon /usr/bin/pkgenpack /usr/bin/pkmon /usr/sbin/packagekitd /usr/bin/gpk-application /usr/bin/gpk-backend-status /usr/bin/gpk-install-catalog /usr/bin/gpk-install-local-file /usr/bin/gpk-install-mime-type /usr/bin/gpk-install-package-name /usr/bin/gpk-install-provide-file /usr/bin/gpk-log /usr/bin/gpk-prefs /usr/bin/gpk-repo /usr/bin/gpk-service-pack /usr/bin/gpk-update-icon /usr/bin/gpk-update-viewer /usr/bin/kupdateapplet /usr/sbin/zypper-install I guess the kde applet is "kupdateapplet", but no idea which one is the gnome applet. - -- Cheers, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAky3vuEACgkQtTMYHG2NR9XADACeONEH7momDymadXbmaJeSYYeV C+wAn2M9KHfNmDToNK8L4W3HRVs2fDja =9Th8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (13)
-
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Carlos E. R. -
Christoph Bartoschek -
John Andersen -
ka1ifq -
kanenas＠hawaii.rr.com -
Marcus Meissner -
Richard Creighton -
Steven L Hess -
Tejas Guruswamy -
Will Stephenson