T2B Wiki - User contributions [en-gb]

UpdateCertificates

2016-05-17T09:17:50Z

Olivier Devroede: /* Procedure */

== Update and request server certificates ==

=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''qnat''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus service on argus

<pre>
service argus stop
service argus start
</pre>

If this is not enough think of restarting the node.

If the DN of the machine changes (new certificate provider, ...) then its need to be added explicitly into the template of argus. The affected variable is PAP_HOST_DN.

'''9.''' (Optional) Adapt GOCDB server entry

If the DN of the machine changes (especially needed for APEL) then go to the GOCDB page and edit the corresponding entry to reflect the new DN.

{{TracNotice|{{PAGENAME}}}}

UpdateCertificates

2016-05-17T09:16:48Z

Olivier Devroede: /* Update and request server certificates */

== Update and request server certificates ==

=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''ccq3''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus service on argus

<pre>
service argus stop
service argus start
</pre>

If this is not enough think of restarting the node.

If the DN of the machine changes (new certificate provider, ...) then its need to be added explicitly into the template of argus. The affected variable is PAP_HOST_DN.

'''9.''' (Optional) Adapt GOCDB server entry

If the DN of the machine changes (especially needed for APEL) then go to the GOCDB page and edit the corresponding entry to reflect the new DN.

{{TracNotice|{{PAGENAME}}}}

UpdateCertificates

2016-05-17T09:16:28Z

Olivier Devroede: /* Update and request server certificates */

== Update and request server certificates ==

----
=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''ccq3''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus service on argus

<pre>
service argus stop
service argus start
</pre>

If this is not enough think of restarting the node.

If the DN of the machine changes (new certificate provider, ...) then its need to be added explicitly into the template of argus. The affected variable is PAP_HOST_DN.

'''9.''' (Optional) Adapt GOCDB server entry

If the DN of the machine changes (especially needed for APEL) then go to the GOCDB page and edit the corresponding entry to reflect the new DN.

{{TracNotice|{{PAGENAME}}}}

UpdateCertificates

2016-05-17T09:15:47Z

Olivier Devroede: /* Deprecated content ! Please read before going any further on this page ! */

== Update and request server certificates ==
[[PageOutline]]
----
=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''ccq3''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus service on argus

<pre>
service argus stop
service argus start
</pre>

If this is not enough think of restarting the node.

If the DN of the machine changes (new certificate provider, ...) then its need to be added explicitly into the template of argus. The affected variable is PAP_HOST_DN.

'''9.''' (Optional) Adapt GOCDB server entry

If the DN of the machine changes (especially needed for APEL) then go to the GOCDB page and edit the corresponding entry to reflect the new DN.

{{TracNotice|{{PAGENAME}}}}

Register to the CMS VO

2016-04-12T14:37:32Z

Olivier Devroede:

