August 2009 - YaST Development - openSUSE Mailing Lists

Re: [yast-devel] license presentation
by Martin Schmidkunz 17 Aug '09

17 Aug '09

* Martin Schmidkunz <Martin.Schmidkunz(a)gmx.de> [Aug 13. 2009 15:47]: >> http://en.opensuse.org/YaST/Web/Docu/Navigation#Display_License_after_First… > The license agreement should be before the 'home' page. Before > agreeing to the license, the user must not get to any other page. Yes, I forgot to mention that. The idea was to show how a license could be presented to the user when he runs a module/application for the first time and the application/module would need a special license which has to be accepted. Cu, Martin Martin Schmidkunz User Experience Team martin.schmidkunz(a)novell.com +49 (0) 911 740 53-346 Novell® Making IT Work As One™ ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -------------------------------------

1 0

[yast-devel] Re: [yast-commit] <rest-service> master : add base system plugin
by Duncan Mac-Vicar P. 14 Aug '09

14 Aug '09

On Friday 14 August 2009 15:00:21 Josef Reidinger wrote: > ref: refs/heads/master > commit 98d602c0c74678ffb790482ccd8b493c99ab3740 > Author: Josef Reidinger <jreidinger(a)suse.cz> > Date: Fri Aug 14 15:00:06 2009 +0200 > > add base system plugin plugins/basesystem> rake (in /space/git/suse/yast/rest-service/plugins/basesystem) /usr/bin/ruby -I"lib:test" "/usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" /usr/bin/ruby -I"lib:test" "/usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" /usr/bin/ruby -I"lib:test" "/usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" /usr/bin/ruby -I"lib:lib:test" "/usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/performance/browsing_test.rb" ./test/test_helper.rb:2:in `require': no such file to load -- /space/git/suse/yast/rest-service/plugins/basesystem/config/environment (LoadError) from ./test/test_helper.rb:2 from ./test/performance/browsing_test.rb:1:in `require' from ./test/performance/browsing_test.rb:1 from /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in `load' from /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5 from /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in `each' from /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5 rake aborted! Command failed with status (1): [/usr/bin/ruby -I"lib:lib:test" "/usr/lib64...] -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] status modul - xml
by Bjoern Geuken 14 Aug '09

14 Aug '09

Hi, I'm trying to gave the status rest-service a nicer xml format, but I faced some problems by sending the times of the values. Inside a browser the xml- tree looks like that: <status> <metricgroup group_name="memory"> <metric name="memory-used"> <label type="value"> <value dateTime="1250178710">1.4260408320e+09</value> <value dateTime="1250178600">1.4165012480e+09</value> <value dateTime="1250178590">1.4164602880e+09</value> .... But when the webclient fetches the data with @client.find(...), it misses the dateTime attributes: #<YaST::ServiceResource::Proxies::Status:0x7f5c68fd0c98 @prefix_options={}, @attributes={"metricgroup"=>[#<YaST::ServiceResource::Proxies::Status::Metricgroup:0x7f5c68f22288 @prefix_options={}, @attributes={"group_name"=>"memory", "metric"=>[#<YaST::ServiceResource::Proxies::Status::Metricgroup::Metric:0x7f5c68f1fb28 @prefix_options={}, @attributes={"label"=>#<YaST::ServiceResource::Proxies::Status::Metricgroup::Metric::Label:0x7f5c68f1f038 @prefix_options={}, @attributes={"values"=> ["1.4095081472e+09", "1.4097989632e+09", ..... "1.4097973248e+09"], "type"=>"value"}>, "name"=>"memory-used"}>, ... It seems that the last branch of an xml-tree (or elements with content?) can't have any attributes. Is this the expected behaviour or maybe a bug? Björn -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 4

[yast-devel] Re: [yast-commit] <rest-service> master : system - do reboot/shutdown only in 'production' mode
by Klaus Kaempf 14 Aug '09

14 Aug '09

Some remarks inline * Ladislav Slezak <lslezak(a)novell.com> [Aug 13. 2009 19:04]: > --- a/plugins/system/app/models/system.rb > +++ b/plugins/system/app/models/system.rb > @@ -46,11 +46,21 @@ class System > case action > > when :reboot > - Rails.logger.debug 'Rebooting the computer...' > - return computer.Reboot == 0 > + if ENV['RAILS_ENV'] == 'production' > + Rails.logger.debug 'Rebooting the computer...' > + return computer.Reboot == 0 'Reboot' seems to be a function. However according to Ruby naming conventions 'Reboot' is a class (first letter upper case). > + else > + Rails.logger.debug "Skipping reboot in #{ENV['RAILS_ENV']} mode" > + return true > + end The result of the "when :reboot" case is of boolean type. Let the 'reboot' function also return a boolean and drop the comparison with 0 > when :shutdown > - Rails.logger.debug 'Shutting down the computer...' > - return computer.Shutdown == 0 > + if ENV['RAILS_ENV'] == 'production' > + Rails.logger.debug 'Shutting down the computer...' > + return computer.Shutdown == 0 > + else > + Rails.logger.debug "Skipping shutdown in #{ENV['RAILS_ENV']} mode" > + return true > + end The duplication of the production check is not DRY (don't repeat yourself). Also think about moving the check into the 'reboot' resp. 'shutdown' functions, because this is "where the action is". Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] WebYaST daily status, 14-Aug-2009
by Jiri Srain 14 Aug '09

14 Aug '09

WebYaST 14-Aug-2009 =================== Present: kkaempf, dmacvicar, schubi, bgeuken, jsrain, lslezak, mvidner, mzugec, jsuchome, jreidinger Status update ------------- - kkaempf: still working on features and tasks discussions on yast-devel TODO: announce and publish the task list - schubi: added testcased of permissions web-client + code clean-up looking on sinatra, will spend today with it (sinatra is an interface for REST services emulation) - bgeuken: worked on status module TODO: work on the web client - dmacvicar: got testsuite in hudson to blue TODO: clean-up, HTML validation TODO: building in BuildService to have an image - jsuchome: committed some work on services plug-in (and YaPI parts) considering approaches how to go on (discussion on yast-devel) not sure what to be done by Monday, need clarification first - mzugec: proposed REST API for network (discussion on yast-devel) TODO: finalize the discussion, start implementation - mvidner: nothing to be added to what Michal said - jreidinger base sysetm module proposal passed to mailing list TODO: write the rest-service back-end still some technical issues to be resolved - lslezak: improved REST service for reboot/shutdown, added testcases added some safety checks (do not reboot in development/testing mode :-) ) TODO: webclient for reboot/shutdown -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] WebYaST: Network REST Model v1
by Martin Vidner 14 Aug '09

14 Aug '09

If you wonder why another model for the same, I have started this in parallel to Miso looking at CIM, and intentionally it does not include any CIM yet. Next we will look how it can be made more CIM-like and whether the anticipated resulting complication is too much :) * /network http://mschmidkunz.110mb.com/network.html Everything goes under /network But the network services, including a DHCP *server*, will be outside Basic Config ------------ * /network/devices/ (RO) Devices and interfaces are the same for now. Devices are read only (for physial devices, but see below for virtual). The read-write part are the configs. * /network/devices/1 (RO) interface=eth0 product=MSI 1341 * /network/configs/ (RO) Configs are separated from devices like ifcfg-* (shown here like key-value pairs but xml in fact) * /network/configs/1 (RW) startmode=dhcp4 * /network/configs/2 bootproto=static ipaddr=1.2.3.4/24 * /network/configs/3 startmode=dhcp4 wireless_essid=HomeWiFi wireless_key=HomeSweetHome * /network/configs/4 startmode=dhcp4 wireless_essid=WorkWiFi wireless_wpa_psk=HomeSweetHome In the above form, configs are not associated with devices and it works like in NetworkManager, a call like /network/devices/1/configure?config=/network/configs/42 is needed. But a config can get another attribute, "device" that makes it the default config for a device, and it works like our ifcfg (where "device" is in the filename) For simplicity, the UI can hide the device-config separation and always edit the single config for a device. * /network/devices/1/current-config (RO) (current_config? TODO style) ipaddr=1.2.3.4/24 This distinguishes the config, which can specify the IP or say DHCP from the current-config, which always specifies the IP (or does not exist). Think /etc versus "ip" output. * /network/routes/ * /network/routes/default (RW) <route> <via>1.2.3.4</> ("ip r" keyword) <route> * /network/resolver (RW) <nameservers> <nameserver>1.2.3.4</> <nameserver>1.2.3.42</> </> <searches> <search>example.com</> <search>example.net</> </> (use-dhcp ?) * /network/resolver/current-config (RO) Like with the devices, this shows the config even if /network/resolver says DHCP * /network/hostname (RW) hostname=trikolka domain=suse.cz fqdn=trikolka.suse.cz (dhcp??) Virtual Devices --------------- (This is for the future, included here just to show that the API accomodates them) For virtual devices (special interfaces not based on hardware devices - bridge, bonding, vlan) is sysconfig configuration splitted into device and configuration parts. /network/configs stays the same and /network/devices becomes writable (details to be worked out but the REST paths are unchanged from the basic config) bridge ------ ifcfg-br0 STARTMODE='auto' BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_PORTS='eth0 eth1' BRIDGE_PORTPRIORITIES='50 20' * /network/devices/1 interface=br0 bridge='yes' bridge_ports='eth0 eth1' bridge_portpriorities='50 20' * /network/configs/1 bootproto='dhcp' VLAN ---- ifcfg-vlan3 STARTMODE=onboot ETHERDEVICE=eth0 IPADDR=192.168.3.27/24 * /network/devices/1 interface=vlan3 etherdevice=eth0 # /network/devices/10 * /network/configs/1 ipaddr=192.168.3.27/24 bonding ------- ifcfg-bond0 STARTMODE='onboot' BOOTPROTO='static' IPADDR='192.168.0.1/24' BONDING_MASTER='yes' BONDING_SLAVE_0='eth0' BONDING_SLAVE_1='eth1' BONDING_MODULE_OPTS='mode=1' # backup mode * /network/devices/1 interface=bond0 bonding_master='yes' bonding_slave_0='eth0' # /network/devices/10 bonding_slave_1='eth1' # /network/devices/11 bonding_module_opts='mode=1' # backup mode * /network/configs/1 ipaddr='192.168.0.1/24' -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

4 7

[yast-devel] Exporting users during installation
by Leonardo L. P. da Mata 13 Aug '09

13 Aug '09

Hello, I need to clone the installation information to be used with autoyast. there is a module called AutoinstClone that can export this information, it reads the Profile::current data and exports this information using XML::YCPToXMLFile module. This profile contains an entry for users, but this entry only contains the root user, if i create one user called "leonardo" during the installation it doesn't appear in this profile. Does anyone knows how to export the information about this initial user created during installation? i need to create this autoyast file automatic, i really need to do it during the installation process without user interference. Thank you -- Leonardo Luiz Padovani da Mata barroca(a)gmail.com "May the force be with you, always" "Nerd Pride... eu tenho. Voce tem?" -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] vendor specific module
by Martin Schmidkunz 13 Aug '09

13 Aug '09

Hi, please find a first idea of integration of vendor specific modules at: http://en.opensuse.org/YaST/Web/Docu/Navigation#Vendor_Specific_Module The idea would be: Vendor specific modules are represented either with an icon specified by a vendor or by a generic icon (e.g. yast-vendor.png) When clicking on the module the vendor specific configuration starts in fullscreen mode and replaces the webYaST UI completely. If specified by the vendor a separate login screen is shown. Cancelling the login dialog returns the user to webYaST "Home". For changes and navigation within the module the module`s controls are used. After finishing work with the vendor specific module the module is exited by clicking either on logout or any other exit option provided within the vendor specific module. The user then returns to webYaST "Home". Retrieved from "http://en.opensuse.org/YaST/Web/Docu/Navigation" Reasons for this: * running a module inside YaST GUI leads to a confusing look and feel and a lot of unclear functionalities (e.g. how to save settings); see slide 4 on presentation at http://en.opensuse.org/YaST/Web/Docu/Navigation#Try_it_3 * most programms have an exit functionality so why not use it? Looking forward to your comments! Cu, Martin -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 4

