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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