* Go to the [https://voms2.cern.ch:8443/voms/cms/register/start.action VOMS page]. On the possible certificate prompt, select the one you just created. 
** [ If you don't arrive in the page below, then you might already be registered to the CMS VO. Make the [[SiteDB|SiteDB check]] to be sure. ]
** Enter the email address registered at cern, then click submit. 
** You should appear just below. If it's you, well click on the correct button ! 

:: [[ File:vocms1.png|center]] 
:* If it doesn't find you with the email you entered after clicking on submit, then look in the [https://phonebook.cern.ch/phonebook/ CERN phonebook] for your email. If you cannot find yourself, then make sure you are registered to CERN or CMS at least.
:: [[File:cern_phonebook.png|center]]
:* Fill in all fields, accept the policy, then submit.
:: [[File:vocms_form.png|center]]
:* The procedure is nearly finished, look at your inbox corresponding to the CERN email.
[[File:vocms_email.png|center]]
:* Just click on the confirmation link in the email received.
[[File:vocms_end.png|center]]

* Now you only need to wait '''a few hours''' for your membership to be approved !

* You can [[SiteDB | follow the wiki]] to check SiteDB if your certificate as well as membership are fine and got approved.

ManageAllAdminScriptsWithGit

2016-03-17T10:31:28Z

Olivier Devroede: /* Adding/Modifying the scripts from your computer */

__TOC__

* The admin scripts are managed by [http://git.iihe.ac.be Git]
* They should be mounted on all machines managed by quattor in '''/scripts'''

 
=== Git Workflow ===
==== Adding/Modifying the scripts from your computer ====
# Request an account from git admins
# add your ssh key to your profile
# Do an '''git clone git@git.iihe.ac.be:iihe-scripts.git''' to download the content of iihe-scripts locally If you already have the script directory locally, you can first make sure you are on the master branch with '''git checkout master''' , and then pull the possible updates with '''git pull''' If you have made some changes to the master branch (wich you shouldn't!!), use '''git stash''' to ''store'' the changes and get a vanilla master, and when on the new branch (next step) use '''git stash apply''' to apply the changes to the current branch.
# Make a new branch from master '''git checkout -b BranchImWorkingOn'''. The branch name should reflect what you plan on doing. Never use directly the ''master'' branch !! You can check this worked with '''git branch -ra''' that lists local & remote branches.
# Make your new scripts or modifications
# If you made new files/directories, prepare them for atomic commit: '''git add -N myfile'''
# Select the chunks of code you want to commit: '''git add -p''' , (explanations of letters [[ManageAllAdminScriptsWithGit#Summary_Of_Git_Commands|here]]). Be as small and precise as possible for each commits.
# If you want to revert the adding chunks to the index you just did : '''git reset -p'''
# Do the commit for the chunks you selected '''git commit -m"short message" [-m"long message"]'''. The long message is optional.
# To list the last commits '''git log -<NumberOfCommits>'''
# Last, you need to push the local changes to the remote server : '''git push origin BranchImWorkingOn'''
# Make a merge request on the [http://git.iihe.ac.be git site]: [[File: git_merge_request.png|700px|center]]

==== Summary Of Git Commands ====
<pre>
# First
git clone git.blahblah
git checkout master
git pull -p # this updates the local branch taking origin
git checkout -b newbranch
#or git branch -m oldbranch newbranch

# if working on wrong branch
git stash
# then go to new branch
git stash apply

git branch -ra ==> lists repo & local branches

# Atomic commit (by hunks):
git add -N myfile #first prepare file before patchadding
git add -p
y - indexer cette partie
n - ne pas indexer cette partie
a - indexer cette partie et toutes celles restantes dans ce fichier
d - ne pas indexer cette partie ni aucune de celles restantes dans ce fichier
g - sélectionner une partie à voir
/ - chercher une partie correspondant à la regexp donnée
j - laisser cette partie non décidée, voir la prochaine partie non encore décidée
J - laisser cette partie non décidée, voir la prochaine partie
k - laisser cette partie non décidée, voir la partie non encore décidée précédente
K - laisser cette partie non décidée, voir la partie précédente
s - couper la partie courante en parties plus petites
e - modifier manuellement la partie courante
? - afficher l'aide

==> this add hunks to index, needs git commit -m""
git reset -p ==> revert the adding to index

git commit -m"" [-m"long message"]

git diff ==> local / index
git diff HEAD ==> local / repo
git diff --cached ==> index / repo

git log -3 ==> lists commit

# Pushing
git push origin newbranch ==> pushes local branch to repo & creates new repo branch

</pre>

 

=== Adding /scripts to a machine and getting access to it ===
* You need to mount with nfs (or autofs) the /storage of tesla
* Then create a symlink from '''/storage_mnt/storage/group/admin/iihe-scripts''' to '''/scripts'''
* Or you can just include the template in '''config/nfs/storage''' in your machine, which does all this.
* It is in read-only for non-root users of the '''admins''' group, so you cannot make any modifications there.
* If you want access as non-root user, you need to add yourself in [http://freeipa.wn.iihe.ac.be freeipa] [accessible through tunnel only] to the '''admins''' group.

 
=== Old Wiki page for using SVN ===
*[[ManageAllAdminScriptsWithSVN| here]]

UpdateCertificates

2016-03-16T12:26:26Z

Olivier Devroede: /* Renew Certificates */

== Deprecated content ! Please read before going any further on this page ! ==
The procedure to request certificates has changed since a few months. The new procedure is described [http://wikit.iihe.ac.be/index.php/SSL_Certificates here].

So, what is written below is not valid anymore and needs to be adapted...

== Update and request server certificates ==
[[PageOutline]]
----
=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''ccq3''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus service on argus

<pre>
service argus stop
service argus start
</pre>

If this is not enough think of restarting the node.

If the DN of the machine changes (new certificate provider, ...) then its need to be added explicitly into the template of argus. The affected variable is PAP_HOST_DN.

{{TracNotice|{{PAGENAME}}}}

UpdateCertificates

2016-03-16T12:25:12Z

Olivier Devroede: /* Renew Certificates */

UpdateCertificates

2016-03-14T13:32:57Z

Olivier Devroede:

== Deprecated content ! Please read before going any further on this page ! ==
The procedure to request certificates has changed since a few months. The new procedure is described [http://wikit.iihe.ac.be/index.php/SSL_Certificates here].

So, what is written below is not valid anymore and needs to be adapted...

== Update and request server certificates ==
[[PageOutline]]
----
=== Introduction ===
All certificates for our machines will have to be updated every year. We will receive mails starting 2 weeks before the certificates expire. 
the decision was taken to update all the certificates at once and Stein De Weirdt wrote a script to do just that. 
The last update of the certificates happened on 2 mai 2008 on a cloudy but warm afternoon.

=== Procedure ===

Log in on '''ccq3''' and generate all the necessary certificates with this tool:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py
</pre>
the tools help output gives:
<pre>
Usage:
--mode Mode: new,renew,conv,get (default: renew)
renew: make new server requests from existing certificates (in directory --dir) and upload the requests
get: - will make quattor templates in <--dir>/private
- public key need to be put in <--dir>/PemDir (to be created)
- the matching private key is looked for in <--dir>
new: make new server request (with DN attributes --att and create the requests/key in --dir)
--dir Read/write templates to/from dir (default: .)

--debug Set debug mode. (default: False)
--att DN Attributes, comma separated list eg (OU=IIHE,CN=gridce.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be)
- assumes C=BE and O=BEGRID
- emailAddress is mandatory (and should be last att)

</pre>

'''1.''' Create/renew certificate
==== Create New Certificate ====
To create a new certificate, do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=new --dir=/root/new-cert/ --att=OU=IIHE,CN=behar050.iihe.ac.be,emailAddress=grid_admin@listserv.vub.ac.be --debug
</pre>
==== Renew Certificates ====
To renew all certificates, first remove all .pem files in /root/new-cert/. Move the .tpl files from /root/new-cert/private to /root/new-cert/. Then, remove everything from the 2 subdirectories (private and PemDir) 
Then Do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=renew --dir=/root/new-cert/ --debug
</pre>
'''2.'''All the keys need to be uploaded one by one to the belnet site. Go to https://gridra.belnet.be , click "Request a Certificate", choose server from the drop down box. Upload one generate certificate (the ones with -req). On OU needs to be added. For this chose 'VUB'. 

'''3.''' All the generated certificates will be send via mail. Download them all (choose only the one ending in _iihe_ac_be.pem from every mail) and put them in /root/new-cert/PemDir and do:
<pre>
/opt/CB6/tmp/src/begrid/cb-client/certificate_tool.py --mode=get --dir=/root/new-cert/ --debug
</pre>
all the certificates templates will be saved in /root/new-cert/private. 
'''4.''' next step is to update all the quattor files and to make the clients connect for their new certificates. 
For this, put the private templates on ccq3, /opt/CB6/private or /opt/CB5/private, in the appropriate glite version dir.
<pre>
cd /opt/CB6/svncheck/
./runcheck
</pre>
'''5.''' This will broadcast a message to all the machines and they will respond within 5 minutes and start updating. All services except one will update fine 
'''6.''' We now check that the update was complete and for this we first log in to '''maite'''.
<pre>
grep filecopy /var/log/ncm-cdispd.log
</pre>
Or alternatively
<pre>
less /var/log/ncm/component-filecopy.log
</pre>
Now, check the certificate:
<pre>
openssl x509 -in /etc/grid-security/hostcert.pem -noout -dates
</pre>
And make sure the new end date is indeed a year from now. 

'''7.''' We now perform a final check: log in to any UI and do
<pre>
srmls srm://maite.iihe.ac.be:8443/pnfs/iihe/cms
</pre>
also try to copy some files from storage to the use disk using dccp.
All directories should be listed.

'''8.''' Restart argus services on argus-emi

<pre>
service argus stop
service argus start
</pre>
If this is not enough think of restarting the node.

{{TracNotice|{{PAGENAME}}}}

DCacheAdminMode

2016-02-21T18:55:52Z

Olivier Devroede:

This wiki page is intended to help admins debugging dCache issues.

=== Tracking pnfs id and pool for a specific file ===

*Login to the admin console
<pre>
[root@maite ~]# ssh -F /root/.ssh/dcache_admin_config admin@localhost

dCache Admin (VII) (user=admin)

[maite.iihe.ac.be] (local) admin >
</pre>

*Copy the file with <tt>dccp</tt> and check in <tt>PoolManager</tt> the status of the transfer. In our case, something is bad with <tt>pnfsid 000C00000000000000D4D6F8</tt>
<pre>
[maite.iihe.ac.be] (local) admin > cd PoolManager
[maite.iihe.ac.be] (PoolManager) admin > rc ls
000C00000000000000D4D6F8@0.0.0.0/0.0.0.0-*/* m=9 r=1 [<unknown>] [Suspended (pool unavailable) 08.19 10:01:01] {0,}
</pre>

*Another way to know the pnfsid of a file is to run:
<pre>
[maite.iihe.ac.be] (local) admin > pnfs map /pnfs/iihe/cms/ph/sc4/store/mc/2007/11/13/CSA07-tt0j_mT_70-alpgen-3545/0005/064A4D43-7DC3-DC11-B586-0030487C116E.root
000C00000000000000D4D6F8
</pre>

*Or yet another way, in <tt>PnfsManager</tt>
<pre>
[maite.iihe.ac.be] (PnfsManager) admin > pnfsidof /pnfs/iihe/cms/ph/sc4/store/mc/2007/11/13/CSA07-tt0j_mT_70-alpgen-3545/0005/064A4D43-7DC3-DC11-B586-0030487C116E.root
000C00000000000000D4D6F8
</pre>

*In <tt>PnfsManager</tt>, using the pnfsid you can locate the pool that stores physically the file by running:
<pre>
[maite.iihe.ac.be] (PnfsManager) admin > cacheinfoof 000C00000000000000D4D6F8
behar5_1
</pre>

*The command cd will not work to leave go back to admin
<pre>
..
</pre>

*Looking into each machine explicitly
<pre>
[beharX.iihe.ac.be] > ls /storage/[1,2,3]/pool/data/0011000000000000032CC250
</pre>

=== Setting the verbosity level of dCache ===

The procedure to increase the log level can be found in the [dcache workbook https://www.dcache.org/manuals/Book-2.12/config/cf-tss-monitor-fhs.shtml]

The different cells can be found in the files in /usr/share/dcache/defaults/ 
the command is: grep "cell\.name" *

<pre>
f.i.:
srm domain: SRM-maite
nfs domain: NFS-maite
xrootd: Xrootd-maite
</pre>

{{TracNotice|{{PAGENAME}}}}

LocalSubmission

2016-02-01T13:34:57Z

Olivier Devroede: /* Attachments */

== Direct submission to local queue on the T2_BE_IIHE cluster ==

=== Aim ===

*The aim of this page is to provide a brief introduction how to submit to the localqueue.
*The localqueue allows to send executable code to the Tier2 cluster.
*This procedure can be used to run non-CMSSW code that need access to files on the Storage Element (SE) maite.iihe.ac.be.
*It is useful to use this procedure to not overload the User Interfaces (UIs) known as the mX machines.

=== Procedure ===

*Log in to a UI mX.iihe.ac.be; replace X with a number of choice. See [[policies]] about the policies on the UIs.
*Make a directory and prepare an executable.
<pre>
mkdir directsubmissiontest
cd directsubmissiontest/
emacs script.sh&
</pre>
*Paste following code into script.sh. (see below)
*Due to the setup of the Tier2 the output of the script will be placed on the ''/localgrid'' partition which is mounted on both the UI's on the workernodes. Therefore you need to prepare a directory to make sure the output is stored correctly. The localgrid partition can be used as a sandbox for temporary placing input and output files. Do not store any files there permanently.
<pre>
mkdir /localgrid/$USER/directsubmissiontest
</pre>
*Execute the following command to submit the script to the local queue
<pre>
qsub -q localgrid@cream02 -o script.stdout -e script.stderr script.sh
</pre>
*Follow the progress of your job on the UI
<pre>
qstat -u $USER localgrid@cream02
</pre>

*Your job finished if you don't see it anymore with qstat. You should now be able to find your output files in the directory you've create on localgrid
<pre>
/localgrid/$USER/directsubmissiontest/script.stdout
/localgrid/$USER/directsubmissiontest/script.stderr
/localgrid/$USER/directsubmissiontest/
</pre>

=== Comments and FAQ ===
*In case you would like to access a root file you should copy it to the /scratch space on the workernode.
**/scratch is the native disk of the workernode and is several 100 GBs big.
**Each job is allotted a working directory that is cleaned automatically at the end of the job. This directory is store in the variable $TMPDIR
**Your procedure should look like this:
**copy the necessary root from /localgrid (if you have any) to $TMPDIR
**Make sure the output of the job is also written to $TMPDIR
**Copy your output files back to /localgrid
**Do not read root files from /localgrid. This directory is not physically located on the workernode, it is mounted from the fileserver. Doing this will put a big load on the fileserver potentially causing the UIs to be slow.

'''****** IMPORTANT *******''' 
If you use the local submission, please notice that you potentially can slow down our site. So please, copy all the files you will use during the job to /scratch to avoid this. 
Many thanks, 
The Admin Team

*How to set CMSSW environment in a batch job?

Add the following lines to your script :
<pre>
pwd=$PWD
source $VO_CMS_SW_DIR/cmsset_default.sh # make scram available
cd /localgrid/<USER NAME>/path/to/CMSSW_4_1_4/src/ # your local CMSSW release
eval `scram runtime -sh` # don't use cmsenv, won't work on batch
cd $pwd
</pre>

*How to make your proxy available during batch jobs?

Make sure you have a valid proxy and copy it to some place on /localgrid :
<pre>
cp $X509_USER_PROXY /localgrid/<USER NAME>/some/place
</pre>

Add the following line to your script :
<pre>
export X509_USER_PROXY=/localgrid/<USER NAME>/some/place
</pre>

*How to avoid my short jobs from being blocked in the waiting queue when the site is full ?

If you intend to submit short jobs, then it is wise to specify explicitly to the batch system their estimated maximum walltime. You can do this by adding an option to the qsub command :
<pre>
qsub -q localgrid@cream02 -o script.stdout -e script.stderr -l walltime=<HH:MM:SS> script.sh
</pre>
or by adding the following line at the beginning of your job script :
<pre>
#PBS -l walltime=<HH:MM:SS>
</pre>
Proceeding this way, your jobs priority will grow faster as time goes by, increasing the chances of being executed first. (The shorter they are, the faster their priority will increase over the time.)

But be aware that if your jobs are running longer then the specified maximum walltime, they will be killed by the batch system. So, don't hesitate to overestimate a bit this maximum walltime.

=== Stop your jobs ===

If for some reason, you want to stop your jobs on the server, you can use this procedure:

<pre>
qstat @cream02 | grep <your user name>
</pre>
This will give you a list of jobs running with thier ID's. f.i.

<pre>
394402.cream02 submit.sh odevroed 0 R localgrid
</pre>
Now, use the ID to kill the job with the qdel command:

<pre>
qdel 394402.cream02
</pre>

Your job will now be removed.

=== Attachments ===

*script.sh
<pre>
#!/bin/bash

##Some general shell commands
STR="Hello World!"
echo $STR
echo ">> script.sh is checking where it is"
pwd
echo ">> script.sh is checking how much disk space is still available"
df -h
echo ">> script.sh is listing files and directories in the current location"
ls -l
echo ">> script.sh is listing files and directories in userdir on storage element"
ls -l /pnfs/iihe/cms/store/user/$USER

##When accessing files on the storage element it is important to execute your code on the /scratch partition of the workernode you are running on. Therefore you need to copy your executable which is accessing/writing root files onto the /scratch partition and execute it there. This is illustrated below.

echo ">> go to TMPDIR"
cd $TMPDIR
echo ">> ls of TMPDIR partition"
ls -l

##Create a small root macro

echo "{
//TFile *MyFile = new TFile(\"testfile.root\",\"RECREATE\");
//MyFile->ls();
//MyFile->Close(),
TFile* f=TFile::Open(\"dcap://maite.iihe.ac.be/pnfs/iihe/cms/store/user/$USER/testfile.root\");
f->ls();
f->Close();
}
" > rootScript.C

cat rootScript.C

echo ">> set root"
##Copied a root version from /user/cmssoft into /localgrid
export ROOTSYS=/localgrid/$USER/cmssoft/root_5.26.00e_iihe_default_dcap/root
export PATH=$PATH:$ROOTSYS/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTSYS/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/lib

echo ">> execute root macro"
root -q -l -b -n rootScript.C

echo ">> ls of TMPDIR"
ls -l

echo "copy the file back to the /localgrid sandbox"
#cp testfile.root /localgrid/jmmaes/directsubmissiontest
</pre>

{{TracNotice|{{PAGENAME}}}}

Policies

2016-01-21T09:55:18Z

Olivier Devroede: /* User Interface policy */

== Policies concerning the usage of local computing resources ==

*The following rules are put in place to allow a fair share of resources between the users. In case you violate these rules your account could be disabled.
*In case you have specific needs concerning storage or CPU please contact the site administrators on [[T2bSupport]].

=== User Interface policy ===

*All user interfaces are running Scientific Linux 6, except m3.iihe.ac.be which is still running SL5.
*The following machines are for light tasks, such as:
**Crab submission
**small interactive root processes
**building code
**debugging code

<pre>
m0.iihe.ac.be, m1.iihe.ac.be, m2.iihe.ac.be, m3.iihe.ac.be
</pre>
*The following machines are available for CPU-intensive and long tasks

<pre>
m5.iihe.ac.be, m6.iihe.ac.be, m7.iihe.ac.be, m8.iihe.ac.be and m9.iihe.ac.be
</pre>

'''This policy is enforced. Processes taking more than 10 minutes CPU on M1->M3 will be killed by the operating system. This limit is set to 5 hours on M5->M8. On M9 the limit is set to 500 hours '''

=== Disk space usage policy ===

*Users can have several locations to store their files/analysis code/final results/...
**The /user partition on the UIs (m-machines) is limited to 500 GB per user.
**:This space should be used as working environment, eg. to checkout code, store results,... It should not be used to store large datasets.
**The /localgrid partition on the UIs (partition is mounted on the workernodes), with its quota shared with /user, so max(/localgrid + /user = 500 GB).
**:This space serves as sandbox for input/output of jobs sent to the local batch queue.
**The /pnfs area has a limit of 2TB per user.
**:This area should contain the sometimes large dataset needed for physics analysis.
**In case one needs more space, please contact the site admins [[T2bSupport| here]].

*Semi-Automatic removal of old files on /pnfs is done every 3 months.
**All files not accessed in 1 year need to be explicitely un-flagged by the user in order to keep them
**All other files CAN be marked by the user for deletion
**Several mails will be send to remind all users to do this.
**These mails will be send in a span of ~1month, after which the admins will proceed to the deletion of all flagged files.
*More information is found on the deletion page: http://mon.iihe.ac.be/OldPnfsFiles
**If you need an account on this page, please ask the admins (grid_adminNOSPAM@listserv.vub.ac.be)

=== Back-up procedures of files ===

*The is a local backup (snapshot mechanism) of the user home directories (for more detailed info, see [[Backup]]
**This back-up is made every day and we can go back day by day till last week. This is to address e.g. user small mistaken deletions.
**Users are strongly advised to not solely rely on this backup. Using a versioning system (SVN or CVS) should prevent accidental removal of files and allowas a user to go back to a previous file when the file was messed up. We don't maintain a CVS repository ourselves but the CMS one should be used, more info [https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookComputingConcepts#CvsCheckoutModules here]
*The entire user home directories are backed up every week in a physically separated hardware. This is to address catastrophe scenario.

=== Memory usage on the grid ===

*To protect the grid, there is an upper memory limit per job of 2.0GB (this is larger than what is asked by CMS) for the physical and the virtual memory.
*If your job exceeds this limit, it will be killed by the queueing system.
**in you crab error log, you will find an error code 271
**if you use direct submission, the reason will be clearly stated in your error log

Motd

2016-01-20T14:03:27Z

Olivier Devroede:

* The several relevant files:
** in quattor, '''sites/.../config/motd.sh''' : script that is called each time you connect as non-root to an ui.
** on UIs, '''/user/motd_news''': the portion to add Announcements.
** in quattor, '''sites/.../config/motd.tpl''' : just does the copy of motd.sh in /etc/profile.d/ for relevant hosts.
 
* The announcements is present only if NEWS is not set to "" in '''motd_news'''. The message is in purple by default ($PURP), and is automatically set back to $DEF at the end. Try to keep the message's lines about the same size as the rest.
::To erase it, just put back :
NEWS=""

::Example:
<pre>NEWS="
$INFO There will be a shutdown of the whole T2B infrastructure due to power
18/01 being down at the CC from :
Monday 25/01 queues : 8am | whole cluster : 3pm
to Tuesday 26/01 6pm (this is deadline, could be up before)
"
</pre>

Getting a certificate for the T2

2016-01-20T13:39:35Z

Olivier Devroede: /* First time certificate */

If you need grid access on the T2, please follow all the steps below: 

=== First time certificate ===
# [[Obtaining_a_certificate | Get a certificate (new)]]. ''If you already have a CERN grid certificate, you can temporarily use it. But for accounting reasons, we need you to get a Belgian certificate ''
# Extract your certificate from your browser: '''[[Chrome]]''' | '''[[Firefox]]'''
# [[certificate_to_UI | Put your certificate on the UIs]]
# [[Register_to_the_CMS_VO|Register to the CMS VO]]
# [[SiteDB | Check if your certificate is ok on SiteDB]]. Note the DN.
# Send a mail to grid_admin@listserv.iihe.ac.be with your DN in order to have write access on the T2.
# [[CERN_certificate_management | Check that your certificate is the only one registered on the CERN website.]]
# [[Check_Certificate_UIs | Check if everything works fine on the mX machines]]

=== Certificate renewal ===
As we switched the company who provides us with certificates, you need to follow the 'First time certificate' to have a new one, this until December 2016 at least.

Getting a certificate for the T2

2016-01-20T13:39:22Z

Olivier Devroede: /* First time certificate */

If you need grid access on the T2, please follow all the steps below: 

=== First time certificate ===
# [[Obtaining_a_certificate | Get a certificate (new)]]. ''If you already have a CERN grid certificate, you can temporarily use it. But for accounting reasons, we need you to get a Belgian cezrtificate ''
# Extract your certificate from your browser: '''[[Chrome]]''' | '''[[Firefox]]'''
# [[certificate_to_UI | Put your certificate on the UIs]]
# [[Register_to_the_CMS_VO|Register to the CMS VO]]
# [[SiteDB | Check if your certificate is ok on SiteDB]]. Note the DN.
# Send a mail to grid_admin@listserv.iihe.ac.be with your DN in order to have write access on the T2.
# [[CERN_certificate_management | Check that your certificate is the only one registered on the CERN website.]]
# [[Check_Certificate_UIs | Check if everything works fine on the mX machines]]

=== Certificate renewal ===
As we switched the company who provides us with certificates, you need to follow the 'First time certificate' to have a new one, this until December 2016 at least.

LocalSubmission

2016-01-04T10:20:50Z

Olivier Devroede: /* Comments and FAQ */

== Direct submission to local queue on the T2_BE_IIHE cluster ==

=== Aim ===

*The aim of this page is to provide a brief introduction how to submit to the localqueue.
*The localqueue allows to send executable code to the Tier2 cluster.
*This procedure can be used to run non-CMSSW code that need access to files on the Storage Element (SE) maite.iihe.ac.be.
*It is useful to use this procedure to not overload the User Interfaces (UIs) known as the mX machines.

=== Procedure ===

*Log in to a UI mX.iihe.ac.be; replace X with a number of choice. See [[policies]] about the policies on the UIs.
*Make a directory and prepare an executable.
<pre>
mkdir directsubmissiontest
cd directsubmissiontest/
emacs script.sh&
</pre>
*Paste following code into script.sh. (see below)
*Due to the setup of the Tier2 the output of the script will be placed on the ''/localgrid'' partition which is mounted on both the UI's on the workernodes. Therefore you need to prepare a directory to make sure the output is stored correctly. The localgrid partition can be used as a sandbox for temporary placing input and output files. Do not store any files there permanently.
<pre>
mkdir /localgrid/$USER/directsubmissiontest
</pre>
*Execute the following command to submit the script to the local queue
<pre>
qsub -q localgrid@cream02 -o script.stdout -e script.stderr script.sh
</pre>
*Follow the progress of your job on the UI
<pre>
qstat -u $USER localgrid@cream02
</pre>

*Your job finished if you don't see it anymore with qstat. You should now be able to find your output files in the directory you've create on localgrid
<pre>
/localgrid/$USER/directsubmissiontest/script.stdout
/localgrid/$USER/directsubmissiontest/script.stderr
/localgrid/$USER/directsubmissiontest/
</pre>

=== Comments and FAQ ===
*In case you would like to access a root file you should copy it to the /scratch space on the workernode.
**/scratch is the native disk of the workernode and is several 100 GBs big.
**Each job is allotted a working directory that is cleaned automatically at the end of the job. This directory is store in the variable $TMPDIR
**Your procedure should look like this:
**copy the necessary root from /localgrid (if you have any) to $TMPDIR
**Make sure the output of the job is also written to $TMPDIR
**Copy your output files back to /localgrid
**Do not read root files from /localgrid. This directory is not physically located on the workernode, it is mounted from the fileserver. Doing this will put a big load on the fileserver potentially causing the UIs to be slow.

'''****** IMPORTANT *******''' 
If you use the local submission, please notice that you potentially can slow down our site. So please, copy all the files you will use during the job to /scratch to avoid this. 
Many thanks, 
The Admin Team

*How to set CMSSW environment in a batch job?

Add the following lines to your script :
<pre>
pwd=$PWD
source $VO_CMS_SW_DIR/cmsset_default.sh # make scram available
cd /localgrid/<USER NAME>/path/to/CMSSW_4_1_4/src/ # your local CMSSW release
eval `scram runtime -sh` # don't use cmsenv, won't work on batch
cd $pwd
</pre>

*How to make your proxy available during batch jobs?

Make sure you have a valid proxy and copy it to some place on /localgrid :
<pre>
cp $X509_USER_PROXY /localgrid/<USER NAME>/some/place
</pre>

Add the following line to your script :
<pre>
export X509_USER_PROXY=/localgrid/<USER NAME>/some/place
</pre>

*How to avoid my short jobs from being blocked in the waiting queue when the site is full ?

If you intend to submit short jobs, then it is wise to specify explicitly to the batch system their estimated maximum walltime. You can do this by adding an option to the qsub command :
<pre>
qsub -q localgrid@cream02 -o script.stdout -e script.stderr -l walltime=<HH:MM:SS> script.sh
</pre>
or by adding the following line at the beginning of your job script :
<pre>
#PBS -l walltime=<HH:MM:SS>
</pre>
Proceeding this way, your jobs priority will grow faster as time goes by, increasing the chances of being executed first. (The shorter they are, the faster their priority will increase over the time.)

But be aware that if your jobs are running longer then the specified maximum walltime, they will be killed by the batch system. So, don't hesitate to overestimate a bit this maximum walltime.

=== Stop your jobs ===

If for some reason, you want to stop your jobs on the server, you can use this procedure:

<pre>
qstat @cream02 | grep <your user name>
</pre>
This will give you a list of jobs running with thier ID's. f.i.

<pre>
394402.cream02 submit.sh odevroed 0 R localgrid
</pre>
Now, use the ID to kill the job with the qdel command:

<pre>
qdel 394402.cream02
</pre>

Your job will now be removed.

=== Attachments ===

*script.sh
<pre>
#!/bin/bash

##Some general shell commands
STR="Hello World!"
echo $STR
echo ">> script.sh is checking where it is"
pwd
echo ">> script.sh is checking how much disk space is still available"
df -h
echo ">> script.sh is listing files and directories in the current location"
ls -l
echo ">> script.sh is listing files and directories in userdir on storage element"
ls -l /pnfs/iihe/cms/store/user/$USER

##When accessing files on the storage element it is important to execute your code on the /scratch partition of the workernode you are running on. Therefore you need to copy your executable which is accessing/writing root files onto the /scratch partition and execute it there. This is illustrated below.

echo ">> go to TMPDIR"
cd $TMPDIR
echo ">> ls of TMPDIR partition"
ls -l

##Create a small root macro

echo "{
//TFile *MyFile = new TFile(\"testfile.root\",\"RECREATE\");
//MyFile->ls();
//MyFile->Close(),
TFile* f=TFile::Open(\"dcap://maite.iihe.ac.be:/pnfs/iihe/cms/store/user/$USER/testfile.root\");
f->ls();
f->Close();
}
" > rootScript.C

cat rootScript.C

echo ">> set root"
##Copied a root version from /user/cmssoft into /localgrid
export ROOTSYS=/localgrid/$USER/cmssoft/root_5.26.00e_iihe_default_dcap/root
export PATH=$PATH:$ROOTSYS/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTSYS/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/lib

echo ">> execute root macro"
root -q -l -b -n rootScript.C

echo ">> ls of TMPDIR"
ls -l

echo "copy the file back to the /localgrid sandbox"
#cp testfile.root /localgrid/jmmaes/directsubmissiontest
</pre>

{{TracNotice|{{PAGENAME}}}}

WorkingInT2BCloud

2015-09-01T16:35:55Z

Olivier Devroede: /* Creation of the disk */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg|1000px]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg|1000px]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg|1000px]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg|1000px]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
## The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
## And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

===== Template: OS Booting =====

[[File:Create_template_booting_opennebula.jpg|1000px]]

If you want to install the machine with Quattor, it is very important to choose the network as the first boot device, and the hard drive as the second one.

===== Template: IO =====

[[File:Create_template_IO_opennebula.jpg|1000px]]

Choose “VNC” to be able to interact with your VM.

===== Template: Context =====

[[File:Create_template_Context_opennebula.jpg|1000px]]

Unselect the contextualization check-boxes (we don't need it because Quattor will do the job).

===== Template: Context =====

[[File:Create_template_Shedulling_opennebula.jpg|1000px]]

# The scheduling is the step where OpenNebula is selecting an hypervisor to host the VM. In our T2B cloud, some hypervisors are connected to the old public network, and the others are connected to the new public network. If your VM will be in the new public network, you must tell explicitely the scheduler to choose the hypervisor accordingly.
* Remark : PUBLIC_NETWORK_AVAILABLE is custom attribute that we have set for each host. Possible values are : “old” and “new”.
** PUBLIC_NETWORK_AVAILABLE = \"new\"
# This was the last step ! You can click on button “Create”.

==== instantiate your VM ====

[[File:Create_Instantiate_opennebula.jpg| 1000px]]

# Back to the table showing all the templates, select the newly created one and...
# ...click on button “Instantiate”

WorkingInT2BCloud

2015-09-01T16:35:05Z

Olivier Devroede: /* instantiate your VM */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg|1000px]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg|1000px]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg|1000px]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
## The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
## And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

===== Template: OS Booting =====

[[File:Create_template_booting_opennebula.jpg|1000px]]

If you want to install the machine with Quattor, it is very important to choose the network as the first boot device, and the hard drive as the second one.

===== Template: IO =====

[[File:Create_template_IO_opennebula.jpg|1000px]]

Choose “VNC” to be able to interact with your VM.

===== Template: Context =====

[[File:Create_template_Context_opennebula.jpg|1000px]]

Unselect the contextualization check-boxes (we don't need it because Quattor will do the job).

===== Template: Context =====

[[File:Create_template_Shedulling_opennebula.jpg|1000px]]

# The scheduling is the step where OpenNebula is selecting an hypervisor to host the VM. In our T2B cloud, some hypervisors are connected to the old public network, and the others are connected to the new public network. If your VM will be in the new public network, you must tell explicitely the scheduler to choose the hypervisor accordingly.
* Remark : PUBLIC_NETWORK_AVAILABLE is custom attribute that we have set for each host. Possible values are : “old” and “new”.
** PUBLIC_NETWORK_AVAILABLE = \"new\"
# This was the last step ! You can click on button “Create”.

==== instantiate your VM ====

[[File:Create_Instantiate_opennebula.jpg| 1000px]]

# Back to the table showing all the templates, select the newly created one and...
# ...click on button “Instantiate”

File:Create Instantiate opennebula.jpg

2015-09-01T16:34:10Z

Olivier Devroede:

WorkingInT2BCloud

2015-09-01T15:38:36Z

Olivier Devroede: /* Creation of VMs */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg|1000px]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg|1000px]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg|1000px]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
## The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
## And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

