Mailinglist Archive: yast-devel (163 mails)

< Previous Next >
[yast-devel] WebYaST: Registration RFC
  • From: "J. Daniel Schmidt" <jdsn@xxxxxxx>
  • Date: Tue, 8 Sep 2009 18:41:11 +0200
  • Message-id: <200909081841.12845.jdsn@xxxxxxx>
Hi,

The last days I did some research about how to implement the registration in
WebYaST. And the more I found out about the stuff the more complicated
everthing got.
I want to give a short summary and ask for your comments here.


The registration itself is realised in a Perl module. There are currently two
wrappers that do the workflow for this module. The first is a command line
tool called "suse_register" and the second is the YaST module
"inst_suse_register" which represents the GUI pendant.

My first idea was to use the Perl module directly from Ruby. After a lot
failures it finally works with the bindings from:
http://www.yoshidam.net/Ruby.html#perl
I will prepare a package of these in the BS in case somebody needs to evaluate
Perl code from Ruby.

When I realised that the rest-service does not run as root (it did on my
workstation) but registration must run as root it made the bindings worthless.
So we have to go through the needle eye of a DBus-SCR-call and run a
commandline script (as root) and parse its output.

Well, as I only need to call a script I don't see the need to go over DBus
here. What about configuring sudo for the webservice user? Or using a tiny
setuid wrapper script? Security-wise this would make no difference, as we can
do everything via SCR-calls as root anyway. It would just make things less
complicated (1).


Fortunately I can rely on the fact that the NCC registration server (and soon
SLMS as well) offer server side caching, that means, I don't need to implement
a client side statemachine (which is hard in REST context where each next call
is the first one).


One tricky part is the zypp lock. If somebody locked the package manager on
the system and then somebody else tries to register, the zypper calls will
fail. The YaST module tells the user about it as it initialises the package
manager on startup. But how to this in REST contect? Just return an error like
"The service you are calling is temporarily not available. Please call again
later"? :) This gets less funny when it happens during a registration, as we
can/should not keep a package management lock in a REST service and thus the
lock might be taken in the meanwhile.




Ciao,
Daniel

--
J. Daniel Schmidt <jdsn@xxxxxxx> SUSE Linux Products GmbH
Research & Development Maxfeldstr. 5
GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg



(1) For me all this has too many layers already:
Ok, lets skip the users browser that does HTTP(S) requests to the web-client
which in turn does HTTP(S) requests to the rest-service.
The rail rest-service then needs to do an SCR-DBus call which starts a DBus-
Service and so does an Execute as root and runs a new script (the current
suse_register is not sufficient for this) which is a new wrapper for the
registration Perl module that talks to the NCC-server via HTTPS requests and
parses their XML. The dumped result needs to get parsed again in the rest-
service. In case there is information missing the user needs to get asked
again. In case the registration is done there are (most likely) changes to be
done to the package system (which might fail because of a zypp lock of a
different user) that need to go there the SCR-DBus-way.

Can we reduce the number of layers somehow? Or did I forget about some, that
need to be added to make it more interesting? :)

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >