Installation
A minimal installation of Fedora 14 is reccommended, you can download the 32bit ISO images here
YUM Repository
The YUM Repository For the latest version of the Generic SFA Wrapper for your version of Fedora
# vi /etc/yum.repos.d/sfa.repo [myplc] name= MyPLC baseurl=http://build.onelab.eu/sfa/2.1-9/sfa-2.1-9--f14-32/RPMS/ enabled=1 gpgcheck=0 # vi /etc/yum.repos.d/myplc.repo [myplc-f14-32] name=MyPLC native baseurl=http://build.onelab.eu/5.0/rc19/onelab--5.0-rc19-f14-32/RPMS/ # go fetch sfa packages from sfa.repo exclude=sfa* enabled=1 gpgcheck=0
Proceed with the installation of SFA
# yum install sfa
Generic SFA Wrapper Configuration
Configure the Generic SFA Wrapper
There is one key setting that you need to tweak in order to disable the PlanetLab driver
# sfa-config-tty Enter command (u for usual changes, w to save, ? for help) e SFA_GENERIC_FLAVOUR == SFA_GENERIC_FLAVOUR : [pl] void Enter command (u for usual changes, w to save, ? for help) w Wrote /etc/sfa/configs/site.xml Merged /etc/sfa/default_configs/site.xml and /etc/sfa/configs/site.xml into /etc/sfa/sfa_config.xml You might want to type ‘r’ (restart sfa), ‘R’ (reload sfa) or ‘q’ (quit) Enter command (u for usual changes, w to save, ? for help) r =================== Stopping sfa Shutting down SFA [ OK ] =================== Starting sfa STARTING... SFA: Checking for PostgreSQL server [ OK ] SFA: installing peer certs [ OK ] SFA: Registry [ OK ] SFA: Aggregate [ OK ] SFA: SliceMgr [ OK ] Enter command (u for usual changes, w to save, ? for help) q
we assume that you have configured your registry to serve the toplevel domain named topdomain
# sfa-config-tty Enter command (u for usual changes, w to save, ? for help) e sfa_interface_hrn == SFA_INTERFACE_HRN : [plc] topdomain Enter command (u for usual changes, w to save, ? for help) w Wrote /etc/sfa/configs/site.xml Merged /etc/sfa/default_configs/site.xml and /etc/sfa/configs/site.xml into /etc/sfa/sfa_config.xml You might want to type ‘r’ (restart sfa), ‘R’ (reload sfa) or ‘q’ (quit) Enter command (u for usual changes, w to save, ? for help) r =================== Stopping sfa Shutting down SFA [ OK ] Stopping PostgreSQL server [ OK ] =================== Starting sfa STARTING... SFA: Checking for PostgreSQL server [ OK ] SFA: installing peer certs [ OK ] SFA: Registry [ OK ] SFA: Aggregate [ OK ] SFA: SliceMgr [ OK ] Enter command (u for usual changes, w to save, ? for help) q
initializes the toplevel records that are needed to proceed
# sfaadmin reg import_registry
Create a subdomain. Although we could in principle use the 'topdomain' authority to sign users directly, it sounds like a better practice to create subauthorities, so let us create one
# sfaadmin reg register -t authority -x topdomain.subdomain
You can use your existing public key or create a new one for this tutorial generate a key for your user (it will only be used locally)
# ssh-keygen -t rsa
Enter the location of your ssh key (ex: /tmp) choose your password.
In this authority we can now create a user record that will refer to a 'PI' in this subdomain; we attach an email address and a public key to this PI record like this
# sfaadmin reg register -t user -x topdomain.subdomain.pi --email the.pi@subdomain.com --key /tmp/id_rsa.pub
This being done, we can 'attach' this user record as a PI to the topdomain.subdomain authority record (of course we refer to all these records through their hrn)
# sfaadmin reg update -t authority -x topdomain.subdomain --pi topdomain.subdomain.pi
Use SFI (SFA client)
# yum install sfa-client # mkdir ~/.sfi # cp /tmp/id_rsa ~/.sfi/topdomain.subdomain.pi.pkey # vi ~/.sfi/sfi_config SFI_AUTH='topdomain.subdomain' SFI_USER='topdomain.subdomain.pi' SFI_REGISTRY='http://localhost:12345/'# sfi --help SFI_SM='http://localhost:12347/'
check if SFA client is installed and
create slice
# vi ~/.sfi/slice_record.xml <record hrn="topdomain.subdomain.slice" type="slice" description="A slice for illustrating registry-only features in SFA" url="http://test.onelab.eu/"> <researcher>topdomain.subdomain.user</researcher> </record> # sfi add ~/.sfi/slice_record.xml
enter the password of your key and test the SFI client
# sfi list topdomain topdomain.subdomain (authority)
sfi show topdomain.subdomain.slice
RSpec
Define your needs in an Rspec specific to your testbed.
This RSpec corresponds to the informations you want to advertise about the resources of your testbed.
For example for the Nitos testbed, the need is to reserve both nodes and channels.
The idea of leasing a channel is new and specific to this Wireless testbeds.
So we had to define a draft of the NITOS Rspec.
<lease id="1" slice_id="dostavro" t_from="1339070400" t_until="1339072200">
<node component_id="urn:publicid:nitlab+outdoor+omf.nitos.node001"/>
<channel id="1" />
</lease>
if your TestBed needs the definition of a specific RSpec, this later have to be implemented as a new version of RSpec supported by the Generic SFA Wrapper which parse, validate, and generate the RSpec (contact INRIA).
On the testbed side, an API should be implemented in order to retrieve your specific testbed informations (nodes, slices, leases,...etc).
Then a specific SFA driver for your testbed must be implemented to translate Generic SFA wrapper API calls into your testbed specific API calls.
Finally, configure the SFA generic wrapper to use your driver (flavour configuration with sfa-config-tty)
The SFAWrap website is licensed by UPMC Sorbonne Universités,
on behalf of the community of contributors,