===== Template: OS Booting =====

[[File:Create_template_booting_opennebula.jpg|1000px]]

If you want to install the machine with Quattor, it is very important to choose the network as the first boot device, and the hard drive as the second one.

===== Template: IO =====

[[File:Create_template_IO_opennebula.jpg|1000px]]

Choose “VNC” to be able to interact with your VM.

===== Template: Context =====

[[File:Create_template_Context_opennebula.jpg|1000px]]

Unselect the contextualization check-boxes (we don't need it because Quattor will do the job).

===== Template: Context =====

[[File:Create_template_Shedulling_opennebula.jpg|1000px]]

# The scheduling is the step where OpenNebula is selecting an hypervisor to host the VM. In our T2B cloud, some hypervisors are connected to the old public network, and the others are connected to the new public network. If your VM will be in the new public network, you must tell explicitely the scheduler to choose the hypervisor accordingly.
* Remark : PUBLIC_NETWORK_AVAILABLE is custom attribute that we have set for each host. Possible values are : “old” and “new”.
** PUBLIC_NETWORK_AVAILABLE = \"new\"
# This was the last step ! You can click on button “Create”.

==== instantiate your VM ====

WorkingInT2BCloud

2015-09-01T15:37:26Z

Olivier Devroede: /* Creation of VMs */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg|1000px]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg|1000px]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg|1000px]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
## The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
## And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