[yast-devel] license presentation
by Martin Schmidkunz 13 Aug '09

13 Aug '09

Hi, please find a first idea for license presentation in webYaST (FATE: 306697) at: http://en.opensuse.org/YaST/Web/Docu/Navigation#Display_License_after_First… The idea is: License for running the webYaST (e.g. Novell licenses) need to be accepted during first run workflow. Licenses for specific modules are display when the user first runs the module. The license is displayed within the webYaST UI. The heading contains the module icon and "License Agreement" as title. Then the license is displayed and a set of unchecked radio buttons with the labels: * Yes, I agree to this License Agreement * No, I do not agree If the license is accepted and the user clicks "OK" the module is started. If the license is not accepted and the user clicks "OK" the user returns to the "Home" page Looking forward to your comments! Cu, Martin -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] Views custom javascripts and stylesheets
by Duncan Mac-Vicar Prett 13 Aug '09

13 Aug '09

I am writing this now that the testsuite is again in blue state :-) One of the things that prevented the validation to pass was systemtime use of custom javascript. WebYaST has a main layout, which includes the standard javascript file. The plugins views are embedded inside the body of the layout. So how can a view add its custom javascripts and stylesheets? If you just add javascript or link tags, the html will be invalid, and you will breat the build. link tags are not allowed inside a div. They have to be in the head section of the document. "But the head section is in the layout". Yes. Enter the magic :-) http://asciicasts.com/episodes/8-layouts-and-content-for The trick is that the layout does a yield :head in the head section of the layut. The name is arbitrary, but for head that is the convention. Then the view can do in any part: <% content_for :head do %> <% end %> To add stuff to the head section. This trick can also be used to create an API fr the views to add content to menus, and other areas of the layout by defining new "areas", and we should document this in the documentation relative to writing modules. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0