===== Template: OS Booting =====

[[File:Create_template_booting_opennebula.jpg|1000px]]

If you want to install the machine with Quattor, it is very important to choose the network as the first boot device, and the hard drive as the second one.

===== Template: IO =====

[[File:Create_template_IO_opennebula.jpg|1000px]]

Choose “VNC” to be able to interact with your VM.

===== Template: Context =====

[[File:Create_template_Context_opennebula.jpg|1000px]]

Unselect the contextualization check-boxes (we don't need it because Quattor will do the job).

===== Template: Context =====

[[File:Create_template_Shedulling_opennebula.jpg|1000px]]

# The scheduling is the step where OpenNebula is selecting an hypervisor to host the VM. In our T2B cloud, some hypervisors are connected to the old public network, and the others are connected to the new public network. If your VM will be in the new public network, you must tell explicitely the scheduler to choose the hypervisor accordingly.
* Remark : PUBLIC_NETWORK_AVAILABLE is custom attribute that we have set for each host. Possible values are : “old” and “new”.
** PUBLIC_NETWORK_AVAILABLE = \"new\"
# This was the last step ! You can click on button “Create”.

WorkingInT2BCloud

2015-09-01T15:36:20Z

Olivier Devroede: /* Creation of the Template */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg|1000px]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg|1000px]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg|1000px]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
## The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
## And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

===== Template: OS Booting =====

[[File:Create_template_booting_opennebula.jpg|1000px]]

If you want to install the machine with Quattor, it is very important to choose the network as the first boot device, and the hard drive as the second one.

===== Template: IO =====

[[File:Create_template_IO_opennebula.jpg]]

Choose “VNC” to be able to interact with your VM.

===== Template: Context =====

[[File:Create_template_Context_opennebula.jpg]]

Unselect the contextualization check-boxes (we don't need it because Quattor will do the job).

===== Template: Context =====

[[File:Create_template_Shedulling_opennebula.jpg]]

# The scheduling is the step where OpenNebula is selecting an hypervisor to host the VM. In our T2B cloud, some hypervisors are connected to the old public network, and the others are connected to the new public network. If your VM will be in the new public network, you must tell explicitely the scheduler to choose the hypervisor accordingly.
* Remark : PUBLIC_NETWORK_AVAILABLE is custom attribute that we have set for each host. Possible values are : “old” and “new”.
** PUBLIC_NETWORK_AVAILABLE = \"new\"
# This was the last step ! You can click on button “Create”.

File:Create template Shedulling opennebula.jpg

2015-09-01T15:34:20Z

Olivier Devroede:

File:Create template Context opennebula.jpg

2015-09-01T15:32:39Z

Olivier Devroede:

File:Create template IO opennebula.jpg

2015-09-01T15:30:43Z

Olivier Devroede:

File:Create template booting opennebula.jpg

2015-09-01T15:28:44Z

Olivier Devroede:

WorkingInT2BCloud

2015-09-01T15:26:04Z

Olivier Devroede: /* Creation of the Template */

== Golden rules ==
*Before starting, please read the [http://docs.opennebula.org/4.12/index.html doc]
*Never, ever, change the status of a VM using virt-manager ! Do everything using Sunstone only, and nothing else !
*Admin tasks on OpenNebula : most of them requires that you become oneadmin ("su - oneadmin").

== Admin tasks ==
=== How to stop OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
sunstone-server stop
oneflow-server stop
econe-server stop
one stop
</pre>

=== How to start OpenNebula ? ===
Connect as root to the front-end machine, and type the following commands :
<pre>
su - oneadmin
one start
sunstone-server start
</pre>

== Using Sunstone front-end ==

=== Connecting to the Sunstone front-end ===
The Sunstone front-end is installed on dom02. Open a "socks" port to qnat or ccq (or configure your FoxyProxy) to connect to the the following URL :
<pre>
http://192.168.10.35:9869/
</pre>
You will be asked a login and a password.

=== Creation of VMs ===
To create a VM, you have to follow the following steps :
#creation of a disk
#creation of a template using the disk created previously
#instantiation of the template to create the VM
In the following explanations, we will suppose that you want to create a new VM that you want to deploy with Quattor.

==== Creation of the disk ====
[[File:Create_disk_opennebula.jpg]]
#Choose type “DATABLOCK” because you just want a drive (not a CDROM iso, neither a disk with preinstalled OS).
#“Persistent” means the content of the disk image is preserved when the machine is shut down.
#You want an empty drive
#Disk size in MB
#Enable the advanced option to go to the next screen.
[[File:Advanced_disk_opennebula.jpg]]

Set the device prefix to “vd”. This will enable the virtio driver (otherwise VM performance are very poor).
Don't forget to change the disk name accordingly in the hardware template in the SCDB. For example :

<pre>
'harddisks' = dict('vda', create('hardware/harddisk/sas_generic', 'capacity', 60*GB));
</pre>

Next, click Create.
Now your disk is ready and we can apply an opennebula template on it.

==== Creation of the Template ====
===== Template: General =====

[[File:Create_template_opennebula.jpg|1000px]]

#We are using KVM hypervisors.
#VCPU should only be used if you want to “pin” some cores of the hypervisor to your VM, the result being better performances.

===== Template: Storage =====

[[File:Create_template_disk_opennebula.jpg]]

# “Disk 0” is created automatically as a default, but...
# Now, associate it with the disk image you just created (select it in the table).
# Display the advanced options

[[File:Create_template_disk_2_opennebula.jpg]]

# Again, set the device prefix to “vd” to enable virtio driver for better performances.
# Disable disk cache for better performances

===== Template: Network =====

[[File:Create_template_network_opennebula.jpg]]

# By default, “interface 0” is automatically created. Click on the blue button “Add another nic” if you need more network interfaces.
# For each nic created in the previous step, select the virtual network in the above table.
** The usage in the T2B is to place the first nic in the public network (Public_T2B_Fullrange)
** And the second nic in the private network (Private_T2B_Fullrange).
# Display the advanced options (see next slide for explanations).
# Set the IP addresses of the nics (don't forget to do it for all the nics defined in the previous step !). The model should be “virtio” for better performances.

File:Create template network opennebula.jpg

2015-09-01T15:23:41Z

Olivier Devroede:

File:Create template disk 2 opennebula.jpg

2015-09-01T15:21:44Z

Olivier Devroede:

File:Create template disk opennebula.jpg

2015-09-01T15:19:20Z

Olivier Devroede:

File:Create template opennebula.jpg

2015-09-01T15:15:43Z

Olivier Devroede:

WorkingInT2BCloud

2015-09-01T15:13:44Z

Olivier Devroede:

WorkingInT2BCloud

2015-09-01T15:11:52Z

Olivier Devroede:

File:Advanced disk opennebula.jpg

2015-09-01T15:07:11Z

Olivier Devroede:

WorkingInT2BCloud

2015-09-01T15:02:43Z

Olivier Devroede:

File:Create disk opennebula.jpg

2015-09-01T15:01:16Z

Olivier Devroede: