diff --git a/_layouts/redirect.html b/_layouts/redirect.html new file mode 100644 index 0000000..aefe65c --- /dev/null +++ b/_layouts/redirect.html @@ -0,0 +1,13 @@ + + + + + + + + +

Redirecting...

+ {{ site.language.if_you_are_not_redirected_automatically }} {{ site.language.click_here }}. + + + diff --git a/_posts/2014-03-20-New-site-in-egypt.md b/_posts/2014-03-20-New-site-in-egypt.md index ca6e4e6..f89ce33 100644 --- a/_posts/2014-03-20-New-site-in-egypt.md +++ b/_posts/2014-03-20-New-site-in-egypt.md @@ -1,12 +1,12 @@ --- layout: post -title: Marhaba Egypt ! +title: Marhaba Egypt description: Egyptian Network for High-Energy Physics deploys site into AAROC headline: Egyptian Network for High-Energy Physics deploys site into AAROC modified: 2014-03-20 category: new-sites tags: [welcome, Egypt, new, sites, deployment] -image: +image: feature: ENHEP-banner.gif comments: true mathjax: @@ -18,6 +18,6 @@ After KENET, DIT and CNRST, we've got a new site on the ROC, hailing all the way # Status of ASRT ENHEP site -We've added the new site to the GOCDB and handed over ownership of it to the site administrators. The site BDII is happily reporting that services are up and running and nagios agrees. Once we've got the MERAKA dev site finished (see our [work with Ansible](https://github.com/AAROC/ansible-for-grid), we'll be able to start certification of the site. +We've added the new site to the GOCDB and handed over ownership of it to the site administrators. The site BDII is happily reporting that services are up and running and nagios agrees. Once we've got the MERAKA dev site finished (see our [work with Ansible](https://github.com/AAROC/ansible-for-grid), we'll be able to start certification of the site. This should be done by early next week, *insha'Allah* ! diff --git a/_posts/2014-03-20-first.md b/_posts/2014-03-20-first.md index 29f7163..400ea59 100644 --- a/_posts/2014-03-20-first.md +++ b/_posts/2014-03-20-first.md @@ -39,7 +39,3 @@ Perhaps the most satisfying development we've had in the last few months is the # It's dangerous out there, take this Research is a fun place to work, specifically because it's confusing, exciting, challenging and changing constantly. We'll always be putting out fires with angry cats and telling our stories over beers; hopefully with a few less bearded faces than we currently have, if you know what I mean. We're never going to be able to automate our operations and provide the right training and documentation that we need for our team to be perfect. It's a constant learning curve - but at least that curve can be integrated, hopefully to something that converges (sorry - math joke). We are working on some cool stuff with our friends all over the world to alleviate the load on our humans. This blog will, hopefully, tell the tale of how the we learned to stop putting out fires with cats and learn to trust the robots and our rational side instead - -{% if page.discourse %} -
-{% endif %} diff --git a/_posts/2014-11-26-Terre-des-hackers.md b/_posts/2014-11-26-Terre-des-hackers.md index b4361f8..c289471 100644 --- a/_posts/2014-11-26-Terre-des-hackers.md +++ b/_posts/2014-11-26-Terre-des-hackers.md @@ -17,7 +17,7 @@ The panel consisted of Peter van Heusden (University of the Western Cape), Jonah Images are courtesy of [the Saint-Exupéry Foundation](http://www.antoinedesaintexupery.com). The thoughts revolve around quotes which I've selected from the book "Terre des Hommes".
- +
---------------------------- @@ -50,7 +50,7 @@ There is sometimes a tension then between *getting things done* and *getting thi We come then to a metaphor :
- +
"L'homme se découvre quand il se mesure avec l'obstacle."
- A. de Saint-Exupéry"
A dejected pilot stands beside his crashed airplane. He, like us, is an explorer. He has chosen to fly to new lands, and has crashed in a desert - land unknown to human feet. He will eventually repair his airplane, or be rescued by his fellow explorers, but has only the tools at hand to survive in the meantime. Not knowing what awaits him, he has taken on that airplane what one might call a "general solution" - the basic tools which can be used in any situation, given enough ingenuity and patience. A hammer, a radio transmitter, a wrench, a compass, a blowtorch, a warm jacket, a rifle (let us not forget that he has crashed in a very hostile territory). @@ -61,9 +61,9 @@ These are his tools for *disaster recovery*, but but it is above all his ***aero > [...] la vie du passé nous semble mieux répondre a notre nature, pour la seule raison qu'elle répond mieux a notre langage. -We are presented with an instrument of discovery, but it seems from "the future". Its controls, it's internal functioning, are exposed and seem foreign to us and we often find ourselves unable to find the terms needed to express our need for or usage of it. Sometimes, this makes it hard to ask for ask for newer, or better aeroplanes... after all, if it is only to deliver packages, why we can already do that with a boat or a train ? And these don't crash in the middle of the desert ! Yes, but aeroplanes go where boats or trains cannot, they see from a different angle, and from their altitude, the world takes on a vastly different aspect. +We are presented with an instrument of discovery, but it seems from "the future". Its controls, it's internal functioning, are exposed and seem foreign to us and we often find ourselves unable to find the terms needed to express our need for or usage of it. Sometimes, this makes it hard to ask for newer, or better aeroplanes... after all, if it is only to deliver packages, why we can already do that with a boat or a train ? And these don't crash in the middle of the desert ! Yes, but aeroplanes go where boats or trains cannot, they see from a different angle, and from their altitude, the world takes on a vastly different aspect. -St. Exupéry's point here is that we are beings bound by the language we speak, the terms we use - and often our reticence to adopt new ways is due to our sense of being at a lack of words. It is in our nature to explore, but in exploring, we need to remind ourselves that it end, not the means which drives us. +St. Exupéry's point here is that we are beings bound by the language we speak, the terms we use - and often our reticence to adopt new ways is due to our sense of being at a lack of words. It is in our nature to explore, but in exploring, we need to remind ourselves that it is the ends, not the means which drives us. > Nous sommes tous de jeunes barbares que nos jouets neufs émerveillent encore. […] @@ -79,7 +79,7 @@ Yes, we, these explorers, do tend to get blinded by the shiny. We forget that *l We forget that the aeroplane was made for a *reason*, which was to arrive somewhere. The very first ones were built essentially for the pilot, whose driving passion is to discover the unknown through discovery. But later ones were built for *passengers*, whose goal is simply to *arrive*. Their passion is the relative, or the business, or the exotic fruit, at the end of the journey and for them the aeroplane, although perhaps intriguing, is not of primary importance. -How was the aeroplane built ? The very first ones had all of the tubes, knobs, dials and guages in plain site (if one will forgive the homonymic pun), because the pilot needed to know every detail of the internal working of the aeroplane. However, later models hid these details both from pilots as well as of course from the passengers, since we came to learn the habits and workings of the machine. We made it less mysterious, and more functional, to respond better to our human, (or in this case, scientific), rather than technical needs. +How was the aeroplane built ? The very first ones had all of the tubes, knobs, dials and guages in plain sight (if one will forgive the homonymic pun), because the pilot needed to know every detail of the internal working of the aeroplane. However, later models hid these details both from pilots as well as of course from the passengers, since we came to learn the habits and workings of the machine. We made it less mysterious, and more functional, to respond better to our human, (or in this case, scientific), rather than technical needs. ## What home awaits us ? @@ -130,7 +130,7 @@ What kind of learning environment do we want for our future generations ? And wh > And all the boards did shrink;
> Data, data, every where,
> Nor any drop to drink
->

Samuel Taylor Coleridge, "The Rime of the Ancient Mariner"

+>

Not Samuel Taylor Coleridge, not "The Rime of the Ancient Mariner"

They have been told that such marvels exist, but how to use them, and what is actually offered is somewhat different. In order to build a "fertile delta", there needs to be better integration between training, research and innovation, especially mutually-reinforcing aspects. diff --git a/_posts/2014-12-31-Standby.md b/_posts/2014-12-31-Standby.md index c2a11dd..8d0a502 100644 --- a/_posts/2014-12-31-Standby.md +++ b/_posts/2014-12-31-Standby.md @@ -63,7 +63,7 @@ I, for one, am tired of writing reports and emails that few people read. If some ## Quick and dirty dashboard -Finally, we're working on a small, simple [dashboard]({{ site_url/SitRep }}) to give a snapshot of the state of our core services, but also those not covered by SAM. This is not meant to be a reimplementation of the [Operations Portal](http://operations-portal.egi.eu), or the [Virtual Organisation portal](http://http://operations-portal.egi.eu/vapor). It will give simple info about the state of the services which we use which are *not* included therein - the core services, the dev cluster, various websites etc that are outside of the realm of the grid, but still important to daily life of the ops team and relying communities. +Finally, we're working on a small, simple [dashboard]({{ site_url }}/SitRep) to give a snapshot of the state of our core services, but also those not covered by SAM. This is not meant to be a reimplementation of the [Operations Portal](http://operations-portal.egi.eu), or the [Virtual Organisation portal](http://http://operations-portal.egi.eu/vapor). It will give simple info about the state of the services which we use which are *not* included therein - the core services, the dev cluster, various websites etc that are outside of the realm of the grid, but still important to daily life of the ops team and relying communities. # Watch this space - or help out ! diff --git a/_posts/2015-06-07-Dissemination-beyond-the-project.md b/_posts/2015-06-07-Dissemination-beyond-the-project.md index e8349ed..6840e4d 100644 --- a/_posts/2015-06-07-Dissemination-beyond-the-project.md +++ b/_posts/2015-06-07-Dissemination-beyond-the-project.md @@ -46,8 +46,23 @@ We can use these to *publish* our articles, as well as invite others to publish This is a blog which the members of the Regional Operations Centre can contribute to. This blog tells the story of e-Infrastructure in Africa, where it comes from, what's currently happening and where it sees things going. Many of the articles are republished in [Open Science in Africa](https://medium.com/open-science-in-africa). Contributions are simply commits or pull requsts to the [repo](https://github.com/AAROC/aaroc.github.io), making it easy to contribute. -I'd like to be able to catalogue and link other interesting articles in this topic - please [reply with suggestions at the tpoic on the forum](http://discourse.sci-gaia.eu/t/where-are-we-disseminating-our-work/55) +I'd like to be able to catalogue and link other interesting articles in this topic - please [reply with suggestions at the topic on the forum](http://discourse.sci-gaia.eu/t/where-are-we-disseminating-our-work/55) + +
# References and Footnotes + [^Cover]: The cover image is used with permission from [Flikr User antefixus U.E.](https://www.flickr.com/photos/21728045@N08/11200960143/in/photostream/) + + + diff --git a/_posts/2015-06-16-Announcing-PerfSONAR.md b/_posts/2015-06-16-Announcing-PerfSONAR.md new file mode 100644 index 0000000..d3fda6b --- /dev/null +++ b/_posts/2015-06-16-Announcing-PerfSONAR.md @@ -0,0 +1,74 @@ +--- +layout: post +title: "PerfSONAR by SANREN" +description: Ever wanted to know how the network is doing ? +headline: The South African NREN has got network performance covered +category: blog +tags: [Announcement, perfSONAR, SANREN, network, performance, open infrastructure] +image: + feature: spidernet.jpg +comments: true +discourse: false +--- + +# TL;DR - End-to-end performance is hard, SANREN has your back, with perfSONAR. + +Applications in a distributed environment can depend critically on the performance of the network over which they run. Getting the most out of the network involves first understanding where the bottlenecks are; SANREN's got you covered with perfSONAR. + +# The SANREN backbone and the rest of the network + +The South African NREN consists of a backbone connecting the main nodes at Universities across the country, as well as main laboratories and research infrastructure. This represents a game-changing investment in research infrastructure in South Africa, bringing researchers closer together and enabling a wide range of tools and services that were not feasible before. + +The 10 GB/s backbone is extended from the nodes to the various institutes which are served by the NREN in a more capilliary fashion. From the pops to the campuses to the LANs and eventually the end-user's device (phone, laptop) or srever in a data centre. This complexity is often overlooked, and the beautiful, impressive simplicity of one number - the core backbone bandwidth - seduces us into thinking that we're suddenly going to shift data at light speed. + +# Understanding end-to-end performance + +We expect that the 10 GB/s of the backbone is translated into our actual experience of the application at hand, ignoring the fact that these applications required data to move in something less like a straight (pipe)line and more like a massive delta. The *actual* performance of the application is often determined by the largely by the slowest component in it, not by the fastest. This may be anything from a congested switch to a misconfigured firewall or simply the network card installed on the receiving end. Aspects such as the kernel configuration of the sending and receiving machines - how it is configured to process the data coming over IP, and how this compares with the physical characteristics of the hardware - can also have a huge, unexpected impact. + +Most of our network devices are configured for reliability and for handling typical traffic on the web, not the massive sustained throughput needed by advanced research applications. It is not uncommon to sense frustation in a user's communcations when they are told that the university has 10 GB/s connectivity, but they are only experiencing orders of magnitude less than that. Understanding what to expect comes from knowing the relationship between the data you want and everything between it and the location in which it needs to be processed. Likewise, getting the most out of backbone investment like SANREN comes down to identifying and optimising every component on a path. + +While it's fairly easy to do this for the backbone components, the complexity of the system - due to the number and variety of components - lower down the line, is a severe challenge. In order to deliver the best service possible and get the most out of a massive investment, a special instrument is needed to probe the performance of the network *on specific paths* - from end to end. + +# Enter perfSONAR + +
+ +
+ +The tool for this job has been developed over decades of research in network engineering : [perfSONAR](http://www.perfsonar.net). In their own words - + +> "perfSONAR is a network measurement toolkit designed to provide federated coverage of paths, and help to establish end-to-end usage expectations. There are 1000s of perfSONAR instances deployed world wide, many of which are available for open testing of key measures of network performance. This global infrastructure helps to identify and isolate problems as they happen, making the role of supporting network users easier for engineering teams, and increasing productivity when utilizing network resources. " + +PerfSONAR provides a set of sensors which collect performance data on network traffic, and there are instances all across the globe, helping to identify and diagnose issues across almost any path that modern research data can travel. This is an extremely powerful tool. + +# PerfSONAR in South Africa + +PerfSONAR in South Africa has been operational for some time - since 2012 in fact - and has already led to significant improvements in data throughput from international laboratories like [CERN](http://www.cern.ch) to South Africa, supporting high-energy physics experiments, *e.g.* [ALICE](http://www.aliceinfo.cern.ch) and [ATLAS](http://www.atlas.ch). With currently 13 permanent nodes and the full backbone covered, it is firmly a part of the international perfSONAR network. + +
+ + +Location of perfSONAR sites in South Africa, from the perfSONAR service discovery page. Image courtesy Roderick Mooi. + +
+PerfSONAR is now a fixed feature of the South African NREN landscape and is used on a daily basis to support optimisation and improvement of the research network. It provides valuable supporting information to network engineers and administrators which need to identify bottlenecks and efficiently take action to resolve it - avoiding the usual "it's your side !" , "no it's your side" back and forth that can so often define network performance debungging. This is, in the final analysis, a great move for users, who get to experience the fastest possible network for their applications. + +# Now that we've found love... + +Of course, tools like perfSONAR only help to identify problems and misconfigurations, they don't automagically *fix* them; that would be just a little *too* awesome :wink:. Luckily there are a lot of proactive ways to address end-to-end performance tips and tricks which can be applied to speed up network transfers, from using different tools to tuning kernel parameters. The good folks at [Faster Data](http://fasterdata.es.net/) provide a comprehensive knowledgebase, which you can refer to if you want to squeeze every last bit of your available bandwidth. You may never get to the golden 10 GB/s, but hey at least you'll sleep better at night knowing there's just nothing more you can do ! + +# To know more + +If you want to find out more about what perfSONAR take a look at the [perfSONAR website](http://www.perfsonar.net) and links therein. A good resource for analysing end-to-end performance is the [ESNet](http://www.esnet.net) knowledgebase and links therein. + +To find out more about how perfSONAR is improving the use and capability of the NREN in South Africa, take a look at [Roderick's slides from TNC 2015](https://tnc15.terena.org/core/presentation/199) - where he goes into depth about the system's use in South Africa. If you're interested how perfSONAR could benefit you locally, don't hesitate to get in touch with Roderick Mooi (rmooi.at.csir.co.za) or Kevin Draai (kdraai.at.csir.co.za) at SANREN. + +Lastly, to use the SANREN perfSONAR tools, take a look at http://perfsonar.sanren.ac.za + +Make that data flow ! + +{% if page.discourse %} +# Discussion +
+ +{% endif %} diff --git a/_posts/2015-07-08-Top-bdii-restart.md b/_posts/2015-07-08-Top-bdii-restart.md new file mode 100644 index 0000000..5f333b6 --- /dev/null +++ b/_posts/2015-07-08-Top-bdii-restart.md @@ -0,0 +1,13 @@ +--- +layout: post +type: status +title: Top-BDII restart +description: Service restart notification +headline: It's dead, Jim ! +category: ops-updates +tags: [AAROC, bdii, operations, updates] +image: + feature: servicedied.jpg +comments: false +--- +The top-bdii at ZA-MERAKA has crashed, raising an alarm on the ops portal and causing several site probes to fail. The service has been restarted. A ticket recently opened will soon be closed. diff --git a/_posts/2015-07-10-CVE-2015-1793.md b/_posts/2015-07-10-CVE-2015-1793.md new file mode 100644 index 0000000..5f2b379 --- /dev/null +++ b/_posts/2015-07-10-CVE-2015-1793.md @@ -0,0 +1,25 @@ +--- +layout: post +type: status +title: A high-severity openssl vulnerability has been announced CVE-2015-1793 +description: Certificate chain verification vulnerability announcement CVE-2015-1793 +headline: Time to update your ssl (again !) +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2015-1793] +image: + feature: openssl_cve_2015_1793.png +comments: false +--- + +A new [security advisory](https://www.openssl.org/news/secadv_20150709.txt) from the OpenSSL project relating to versions starting at 1.0.1n 1.0.2b. + +**This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.** + + 1. OpenSSL 1.0.2b/1.0.2c users should upgrade to **1.0.2d** + 1. OpenSSL 1.0.1n/1.0.1o users should upgrade to **1.0.1p** + +If you need direct support from the CSIRT, please contact Roderick Mooi (rmooi.at.csir.co.za) + +## Updates + +**Update** - According to [RedHat](https://access.redhat.com/solutions/1523323) this CVE does not affect them. Presumably this includes derivates. Thanks @bazinski diff --git a/_posts/2015-07-14-CVMFS-update.md b/_posts/2015-07-14-CVMFS-update.md new file mode 100644 index 0000000..e2a936f --- /dev/null +++ b/_posts/2015-07-14-CVMFS-update.md @@ -0,0 +1,73 @@ +--- +layout: post +type: post +title: Iterating CVMFS +description: 'An update on our quest to deliver applications' +headline: 'Step 1: RTFM; Step 2: Repeat; Step3: Do it right this time...' +modified: +category: blog +tags: [cvmfs, CODE-RADE, CVMFS] +image: + feature: patience-yoda.jpg + attribution: 'http://quotesfans.com' +comments: true +mathjax: +discourse: true +--- + +# TL;DR + +A quick update on the work we're doing in the [CODE-RADE](https://github.com/AAROC/CODE-RADE-project) to bring a continuous delivery capability to the applications which can run on our infrastructure. A workflow to test the delivery of applicaitons in CVMFS needs to be implemented *and it better be automated*. + +# The problem at hand + +So, we've gone to quite a significant length to develop a platform which allows almost anyone to contribute applications to the ROC's repository. By sending a pull request or a commit directly to a repo in [https://github.com/SouthAfricaDigitalScience] -- but what happens when an application is built ? + +Applications are "delivered" to the sites via [CVMFS](http://cernvm.cern.ch/portal/cvmfs)[^maybedocker]. + +We need it to be checked against itself, but also run from the CVMFS repo to make sure that when it gets out into the "wild" - on the sites that mount the repo and execute the applications. One of the reasons we chose CVMFS as a delivery mechanism was to give the site administrators less overhead in managing applications. + +# Basic Workflow + +
+ +
Figure 1: What happens once we've built the application ?
+
+ +The part of the workflow representing testing and integration shown in [Figure 1](#Figure 1) is the meat of the problem - how do you reliably test user-contributed applications before integrating them into a repository which will be used at all sites ? - but the issue still remains of *actually getting the software into the repo*. Let's take a closer look at that... + +## Slightly more detailed workflow. + +So, once we have concluded the workflow in [Figure 1](#Figure 1), some orchestration has to happen : + + 1. On the build node: + 1. shift new artifacts into the CVMFS server + 1. unmount the dev repo + 1. On the CVMFS server: + 1. Put cvmfs dev repo into transaction + 1. Run regression tests on the new code - this includes all of the functional tests of all of the existing applications, _as well as_ the new application. + 1. If all pass, publish the new dev repo + 1. On the build node: + 1. mount the dev repo + 1. run regression tests + 1. Send a message that the new application has passed all tests + +:hurtrealbad: ***It is now time for a human to take over and pull the code into the production repo which is mounted on all the sites.*** :hurtrealbad: + +Unless I'm missing something obvious, this is the slightly more detailed workflow.... before you get all excited about publishing containers and all, Yoda has a message for you: + + + +That will come, that will come. In the meantime, go listen to some rad music: + +
+ + + +
+ +... till next time ... :wave: :octocat: + +# Footnotes and References + +[^maybedocker]: The choice of CVMFS was made as it is the only high-performance read-only delivery mechanism out there, currently used heavily and well-tested by the WLCG VO's. It's not the only choice and we want to make delivery possible via Docker as well. More on that later. diff --git a/_posts/2015-07-24-CVE-2015-3246.md b/_posts/2015-07-24-CVE-2015-3246.md new file mode 100644 index 0000000..85b8ac1 --- /dev/null +++ b/_posts/2015-07-24-CVE-2015-3246.md @@ -0,0 +1,47 @@ +--- +layout: post +type: status +title: A CRITICAL-severity libuser vulnerability has been announced CVE-2015-3245. +description: EGI SVG Advisory 'Critical' risk libuser local root exploit for RedHat and derivatives. +headline: Users, though shalt not pass(word) ! +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2015-3246] +image: + feature: 'CVE-2015-3246.jpg' + attribution: "DeviantArt user Anna-Yaina - http://anna-yaina.deviantart.com/" +comments: false +--- + +# CRITICAL severity means take action now + +A new critical vulnerability [has been announced](https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts/libuser-2015-07-24) by the [EGI CSIRT](https://wiki.egi.eu/wiki/EGI_CSIRT:Alerts). From the advisory : + +> This vulnerability is present in the case of access via a local user account and its password. + +Most of the back-end infrastructure is safe (at least, in the "grid" world), since : +> Fortunately much of the access to the EGI infrastructure is NOT via this method; so much of the EGI infrastructure is not likely to be affected. + +This is true of AAROC sites as well... BUT : + +> However, if access via login with a local user and password is enabled, then sites should act +> quickly to update. One scenario in EGI where access is likely to be via this method is where +> User Interfaces (UIs) are made available with a local passwd file. + +# Perun, take the wheel ! + +**Some** of our UI's are managed by [Perun](https://perun.c4.csir.co.za), which is not affected, but if you are allowing user login with password, please take immediate action. + +Essentially this means + +``` +yum update libuser +``` + +Stay safe and have a good weekend, y'all :smile: + +# Updates + +**Update 2015-07-30** + +As question on the target of the advisory were raised, sites are reminded that this advisory applies to all system with libuser installed and thus that they are expected to update to a non-vulnerable version. +However, as for any vulnerability, sites can apply temporary mitigation (see the recommendations) if an update is not an option. diff --git a/_posts/2015-07-27-CODE-RADE-Real-World.md b/_posts/2015-07-27-CODE-RADE-Real-World.md new file mode 100644 index 0000000..81e5a85 --- /dev/null +++ b/_posts/2015-07-27-CODE-RADE-Real-World.md @@ -0,0 +1,144 @@ +--- +layout: post +title: CODE-RADE in the Real World +description: 'What use is a user if the infrastructure is useless ?' +headline: "Let's get rid of those bottlenecks and get our science on !" +category: blog +tags: [blog, HPC, CODE-RADE, automation, jenkins, github, rock n roll] +image: + feature: bottleneck.jpg + attribution: +comments: true +mathjax: +discourse: false +--- + + +# TL;DR: We are building some awesome technical automation to deliver applications - but how does the actual intended audience actually use it ? + +Whoa ! That's a mouthful, even for a quasi-abstract, but stick with me, this one is all about "Ok, now what ?". The time has come to get real with CODE-RADE project, after many many months of laying down foundations. The basic premise of the project is to demolish the barrier to entry for new applications, by + + 1. Judicious use of web technologies + 1. Heavy use of automation + +Basically, we want a user or research group to propose an application that they want, _literally by sending a pull request_, have some fancy robots take over from there, then a few days later have the user submitting jobs to the grid with their new shiny. + +Delivering applications should be a simple as pushing a few commits to a repo; executing that application in a workflow should be as simple as writing a script that says not much more than + + + # Add the AAROC deployed apps module + module add deploy + # Add myApp and dependencies + module add myApp + # SCIENCE ! + . . . my_workflow . . . + + +# Step 4 - Profit ! + +
+ +
This is most likely attributable to a South Park episode, but since this is the internet, who knows anymore !
+
+Unless you've been living on Mars until just this moment, or are reading this blog post from the [New Horizons](https://www.nasa.gov/mission_pages/newhorizons/main/) probe, you probably know the [Profit !!! meme](http://knowyourmeme.com/memes/profit). + + If not[^HiMars], here's how it works : + +> You have a goal, and you have a vague idea of how to reach it. The first two steps are easy, then some magic happens, finally, PROFIT !!! + +I propose that this is usually the case for researchers - they *know* their application better than the infrastructure operators do, and they usually know how to build it and execute it. The infrastructure operators, however, know how to deliver applications to their users - they might have some local customisations at their sites for how they deal with users, parallelism, file systems etc. In this analogy, the user[^UserResearcher] would know the first two steps of their goal-oriented path : + + 1. Compile the application against it's respective dependencies + 1. Check that the application executes correctly + +while the operator knows the other side of that model, and can ensure that the application is in the right path with the right permissions, etc. + +# A bit of background. + +Before we get into the steps that a user would need to take *right now* to deploy their application to the grid, let's take a brief look into the past. + +## No-one said it would be easy... + +Getting applications onto the infrastructure was one of the main blocking aspects of SAGrid, and most national distributed computing platforms. Without being able to run their code or workflows in a reasonable time, users and entire communities get discouraged and - in some cases - turn to home-brew solutions. However, the model we had in place assumed that there was an impermeable barrier between the user and the infrastructure, with the *"Software Manager"* playing the role of "priest", interceding for the user to the infrastructure's operations team. Essentially, this created a huge bottleneck, because special jobs had to be created, to be submitted site-by-site, in order to install the applications. What is more, functional checks were rarely made on the deployed applications, and updates to the packages were not guaranteed - they needed to be manually updated. + +## No-one said it should be this hard + +Wow, looking back that was quite *dumb*, for lack of a better word. Yes, we had nothing else to work with, and yes, *everyone else was doing it*, but that doesn't mean we can't make it less stupid ! We wanted to re-design the process so that it was more _user driven_ and _parallel_ than previously, with as few as possible bottlenecks. Essentially, we wanted to make the impermeable wall permeable, but brokering some trust between user and operator. All the user had to do was show the operator how the application had to be built; all the operator had to do was ensure that trusted applications were always available. Since most of the support effort previously was spent on ensuring that applications were compiled and linked correctly, and tracking down runtime errors, we wanted to eliminate or drastically reduce the occurence of these. The operators would be saying "ok, prove to me that you can execute in this environment witout doing bad things". + +# The Two-Way Mirror + +What if all the testing, checking and execution could be automated in some way ? A tireless robot could realistically test all desired configurations of an application, and could do so in an unbiased way - such that both the operator and the user could refer to the same build and say "yep, looks good". This is a kind of "two-way mirror", where the user can make verifiable statements about the application, and the operator can make verifiable statements about whether that application will execute on the remote side of the infrastructure[^BasicallyWN]. In the middle there is some opaqueness to both sides, but there is enough transparency to engender trust. + +
+ +
The jenkins magic
+
+ + +This is the basis of the trust brokerage and we've implemented it with [Jenkins](http://jenkins-ci.org). The details of the Continuous Integration setup for AAROC have been described at various previous posts in this blog and other slide decks, and here we want to focus on the user side of the process. What does a user have to do, step-by-step, in order to get their application to a point where it's executable ? + +# Your move, user... + +Let's start by putting the ball in the user's hand - we expect the user to prepare at least two scripts, and to place them in a change-controlled repository. As a default approach, this repo would be on [Github](https://github.com)[^NotJustGit], containing: + + 1. A `README` telling us what the application is and what dependencies it needs + 1. A `build.sh` script which **only** compiles the code and produces binary and library files (this is somtimes trivial, in the case of precompiled code) + 1. A `check-build.sh` script which provides a functional test of the code, as well as creates a modulefile for + +## Fork the demo repo + +Fork the [My-First-Deploy](https://github.com/SouthAfricaDigitalScience/my-first-deploy) repo to get an idea of what's going on; there's a nice README in there which explains how things work and where to get help. + +## Mount the CVMFS repo. + +All of the applications that have already been tested are already in the CVMFS repo, which you can easily mount on your laptop or local cluster. + +------- +

Instructions for mounting our CVMFS repositories

+ +-------- + + +We've even got a nice [playbook](https://github.com/AAROC/DevOps/blob/master/Ansible/cvmfs.yml) that you can use to make your machine a CVMFS client :smile:. This will give you direct access (via fuse) to the existing repo, and allow you to build code against the libraries therein. + +## Make sure it builds + +Your next task is to make the application build on something that you know - something "Linux" that is. Your main aim is to prove to the operators that the application will run, and they are operating a CentOS-based infrastructure. Some sites deploy Debian worker nodes too, which is why we have the Debian build slave - so basically if you can write a script that will compile your application against the libraries in CVMFS (and **only** those), then it will pass the first phase of testing. At this point, you can send a pull request and we can create the job to test the code on Jenkins. The script should be called `build.sh` for conventional reasons. + +***From here on out, every commit will trigger a Jenkins build*** + +## Make sure it runs + +Once you've made it compile, the next step is to prove that it will not give runtime errors. This means that a modulefile needs to be created for the application and a short script, by convention called `check-build.sh` is executed to load the modulefile for the applicaiton and execute functional tests. These tests have to be provided by you, the requestor, since you're the expert after all ! + +# Green Lights ! Ansible ! Transaction ! + +Once the `check-build` phase has successfully completed, a manual promotion is needed. We want this to be one of the few human steps to be made in the workflow, and we have to maintain some form of human interaction, mostly for quality and accountability reasons. Once a check has been made on the artifact, and perhaps a few messages have been exchanged between developer and expert, the application can be pulled into the `dev` repository. + +This involves putting the CVMFS repo into a "transaction" - a write-enabled mode in which updates of the repo can be made - and publishing a new version of the repo. All of this happens "behind the curtains", so to speak, from the user's point of view. All that they should see is a message somewhere that says something like + +> A new version of the repository has been published in the `dev` repository - +> Changelog: "New application xyz added after successful build, requested by so-and-so" + +## Real-world testing + +Now, the application is out there "in the wild" - albeit in a testing repository. Certain sites, and the user themself can test the application in a wider sense than the narrow infrastructure-focussed tests that Jenkins runs. After a brief period of testing, and consensus from the production sites, we can move the application into the production repository. + +This intermediate step can of course be considered optional, and skipping it could speed up deployment in most cases, but it is useful to have it in the workflow, to ensure that sites have informed consensus on what they are executing. Since the repo is mounted permanently, no action is taken on the site operator's behalf in order to deliver the application - **this is a feature**. + +# Go wild ! :tada: + +So, at this point, the application is _executable_ out there in the world. All we need to do is keep track of who is mounting the repo - which is usually published in the site-BDII. If updates to the application are made, they are user-triggered, and the operations team is consistently kept in the loop thanks to the continuous integration system. New versions of the application can be developed, and continuously tested, until arriving again at that most beautiful of all sights : ![all green]({{site_url}}/images/passing.svg) + +Continuous delivery - that's where we want to be. + +# Bonus points + +Bonus points to anyone who can mention the songs referred to in this post in the comments below. + +# References and Footnotes + +[^HiMars]: If you really have been living on Mars, well done, you are what humanity has been searching for, for millenia. Please make yourself known to one of our friendly visiting robots ! +[^UserResearcher]: I'm using "user" and "researcher" interchangeably throughout this article - what I mean here is "the entity who knows and uses the application". These may be different people, but the system is set up to handle this - the important point is that they are *different* from the operators. +[^BasicallyWN]: What we mean here by "remote side of the infrastructure" is basically "a worker node". This is being simulated as a specific execution environment (shell) on the build slaves, which is very similar to a worker-node, having all of the middleware and dependencies that a real worker node would have (and no more), but the "remote side of the infrastructure" can also be considered something that is outside of the authentication realm - a user interface or personal laptop for example. Since we have the possibility to simluate many different environments with Jenkins, simultaneously, we can acount for almost any site configuration. Currently, there are only SL6 and Ubuntu 1404 build slaves. +[^NotJustGit]: We really like Github because of the nice API it provides developers with, but in principle this could be any svn or git repo. Basically, we just need to know when changes are pushed to the repo, so that Jenkins can trigger the job. diff --git a/_posts/2015-08-05-DevOps-Manual.md b/_posts/2015-08-05-DevOps-Manual.md new file mode 100644 index 0000000..45b61b3 --- /dev/null +++ b/_posts/2015-08-05-DevOps-Manual.md @@ -0,0 +1,52 @@ +--- +layout: post +title: '"Manual" vs "DevOps" - which is better ?' +description: 'How should we teach the deployment, operation and maintenance of e-Infrastructure services ?' +headline: "Of course, both." +category: blog +tags: [blog, DevOps] +image: + feature: sciencepattern.png + attribution: http://thepatternlibrary.com/#science +comments: true +mathjax: +discourse: true +--- + + +This question arose during an email exchange with colleagues from [CESNET](http://www.cesnet.cz/?lang=en) recently, in the context of the upcoming [workshop on identity federations](http://osscom2015.osscom.org/?q=content/workshop-joining-eduroam-and-identity-federation) at the [OSSCOM](http://osscom2015.osscom.org/) conference. There will be an _install fest_ :tada: + +# How should we teach and collaborate ? + +This is great, but there are different philosophies about going about this. Essentially, everyone can agree that we don't want to have "black box" solutions for eduroam and other federated identity services - this may solve an immediate need, but can create a clientele system where remote experts are needed to operate local services. Also, everyone can agree that _learning_ how services work is a good idea, and that _knowledge transfer_ is part of the desired process. + +The question then becomes - **How do we teach the installation, operation and maintenance of these services in a sustainable way** ? + +While a student is in the classroom, during the event, it's arguable - but by no means guaranteed - that they will have a clear understanding of the technology thanks to their contact with the demonstrator/lecturer ; but what about those who are not able to attend ? What happens _after_ the event ? + +The approach we've taken in the [Africa-Arabia Regional Operations Centre](http://www.africa-grid.org) is to develop functional descriptions of services using [Ansible](http://www.ansible.com) and [Puppet](http://www.puppetlabs.com) which not only _document_ the procedure, but also _implement_ it. + +# Procedures versus states. + +So, while a manual, step-by-step approach can highlight and explain aspects in a procedural way, a DevOps approach can do the same, but in an _idempotent_ way. The difference is that if you go through the manual and follow all the steps to a tee, you should end up with a working system. Ok great ! Now, peturb that system a little - change a variable, update a package, etc - the manual is out of date and needs to be followed again from the starting point. Also, configuration drift can easily occur and usually can't be remotely verified without some form of intrusion (either authorised or not...) + +On the other hand, an Ansible playbook makes statements about the desired _state_ that aspects of a service should be in - + + * `a certain file should exist and have certain contents` + * `connectivity to this host should happen on such-and-such a port` + * `a certain process should be started and should belong to a certain user` + +It lets the developer focus on the _what_ and leave the _how_ to the orchestration engine. + +> This is code. + +And as code, it can be version controlled, tested, forked. + + +This is why we are pushing the DevOps model, and encourage anyone in the region to collaborate with us by using and contributing to the [DevOps](https://github.com/AAROC/DevOps) repository. We hope to do the same for radius server installation and are planning to do this for the Shibboleth-3 deployments soon after August. + +# Reproducible deployments + +By abstracting and co-ordinating _roles_ (ie, services configured in a certain way) we can allow sites to easily whip up complex configurations of services quite easily. But best of all, it's reproducible. We can and do test roles while developing them, and this provides us with good reference examples (this is done in the `dev` branch, if anyone is listening). Once these are known to give the desired end states, they can be forked and used to instantiate specific states, using different variables site by site. This makes it easier to identify and resolve problems - as well as make the return on investment in time spent during a workshop far greater. + +So - will you teach the "DevOps" way in your next eduroam, identity federation, `` workshop ? diff --git a/_posts/2015-08-20-CODE-RADE-Community-Call.md b/_posts/2015-08-20-CODE-RADE-Community-Call.md new file mode 100644 index 0000000..b676072 --- /dev/null +++ b/_posts/2015-08-20-CODE-RADE-Community-Call.md @@ -0,0 +1,102 @@ +--- +layout: post +title: 'CODE-RADE Community Call' +description: 'Community call for the CODE-RADE project - Week 35 (2015)' +headline: "It's not called *continuous* integration for nothing." +category: blog +tags: [blog, CODE-RADE, sitrep] +image: + feature: + attribution: +comments: false +mathjax: false +discourse: false +--- + +# Community Calls + +The project is gaining steam and we want to have a recurrent +Our first community call for CODE-RADE just happened in the [AAROC mconf space](http://mconf.sanren.ac.za/webconf) +If you want to comment or discuss this call, head over to [the discussion forum](http://discourse.sci-gaia.eu/t/code-rade-community-call-week-35) + + +# Roll-call + +Present were @dmakweba Sean from TLABS, @smasoka and myself. We'd like to start small, keep the door open and slowly grow the project... + +It seemed that there were some problems with the mconf system - @smasoka and I managed a stable connection, but Sean got kicked out due to instability and @dmakweba couldn't hear very well. + +# On the Agenda + +## Website + +The project needs a public website with better information, guides, dashboard, status, information, etc. This is being built under the new [CODE-RADE](https://github.com/AAROC/CODE-RADE) repo, in the gh-pages branch. Definitely still work in progress, but we can work on this. The current pages at [Applications]({{site_url}}/applications)and [CVMFS]({{ site_url }}/cvmfs) will stay, and will be useful to end-users but [CODE-RADE]({{site_url}}/CODE-RADE) will contain the documentation, links to publications etc. + +## Project issues and planning + +The scripts which build and check the applications are kept each in a separate repository - this means there are several repositories and if builds fail, issues need to be opened, tracked and eventually fixed. Since these issues are tied to a repo, it's easy to track which commit fixed them, but since there are many repos, it's hard to keep track of the overall status of the CODE-RADE project. We need a way to collect issues and present them in a holistic way in order to track the overall progress of the project. + +There are also cross-cutting issues which may arise, which are only fixable by working on the Jenkins server, or some other central node of the platform. + +In order to keep track of the issues, we can used things like [ontrack](http://nemerosa.github.io/ontrack/) or [Waffle.io](http://waffle.io). I particularly like Waffle. + +## (Scholarly) Publishing the project + +The time has come to work on scholarly output of the project - we need to submit articles to journals and conferences to get the narrative in the public domain, in a peer-reviewed way. We also need to think about keeping the slide decks and articles in a findable place. + +### Conferences + +We have a couple of upcoming opportunities to do this : + + 1. OSSCOM in Amman, organised by ASREN - 10-13/09/2015 + 1. [pyConZA](https://za.pycon.org/) in Johannesburg, with a Software Carpentry Bootcamp - 2-4/10/2015 + 1. [The e-Research Africa conference](http://www.eresearch.ac.za) in Cape Town - 9-13/11/2015 + 1. The Ubuntunet Connect Conference in Maputo - 17-20/11/2015 + 1. The CHPC Conference in Pretoria 30/11/2015-04/12/2015 + + We probably can't make OSSCOM, but we should submit presentations to E-Research Africa and the CHPC conference. @smasoka should be presenting at CHPC, whilst both I and @smasoka will present at e-Research Africa. I will present at Ubuntunet. + + +### Where to put our contributions + +We should submit works to preprint servers which issue persistent identifiers and create a table on the project website with these links (could also be an iframe from Zenodo e.g.). We could also think about having an Africa-Grid Open Access Document and Data repository as part of DIRISA. This needs the Ansible playbook for Invenio to be finished. See [this topic on the forum](http://discourse.sci-gaia.eu/t/pre-beta-version-of-the-open-access-repository) + +## This week's topics + +### Update to end-user modulefiles + +Modulefiles will be used to allow users submitting jobs or running applications locally on their laptops to easily set up shell environments. Modules should be configured according to the *site* in question - by *site*, we mean a particular configuration or state, *e.g.* + + * a generic laptop with no cluster, with a Debian OS (generic, gcc4) + * a generic CEntOS site with standard middleware (gcc4-torque-openmpi) + * a CEntOS site optimised for high performance (gcc5-slurm-openmpi) + +These modules differ from those which we create during integration and then use to build applications against each other - they need to take the absolute minimum of parameters and need to be automatically set up by the end user. No variables to set, no special commands etc. A user or a script should simply be able to do something like + + + #!/bin/bash + source grid.sh # this is somewhere predefined on the site + module add # the tag that most represents your site - now you can add applications + module add # now you can run app on site with all the various configs + + + +We might want to keep the modules in a repo, so that we can track issues with them - or the module could be added to the app repo by jenkins itself after jobs complete. + +### Volunteer sites + +We need some volunteer sites to actually mount the repos so that we can send jobs down there. :beers: to the first site who signs up. We have a handy Ansible playbook to help out. + +### Jenkins development and future + +Just two points : + + 1. We've committed the Jenkins config to the repo on github, so it should be reproducible + 1. We are running out of space at UFS, so we need to start thinking about a beefier infrastructure. + + +# Next meeting + +The next meeting will be + + :calendar: 31/08/2015 on mconf. diff --git a/_posts/2015-09-01-Create-Publish.md b/_posts/2015-09-01-Create-Publish.md new file mode 100644 index 0000000..fdc9f21 --- /dev/null +++ b/_posts/2015-09-01-Create-Publish.md @@ -0,0 +1,83 @@ +--- +layout: post +title: 'Creation vs Publication' +description: 'Horses for courses in the Open' +headline: 'How to get things done that stay done' +category: blog +tags: [blog, Open Access, Github, collaboration, Persistent Identifiers, pubishing, creative] +image: + feature: r7Z09Ht.gif + attribution: Courtesy of [The Pattern Library](http://thepatternlibrary.com/#alchemy) +comments: true +mathjax: false +discourse: false +--- + +# Simple questions + +The best questions are simple: + +> When should we use github and when should we use oar? +> -- Bjorn Pehrson. + +This is always a matter of style, and what suits the team you're working in, but here's how I feel comfortable: + +# Different tools for different phases. + +Github and OAR (whether the invenio-based OAR, or any other Open-AIRE compliant OAR) are two different things used for different stages in the scholarly communication lifecyle. + + 1. Github is used for _collaborating_ and _creating_ + 1. OARs are used for _publishing_ and _curating_. + +## The creative phase. + +I put everything I work on in Github, because I know that it will be : + + 1. Change controlled - I can push updates to the repository and keep a log of my work + 1. Testable - at ever commit I can trigger a set of tests if need be + 1. Collaborative - others can fork my repository, send me pull requests and contribute to it easily; github keeps track of the contributors. + 1. Safe - I'm never going to lose work if it's pushed to Github. I can replicate it to as many remotes as I like. + +Now, this is during the _creative_ process, when there are changes under way and things are being built and tested. This goes for code as well as websites or even articles to journals. when it comes to _publish_, the work is in a stable and publishable state - a kind of _version_ if you like. Now, Github and other similar services allow you to publish versions of you work, but how to you create something that will be citable with a persistent URI ? This is where OARs come in. + +## The productive phase + +When I am ready to say "ok, this product is final" - ie issue a permanent version, I usually assign a specific persistent identifier with a specific release. [Zenodo](http://zenodo.org) - which is based on [Invenio](http://invenio-software.org), which in turn Sci-GaIA's [OAR](https://oar.sci-gaia.eu) is based on) ) does this very nicely by connecting via API to Github, requesting the list of releases of a repository and issueing a [DOI](http://www.doi.org/) from [DataCite](https://www.datacite.org/) for a new release. + +This is one aspect of the persistence of a product - the other is the persistence of the creators of that product. While there is no unique way to do this, [ORCID](http://orcid.org/) is probably the most widely used and reliable. + +## Reproducibility, Citability, Discovery. + +This may sound like a lot of work, but actually there are many advantages to simply putting things on the web somewhere : + + 1. By putting _products_ (code, articles, etc) into an OAR and issuing them persistent, unique identifiers, you can build a library of what you have published. + 1. By _linking_ them to the code and other tools which created them using Github, you can make these products _reproducible_, which is one of the main issues the project is trying to address. + 1. By complying with the OAI standards, your work will be included in the data and article citation indices and therefore will be more discoverable to other researchers. + +# Dealing with Data + +Finally, one place where Github "breaks down" is when it comes to dealing with large files, _i.e._ data. Git's change tracking algorithm sees every change to a binary file no matter how small as a 100% re-write and since it keeps the entire history of the file, this results in a very fast exploding repository. It's far better put data and large digital artefacts in a digital repository, which may or may not have change control in it... here, the important thing is the _semantics_ of **how** that artefact was created. If the data is linked semantically - via it's metadata - both to the creator and the creation process, then it is reproducible and citable. + +-------- + + +

Sci-GaIA is working on an integrated Open Science platform which delivers these services to research communities.

+ +------ + +# Comment, discuss, extend + +If you'd like to give some feedback or extend the discussion, please head over to the original [topic](http://discourse.sci-gaia.eu/t/publishing-vs-creating-in-the-open/) on the discussion forum. + +
+ + diff --git a/_posts/2015-09-14-CODE-RADE-burn-down.md b/_posts/2015-09-14-CODE-RADE-burn-down.md new file mode 100644 index 0000000..864d8bb --- /dev/null +++ b/_posts/2015-09-14-CODE-RADE-burn-down.md @@ -0,0 +1,167 @@ +--- +layout: post +title: 'CODE-RADE build burn down 36' +description: 'Summary of the build burn down of the CODE-RADE project, week 36' +headline: "CODE-RADE: burn baby burn" +category: blog +tags: [blog, CODE-RADE, sitrep] +image: + feature: burn.jpg + attribution: +comments: false +mathjax: false +discourse: true +--- + +# Burn down + +> TL;DR: The CODE-RADE platform is now mostly configured, and minor problems overcome. Continuous integration is being tested with weekly burn downs, to see whether the full chain is working. **Spoiler alert: it's not**. Also, you can help ! + +Here's the thing : + +---- + +
+ +
BAD THINGS HAPPEN !
+
+ +---- + + +Stuff breaks. The whole point of this project is to develop a system which will _reliably, reproducibly, rapidly_ rebuild the repository of applications used at various sites. We therefore conduct these burn downs to see if this is actually the case (spoiler: it's not yet), and highlight the issues which remain in the ashes. + +The CODE-RADE platform is how we think we can reliably deliver applications to both sites and individual users and _do it right_. Right means : + + * **Continuous** - New requests are automatically integrated using standard build and integration procedures. Most tasks are automated and little intervention is needed from site administrators. + * **User-driven** - Want an app that's not in our repository ? Just send us a pull request. + * **Site-Independent** - We build the apps for execution + * **Reproducible** - When we integrate something, we want it to _stay_ integrated. The last budgie standing after the nuclear holocaust should be able to rebuild _everything_ just by gently nudging their cute little beak against the still-radioactive screen showing the CI build server web interface. + + +# Integration flow + +
+ +
An example of Continuous Integration workflow, by the ThoughtWorks GO CI product team.
+
+ +Integration is not a linear path. Of course, it can't be _cyclical_, but to satisfy various end-user and site configuration desires, there has to be a level of paralellism involved. We do this with the Jenkins [MatrixJob Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Project+Plugin). This allows us to define _axes_ for our job configurations, for example the target operating system or application version number. + +There are also various _phases_ to the integration flow, from initial request to final delivered product. It would be really nice to have a visual representation of the state of your application - to be able to answer, _e.g._ the question : + +> "Where is my application in the delivery chain ?" + + Another issue which we'd like to address how to raise, escalate and resolve issues that may arise during the integration workflow. Now, we've taken the route that each application which we want built and integrated should have its own repository - we've now got around 30 repos in [South Africa Digital Science](https://github.com/SouthAfricaDigitalScience). How do we keep track of what state the various applications are, cross-reference them with their build results and understand where the bottlenecks are ? + +----- + + +It just so turns out that this problem is not a new one, basically, we need a "scrum" or "kanban" board[^ScrumBoard]. +To this end, we've created a [board](https://waffle.io/AAROC/CODE-RADE) to contain all of the tickets opened in the various repos against the specific applications. The single board allows us to place to see the overall status of the CODE-RADE project. Unfortunately, ticket dependencies are managed "by hand" - there's no way (yet) to specify which cards are blocked by which other ones, but we can take care of that just by manually ordering the cards on the board. Anyone who owns the repos (ie, in the right team of the owner organisations on Github) can interact with the board. Updating tickets information just involves a few clicks, and shifting issues along the pipeline is a drag-and-drop procedure. + + +
+ +
Full overview of the build flow, from a multi-repo waffle board.
+
+ + + +## Dependency Graph + +One of the greatest (and thus hardest) things about CODE-RADE is the expression of dependencies between applications. Most open source software is not a monolithic structure, but rather delicate - some might say graceful - assembly of various independent components. These components may be in turn variously configured to produce different functional states, each of which can be considered nodes in a DAG[^DAG]. In fact, one of the main corrolaries of CODE-RADE, if we do things right, is to express a more-or-less fully-populated graph of the dependencies of _all_ applications used in scientific research[^notpossible] (or at least the most popular ones). + +
+ +
The compiler build chain dependency graph as of writing - yes, it needs work. The full dependency graph is too large to show on one page. See http://dx.doi.org/10.5281/zenodo.30977
+
+ +This is for what we're calling ***"Foundation Release 1"*** - _IE_, "*stuff you can use to build other stuff*". + +# Build Failure Analysis + +We're using the [Jenknis Build Failure Analysis plugin](https://wiki.jenkins-ci.org/display/JENKINS/Build+Failure+Analyzer) to identify various build failures. This is a fantastic plugin which scans the build logs and tries to figure out (via regexp) what went wrong. The build failure analysis helps us to estimate how much time fixing a build failure would take and spotting error patterns that are affecting more than one job. + +Of course, failure types have to be spotted and identified by actual humans - so, if you've got some time on your hands and feel like reading build logs, why not help us isolate these common errors and implement fixes ? + +# Bottlenecks + +So, with the dependency graph expressing the route from one component to the next, and the waffle board detailing where the actual issues are, we can plan work to address this and ensure that the pipeline burns right down. Here's a summary of the current state of affairs: + + * Total jobs in Foundation Release: 20 + * Failing jobs: 5 + +So, we're roughly 75 % of the way there (at least, using one definitely inappropriate metric ![^BetterMetric]). + +## Disk space - workaround + +One problem was the issue of disk space. The jobs were being built entirely on the slaves - which meant that the build artifacts including the intermediate ones were all kept on thes fairly small machines (~ 100 GB). The CI server however has a nice big (~1TB) disk which we are now exporting portions of over NFS to the build slaves. Thus, the jobs are all reading from and writing to a single disk. + +While this solves the size available problem, it does bring up some severe performance issues, especially in the case of wide matrix jobs such as `gcc`, which has 6 concurrent builds for the different axes. This can probably be alleviated by ensuring that the matrix builds are sequential instead of parallel as they are at the moment. + +## Numpy errors + +The [NumPy](http://www.numpy.org/) build scripts in their own [repo ](https://github.com/SouthAfricaDigitalScience/numpy-deploy) - currently, we're getting the following error when building NumPy + +{% highlight python %} + 'import site' failed; use -v for traceback + Traceback (most recent call last): + File "setup.py", line 16, in + from __future__ import division, print_function + ImportError: No module named __future__ + Build step 'Execute shell' marked build as failure +{% endhighlight %} + +We have no idea what this means, so if you're a python speaker, please take a look at the `build.sh` script and maybe send us a PR that fixes it. + +## OpenMPI + +OpenMPI is failing only on the SL6 slaves. From the looks of things, the builds are passing, but functional tests are not. These are giving modulefile errors such as + +{% highlight bash %} ++ ./check-build.sh +About to make the modules +./check-build.sh: line 3: cd: /var/lib/jenkins/workspace/OpenMPI/ARCH/x86_64/GCC_VERSION/5.2.0/OS/sl6/SITE/generic/VERSION/1.8.1/openmpi-1.8.1: No such file or directory +{% endhighlight %} + +and further down the `check-build.sh` script : + +{% highlight bash %} +ModuleCmd_Load.c(208):ERROR:105: Unable to locate a modulefile for openmpi/1.8.1-gcc-5.2.0 +which: no mpirun in (/usr/local/bin:/bin:/usr/bin) +Build step Conditional step (single) marked build as failure +{% endhighlight %} + +The NumPy build failures are inhibiting the rest of the python chain including SciPy and others. + +# SitRep and TODO + +So... this weekend's burn down went ok, but not awesomely. We need to focus on testing the compilers out of the build environment now. (this would be the validation channel in the waffle board) and call in some help on the NumPy and SciPy issues. Also, some time needs to be spent on actually populating the board with the tickets for checking the application states... + +----- + +The next community call is Wednesday 16/09 at midday. Be there or be[^square] :squirrel: + +----- + +In the meantime : + +
+ +# References and Footnotes + +[^square]: That's a squirrel, in case you're wondering. Emoji haven't caught up to 1950's slang yet. We live in hope. +[^ScrumBoard]: Also known as a KANBAN board. See [Altassian's description](https://confluence.atlassian.com/display/AGILE/Scrum+Board) +[^DAG]: DAG : [Directed Acyclic Graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph). +[^notpossible]: Ok,. this is clearly not possible even in principle, since there are new applications, version and configurations born every day - but hey, at least we're reaching high :smile: +[^BetterMetric]: Waffle allows you to assign "sizes" to your cards, which are basically estimates of how much effort is required to move them... I guess it's similar to "mass" in that sense. So, if you take a look at the board, it'll show you where the actual centre of mass of the project is. Which is :cool: diff --git a/_posts/2015-10-05-CODE-RADE-commentary.md b/_posts/2015-10-05-CODE-RADE-commentary.md new file mode 100644 index 0000000..409f8ce --- /dev/null +++ b/_posts/2015-10-05-CODE-RADE-commentary.md @@ -0,0 +1,29 @@ +--- +layout: post +title: 'CODE-RADE commentary' +description: 'Some critical feedback from the community on CODE-RADE' +headline: "What do you think?" +category: blog +tags: [blog, CODE-RADE, sitrep] +image: + feature: SplitShire-068.jpg + attribution: "Image courtesy of SplitShire http://www.splitshire.com/light-umbrella/" +comments: false +mathjax: false +discourse: true +--- + +No project can live without the oxygen of and fire of debate. The time has come to put CODE-RADE out there in the wild, and see how it stands up to the real world. The philosophy, technique and end product need to pass the most crucial and critical of all tests : usability. We asked a few people to contribute their ideas and criticisms, which we publish here (edited only for quality and grammar). + +This week's comment is from [Dane Kennedy](http://github.com/kennedydane), a research scientist at the [CHPC](http://www.chpc.ac.za) - South Africa's largest research computing centre and one of the target sites for the project. We asked the questions _in italics_ and let him go wild with his responses. If you have further commentary, please [follow the discussion](http://discourse.sci-gaia.eu/t/code-rade-commentary/1799) + +----- + + +> First let me start by saying that I'm very new to the setup and I've not read all the links and documentation that has been thrown at me. So -- my comments and observations may well be uninformed. + + 1. ***What do you like about the project ?*** - Well I quite like the idea of having an automated system for application compilation and installation. I like that there are enthusiastic scientists involved who want to make things work better. + 1. ***You expressed some doubts about the usability of the system in a place like CHPC - could you expand ?*** - Well, my doubts were actually more general -- one of scalability. I am worried that the current system (as I understand it) revolves around supplying different versions of applications for different versions operating systems and potentially different versions of hardware. So I am worried that as the package list grows, this will become unmanageable. My other issue is that I am concerned about the CVMFS -- it seems like a relatively specialised read-only remote filesystem that does various magical things like caching and Idon'tknowwhat. I worry about things that could potentially require one to be connected to the internet. So somewhere like the CHPC is connected all the time, of course (well hopefully!), but I'm considering other scenarios like Mike the Biologist who is away at a conference and no longer has internet access. Now that he can't mount CVMFS -- does his software stop working on his laptop? I'm guessing that's where the caching come in... But it still leaves me feeling somewhat uncomfortable (I must read more about this). + 1. ***Any criticism of the workflow ?*** At the time when I first got introduced to this there seemed to be some kind of NFS problem, which meant that build times were very slow. As someone who is absolutely rubbish at multi-tasking or task-switching, the longer I have to sit and wait between builds is probably going to result in me losing interest and working on something else where I can have more flow. This can obviously be overcome and the number of build nodes can be increased presumably. + 1. ***Where do you see this project going ? how could it benefit users - and what needs to change for that to happen?*** I'm not sure. I am concerned that there's an element of re-inventing the wheel here. It feels like package management is an old idea, and what this is aiming to do is provide users with the option of selecting particular versions of their tool of choice. This too is not a new problem -- I have had a lot of success using (ana)conda -- and I think it might be worthwhile investigating that as an option. It also looks at setting up users environments, making sure versions are correct and that dependencies are met (and if they're not -- it will install them). Most people are familiar with it as a python package manager, but it's not python-specific -- in fact one can now get ahold of R stuff there. So, I'm actually going to put a little more effort into investigating (ana)conda package management as it seems as if it might be a little more flexible in terms of providing a solution to a wide variety of end-users. + 1. ***How would you see users interacting , via bot, with this ?*** I haven't thought about bots interacting with this much. diff --git a/_posts/2015-10-21-BetterDelivery.md b/_posts/2015-10-21-BetterDelivery.md new file mode 100644 index 0000000..135ce01 --- /dev/null +++ b/_posts/2015-10-21-BetterDelivery.md @@ -0,0 +1,99 @@ +--- +layout: post +title: 'A better testing and delivery strategy' +description: 'The time has come to put on our Big Boy CI boots' +headline: 'The time has come to put on our Big Boy CI boots' +category: blog +tags: [blog, CODE-RADE, sitrep] +image: + feature: tumblr_mw87ofGfHW1sfie3io1_1280.jpg + attribution: "Image courtesy of New Old Stock - http://nos.twnsnd.co/image/69699793933" +comments: false +mathjax: false +discourse: true +--- + +TL;DR - We've been doing things wrong all this time. Time to do them right. + +------- + +# Getting serious about workflow + +When we set out on this project all that time ago[^Depressing], the workflow was simple - write the scripts necessary to build any application, and create a module file for it, then install everything in a single repository and ship it with [CVMFS](http://cernvm.cern.ch/portal/filesystem). The change control would be done by [Github](https://github.com/), builds would be done by [Jenkins](http://www.jenkins-ci.org). We want these apps to _just run_ on grid, standalone HPC and cloud sites, which would be running one of a limited set of targets. The theory went that we'd build for these targets[^targets] and then shove them into CVMFS along with their module files. + +# Things go wrong + +As we started tinkering with the system and seeing where it could go, certain implementation decisions were lost to time. We originally discussed using a kind of [Domain-Specific-Language](https://en.wikipedia.org/wiki/Domain-specific_language) - very similar to what we subsequently discovered is done by [EasyBuild](https://hpcugent.github.io/easybuild/) with their [EasyConfig](https://github.com/hpcugent/easybuild-easyconfigs). Alas, we're not as awesome as we could be given infinite resources, so we went with the general rule of separating out specific stages of the build into simple scripts, that Jenkins would execute sequentially. + +This is very far from being a "standard", nobody in their right mind would call it an "API", but we wanted to provide the means for new contributors to collaborate easily, and a common workflow like this was needed. However, the first thing we did after making this discussion was ... break it. + +
+ +
Is this why we can't have nice things?
+
+ +The simple workflow : + + 1. Build the application (using `build.sh`) + 1. Test the application (using `check-build.sh`) + 1. Install the application in the right place in the repository + 1. Write the application modulefile and put that in the repository + 1. Initiate a transaction and publish a new version of the repository + +went out of the window, because clumsy things were done in our initial enthusiasm of getting things going. +This meant that we have populated a nice big CMVFS repository (well, two actually) with broken apps. +The libraries and applications are all properly built, but module files were only written for the build and test environment, but not for the repository environment in which they would actually be used out there in the real world. + +We're at the point now, where we need to focus more on quality and trustworthiness, which means *usability*. This post describes a few tweaks we're making to `CODE-RADE` in order to make the the upcoming release usable. + + +# We can actually have nice things. + +First of all, we need to keep the jobs tidy and consistent. +*"Tidy"* means separating out tasks into individual scripts, and not dumping various stages of integration into the same script. +*"Consistent"* means checking that all of the jobs are doing something similar and weeding out differences between their implementations as far as possible. + +## Cleaner build scripts, cleaner integration statuses + +Currently there in general two build scripts. +These are executed by Jenkins at each "build stage". +The theory is that if something fails to build, it should not be installed, no modulefile should be created and it should not make it to the repo. Duh. +Jenkins does this by having separate build stages, and subsequent stages are triggered by the status of the preceding ones. +In this way you have a kind of "Build Flow". Not the *actual* [Build Flow](https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin) that Jenkins already has with it's own DSL but nonetheless a logical, serial workflow. +We currently have the compilation phase in a single script (`build.sh`), but the following steps are all bundled into one - `check-build.sh`. +So, the first thing we have to do is increase the number of build steps and increase the number of scripts, so that we can have finer-grained control over what stage application integration is in. +Also, certain stages in the build flow should trigger other events outside of the application build flow - for example, if a job compiles and is tested properly, it should be installed in the build environment, with appropriate module file (`ci//` - with application root at `/apprepo`). +It should then _also_ be installed in the deploy environment with corresponding modulefile (`deploy//` with application root at `/cvmfs`). +At this point, the transaction can be triggered - at least on `devrepo` and we'd have a _proper_ continuous integration. + +All we need to do this is to change the prefix of the `make install` bit. + +## Better separation of staging and integration + +The integration area `/apprepo` is used by the jobs to find and compile against their dependencies, however, on the build slaves we don't have a staging area for creating the artifacts that have to get shipped to the CVMFS repository[^Fanie]. One thing we could do is start building tarball *"artifacts"* and keep them with the job number associated to the file in some way[^filename]. This would allow us to keep a clean CVMFS repository, with direct links between the applications in it and the build number that created them. + +There is a tradeoff to be made here, though - + + * It is very efficient to `rsync` individual files between the build slaves and the CVMFS repository, since only the differences will be shipped. If tarballs were to be shipped, we would probably lose this efficiency. + * CVMFS uses AUFS, and calculates differences in files in order to generate the new filesystem. These differences may be lost otherwise. + +So, perhaps the right thing to do is to do `rsync` for `devrepo` and `tarball` for `apprepo`. + +# We're late already ! + +These have been some thoughts on improving the usability and scalability of project CODE-RADE. It will take a while to implment, and in the meantime, we need to publish the first release - Foundation Release 1. +This was scheduled for **3 weeks ago** :scream: so it's time to get *something* out there. There are currently [9 open issues](https://github.com/AAROC/CODE-RADE/milestones/Infrastructure%20foundation%20release%201) for this release and most of them are related to modulefiles. We can fix this, so let's do it. + +Peace out. + +------ + +# Footnotes and References + +[^Depressing]: It's a bit depressing to think that it started 2 years ago and only now we're getting to something that might be called ready for public consumption. +[^targets]: The targets were a combination of operating system, site architecture and a tag on the kind of site - `optimised`, `generic`, `gpgpu`, _etc_. +[^Fanie]: This *was* done once upon a time early on, but was discontinued for other reasons. +[^jobnumber]: diff --git a/_posts/2015-10-23-CODE-RADE-Downtime.md b/_posts/2015-10-23-CODE-RADE-Downtime.md new file mode 100644 index 0000000..04fb5e4 --- /dev/null +++ b/_posts/2015-10-23-CODE-RADE-Downtime.md @@ -0,0 +1,235 @@ +--- +layout: post +title: 'CODE-RADE Downtime' +description: 'The road to downtime is paved with good intentions' +headline: 'We done goofed.' +category: blog +tags: [blog, CODE-RADE, sitrep, downtime, goof, doh] +image: + feature: 'he__s_dead_jim_by_pepper_fox.jpg' + attribution: "Image courtesy of Deviant Art http://orig00.deviantart.net/0872/f/2009/167/7/e/he__s_dead_jim_by_pepper_fox.jpg" +comments: false +mathjax: false +discourse: true +--- + +# We killed Jenkins + +We didn't mean to. Actually, we were just about to publish [Foundation Release 1](). The plan was to make the release, upgrade Jenkins and move on... _in that order_. Of course, thinking that everything would be fine if we just upgraded Jenkins and _then_ published the release, we went ahead and upgraded to [1.625](http://updates.jenkins-ci.org/1.625/latest/jenkins.war) and then ... bad things happened. + +
+ +
Let's just say things went pear-shaped
+
+ +# What went wrong + +So, actually the service _is_ up and running, but several - almost all - of our jobs were removed from the Jenkins configuration :scream:. This is pretty horrific, we'd spent months adding these jobs and painstakingly ensuring that their dependencies were correctly encoded... However, checking the config directory, we noticed that all of the job configs[^Configs] were still there. They just weren't being accepted by Jenkins. + +---- + +So, what went wrong ? + +---- + + +The first log entry we encountered was : + + + WARNING: Failed to scout com.tikal.jenkins.plugins.multijob.MultiJobBuildSelector java.lang.InstantiationException: java.lang.NoClassDefFoundError: hudson/plugins/copyartifact/BuildSelector + + +Now, most of our jobs are [matrix jobs](https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Project+Plugin) which allow us to test the various configurations of operating system, version number, compiler configuration, _etc_. The above error was the first hint that this was a _plugin_ issue and not an actual Jenkins issue. + +Then, we started getting these : + + SEVERE: Could not load actions from hudson.plugins.jswidgets.JsProjectActionFactory@6ca0e1b6 for hudson.matrix.MatrixProject@73ac157[hdf5-deploy] + + +followed by + + Oct 23, 2015 2:41:58 PM jenkins.InitReactorRunner$1 onTaskFailed + SEVERE: Failed Loading job hdf5-deploy + java.lang.NullPointerException + + +As you can see that is for a specific job `hd5-deploy`, which was using the MatrixProject configuration. It's also using a bunch of Jenkins plugins which are how we configure these jobs to do the things we want them to do. + +## Job triggers ? + +In particular, the job build triggers are using the [Github](https://wiki.jenkins-ci.org/display/JENKINS/GITHUB+plugin) and [Github Pull Request](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin) plugins. + +The lowest-lying job in the dependency graph, [`gmp-deploy`](https://github.com/SouthAfricaDigitalScience/gmp-deploy) was also not loaded. This is _only_ triggered by Github events, and not other jobs[^HumanIntervention] and was throwing errors like this : + + + + Oct 23, 2015 2:42:13 PM jenkins.InitReactorRunner$1 onTaskFailed + SEVERE: Failed Loading job gmp-deploy + java.lang.NullPointerException + at hudson.matrix.MatrixProject.createTransientActions(MatrixProject.java:442) + at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:748) + at hudson.matrix.MatrixProject.updateTransientActions(MatrixProject.java:456) + at hudson.model.AbstractProject.save(AbstractProject.java:304) + at org.jenkinsci.plugins.ghprb.GhprbTrigger.save(GhprbTrigger.java:171) + at org.jenkinsci.plugins.ghprb.GhprbTrigger.start(GhprbTrigger.java:186) + at org.jenkinsci.plugins.ghprb.GhprbTrigger.start(GhprbTrigger.java:52) + at hudson.model.AbstractProject.onLoad(AbstractProject.java:326) + at hudson.matrix.MatrixProject.onLoad(MatrixProject.java:497) + at hudson.model.Items.load(Items.java:322) + at jenkins.model.Jenkins$17.run(Jenkins.java:2655) + at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169) + + +So, this points in the direction of the "GhprbTrigger" the trigger that says "build this job when a pull request is sent to the Github repo". There are some suggestions that these are known bugs, from the [Jenkins JIRA](https://issues.jenkins-ci.org/browse/JENKINS-28417), but the solution that was suggested did not fix anything. + +## Hints from the job configurations + +The `gmp-deploy` job configuration looks like this : + + + + + + + + 30 + 100 + 60 + 30 + + false + + + false + + + https://github.com/SouthAfricaDigitalScience/gmp-deploy.git/ + + + false + + + + human approved + build passes on sl6 + build passes on u1404 + push artifacts + + + + + 2 + + + https://github.com/SouthAfricaDigitalScience/gmp-deploy + you wish + + + + + */master + + + false + + + + + + + + + + + ... stuff ... + + gmp-deploy + <__project class="matrix-project" reference="../../.."/> + you wish + + + + + + + + + + + false + + + VERSION + + 5.1.3 + + + + SITE + + generic + + + + OS + + sl6 + u1404 + + + + ARCH + + x86_64 + + + + + false + + + + +

If anyone is out there reading this and can spot the error, please help us out !

+ +# We goofed - might as well publish a relase... + +So - we goofed ! CODE-RADE won't be building anything for a few days, while we get this sorted out. The important thing is to learn some lessons : + + 1. First publish a release, then upgrade your build server + 1. Upgrade jenkins and the plugins separately + 1. Upgrade plugins one by one + 1. Maintain a roll-back strategy in case of Bad Things like this. + +
+ +
Oh well. It's still Friday though...
+
+ +So, we'll be publishing [Foundation Release 1](https://github.com/AAROC/CODE-RADE/milestones/Infrastructure%20foundation%20release%201) _as is_. Warts and all. What's in there will be in there, what's missing will come in [Foundation Release 2](https://github.com/AAROC/CODE-RADE/milestones/Infrastructure%20foundation%20release%202), scheduled for ***November 13 2015***. There should also be a first [Public Release](https://github.com/AAROC/CODE-RADE/milestones/CODE-RADE%20Public%20Release%201) on ***October 31 2015***. + + +# Then, Github died + +Ok, so builds weren't triggered... we needed to fix this and fast ! But this morning, we got another surprise : + +
+ +
The well-known step function. Decidedly sub-optimal.
+
+ + + + + + +Sigh. Your pain is our pain @github + + + + + +# Footnotes and References + +[^Configs]: The job configurations are kept in xml format in `$JENKINSHOME/jobs`. These are kept in source control (actually a private Github Repository) - so it could not really have been such a huge disaster. +[^HumanIntervention]: Ok, sometimes we humans intervene and trigger jobs, but ***only if they've been very naughty !*** diff --git a/_posts/2015-11-01-AnsibleBootCamp.md b/_posts/2015-11-01-AnsibleBootCamp.md new file mode 100644 index 0000000..b61ea14 --- /dev/null +++ b/_posts/2015-11-01-AnsibleBootCamp.md @@ -0,0 +1,90 @@ +--- +layout: post +title: 'An Ansible Boot camp' +description: 'Time to get your training on' +headline: 'Time to get your training on' +category: blog +tags: [blog, training, sci-gaia, ansible] +image: + feature: '220110409213151001_4957481_ver1.0_640_480.JPG' + attribution: "" +comments: false +mathjax: false +discourse: true +--- + +# TL;DR + +We teamed up with GARR to develop an intensive 5-day course for infrastructure operators, focussing on service federation and the DevOps movement. Using [Ansible](http://www.ansible.com), we went over the theory and practice of "Infrastructure as Code" with practical examples and lots of hands-on. This is still a work in progress, but will soon be published to [the Sci-GaIA e-Learning platform](http://courses.sci-gaia.eu). Watch [the repo](http://github.com/AAROC/AnsibleBootCamp) for more. + +# Ansible Boot camp + + +Last week, we ran the first [Sci-GaIA](http://www.sci-gaia.eu) training course. The course was titled "[DevOps for Federation](http://agenda.ct.infn.it/event/1180/)" and was conducted at the INFN (Catania), by the Meraka Institute's [Bruce Becker](http://brucellino.github.io) and [Andrea Biancini](http://www.unimib.it/go/9216095476319321399/Home/Italiano/Elenco-Docenti/BIANCINI-ANDREA-dipartimento-di-fisica-giuseppe-occhialini) from [GARR](http://www.garr.it) (the Italian NREN) and the Bicocca University in Milan. The core technologies taught in this course were Ansible and Shibboleth + +
+ + +
This course is affiliated neither with the Shibboleth project nor Ansible. We just like their stuff...
+
+ +## Off to a coding start + +As its name suggests, the course is intendend for those with almost zero prior knowledge. There are indeed certain prerequisites which are not covered in the course, such as knowledge of Linux shells. An understanding of `git`, `python` and `YAML` for the first part, as well as a basic understanding of the Apache web server configuration for the second part are suggested - and these can be accomplished by well-known online code schools +The course is designed to be run stand-alone, with students taking it self-paced online. However, the material is modular and Open-Source, so it can be re-worked into university coursework or other technical training of a more formal nature. Much inspiration for the methodology was taken from the [Software Carpentry](https://software-carpentry.org/). + +## Two timely topics + + +The course was separated into two sections - + + 1. Theory and practice of DevOps with Ansible + 1. Turn your web service into a federated web service + +These addresses two of the aims of the Sci-GaIA project : ***development of African Identity Federations, and the support of e-Infrastructures in the region***. + +Taking identity federations as an example, as these are developed, the need for both identity providers as well as new services are going to be needed in the region. Since many countries are starting from scratch in their development of these federations, the administrators of new services are both learning how to develop them *and* operating them at the same time. There is therefore a great need for collaboration, knowledge dissemination and sharing, all of which are aspects of the DevOps movement. The tools of the trade may change from time to time, but the need to share best practice widely in a federation is a fundamental one. + +An identity federation is only as useful as the services it offers to users, and often integrating existing services into a new federation takes very long and can be tricky. This course therefore also targets those administrators or service developers who indeed want to open up access to their web applications to a wider community without the overhead of user management. During the course, we discussed not only the technical aspects of how to do this, but also the human and policy aspects of developing services. + +# Open, Reproducible, Community + +There are several online learning materials (and of course, TFM[^TFM] !) which address these issues of technology - so why make yet another online course ? The issue comes down to the development of community. While online code schools target mostly individuals, we wanted to target *communities* - in particular the NREN and e-Infrastructures communities. Particular emphasis is placed on making code open, maintainable, in adopting testing and verification strategies, and other good open source development practice. If, as the saying goes, *"everything is code"*[^EverythingIsCode], we wanted that code to be written well. + +# Everything is code + +We wanted the course to be *executable* in a sense. The sessions were taped on video, and will be available via the [Sci-GaIA Open EdX instance](http://courses.sci-gaia.eu), but that only addresses the student learning aspect. We also wanted it to be possible to give the course independently at a different institute, by different instructors. To this end, we have started working on the actual *course playbooks*[^playbooks]. The goal is that everything goes into [the repo](https://github.com/AAROC/AnsibleBootCamp); when someone wants to offer the course, everything that they will need will be available in the repository, except of course the online learning material such as videos and quizzes. + +Included in the repository will be both instructor material, + + * **[Dockerfiles](https://docs.docker.com/reference/builder/)** necessary to build the training environment. Docker images will also be maintained on [Docker hub](http://hub.docker.com) for the instructor + * **Lesson guides** - text files describing what to cover, with notes on what to focus on and inputs to the lesson plan. + * **Evaluation playbooks** - playbooks which run against the student's work in order to check whether the lessons have been correctly done. + +as well as the student material: + + * **Getting started guides** - summaries of the slides and common commands + * **Tutorial playbooks** - initial playbooks which teach the students aspects of the DevOps approach and which demonstrate the functionality[^againstImages] + * **Exercises** - both manual and coding exercises are foreseen. Most of them will be evaluated by playbook, so that they can be checked automatically. + +By putting in extra effort initially, we hope to make the course independently *executable* - meaning that a student can in principle use everything in the repo to both create the course and take it. The hope is that both individuals as well as small, new groups could use this as a learning and teaching resources, using it and contributing back to the course as time goes by, thereby helping to build a stronger community of technical expertise in our region. + +# Powered by you + +NREN's, grid and cloud services and data infrastructures are all powered by people at the end of the day. The Sci-GaIA project, through its member institutes, wants to leave a lasting impact on these _people_. + +**It will be of no use to anyone to build a fine infrastructure if it's not built to last.** + +# Coming soon + +So, watch this space and hopefully we'll be able to announce the full course at the [UbuntuNet Connect Conference](http://www.ubuntunet.net/uc2015) in Maputo later this month. In the meantime, watch the [repo](https://github/AAROC/AnsibleBootCamp) - or if you're really keen fork the repo and send us a pull request ! You'll be helping to build a better infrastructure in Africa. + +----- + + +# Footnotes and References + +[^TFM]: The Fine Manual is always the best reference ! +[^EverythingIsCode]: "Everything is code" is an operations philosophy wherein configuration management, testing and continuous integration tools are heavily adopted in order to represent all services in an infrastructure in some form of programming language. This makes the wall between service developers and service operators far less opaque. +[^playbooks]: ["Playbooks"](http://docs.ansible.com/ansible/playbooks.html) a concept in Ansible whereby it performs service orchestration. The concept is widely adopted as a strategy or tactics description in various sporting codes. (haha, get it - codes.) +[^againstImages]: These are to be run against Docker images, or similarly prepared virtual machines, depending on the classroom environment, to demonstrate how the system works. diff --git a/_posts/2015-11-06-SVG-2015-CVE-2015-7835.md b/_posts/2015-11-06-SVG-2015-CVE-2015-7835.md new file mode 100644 index 0000000..8f6ae04 --- /dev/null +++ b/_posts/2015-11-06-SVG-2015-CVE-2015-7835.md @@ -0,0 +1,24 @@ +--- +layout: post +type: status +title: "A EGI SVG Advisory 'Critical' Risk 'Breakout' vulnerability for sites running Xen" +description: 'EGI SVG 2015-7835 - Breakout risk where users have root on Xen VMs' +headline: 'Tighten your Xen' +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2015-7835 ] +image: + feature: 'atari_breakout_free_play.jpg' + attribution: "Courtesy, The Register - http://www.theregister.co.uk/2015/11/04/mozilla_patches_up_firefox_flaws/" +comments: false +--- + +A critical vulnerability has been discovered in the [Xen hypervisor](http://xenbits.xen.org/xsa/advisory-148.html), allowing users **having root** access on the guest VM to "break out" of the context and attac the `dom0`. Xen is widely used in the [EGI FedCloud](https://www.egi.eu/infrastructure/cloud/), and is likely also used on various sites in the ROC. + + + +Recommendations +=============== + +All running resources deploying Xen MUST be either patched or have mitigation in place by **2015-11-10 T21:00+01:00.** + +Site administrators using Xen are requested to check the security advisory and take action if necessary, or risk suspension. diff --git a/_posts/2015-11-09-CVE-2015-7183.md b/_posts/2015-11-09-CVE-2015-7183.md new file mode 100644 index 0000000..270a3ec --- /dev/null +++ b/_posts/2015-11-09-CVE-2015-7183.md @@ -0,0 +1,23 @@ +--- +layout: post +type: status +title: 'A CRITICAL-severity Remote arbitrary code execution vulnerability has been announced.' +description: 'EGI SVG Advisory : Remote arbitrary code execution vulnerabilities in the core crypto library used by RedHat.' +headline: 'Time to update or disable libnss' +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2015-7183 ] +image: + feature: 'firefox.jpg' + attribution: "Courtesy, The Register - http://www.theregister.co.uk/2015/11/04/mozilla_patches_up_firefox_flaws/" +comments: false +--- + +CSIRT has announced a [new vulnerability](https://wiki.egi.eu/wiki/SVG:Advisory-SVG-2015-CVE-2015-7183) Mozilla's `libnss`. This has been characterised as a **CRITICAL-severity** vulnerability, since it allows arbitrary remote code execution. + +The fix is particularly easy. See the instructions on the [EGI SVG wiki](https://wiki.egi.eu/wiki/SVG:Advisory-SVG-2015-CVE-2015-718). + +------- + +For any support or questions, contact the [SANREN CSIRT](mailto:csirt@sanren.ac.za), or hook us up on Slack + +----- diff --git a/_posts/2015-11-19-UC2015.md b/_posts/2015-11-19-UC2015.md new file mode 100644 index 0000000..5735d60 --- /dev/null +++ b/_posts/2015-11-19-UC2015.md @@ -0,0 +1,133 @@ +--- +layout: post +title: 'Back home someplace new' +description: 'Thoughts and observations from UC2015' +headline: Ubuntunet Connect 2015 - 19-20 November 2015 +#modified: '2015-11-18' +category: blog +tags: [Ubuntunet Connect, conference, commentary, community] +image: + feature: CUSOq4xUwAAZCJn.jpg + attribution: 'Image courtesy of Katrin Stover - https://twitter.com/Cat_Stover/status/668408267098443777' +comments: false +discourse: true +--- + +# Back home + +Everybody has a place that they like to call home. It may be a place, or it may be a group of people - and coming back to an Ubuntunet Connect meeting felt a bit like this for me - coming home. It's a community meeting of people who are sincerely engaged with their constituents and are committed to making a difference to research communities in the long run. Most of us there know how little positive feedback there is in developing an NREN - when the bandwidth is slow and the services don't work, we hear complaints and murmurings of discontent, but when everything _works_, we hardly ever get a pat on the back for a job well done. When the network works, it disappears (as most well-functioning techonlogy). Yet, despite the often lacking feeling appreciation from user communities, the NREN community is really close and there's plenty of support from within. + +So, this was the first time in Mozambique for me, and the *n-th* time "back home" in Ubuntunet's annual meeting. The conference was held over 19 - 20 November in Maputo. + +# Looking back... + +This event was an especially important one for two reasons : for one thing, it's Ubuntunet's 10-year birthday :tada:. Now, you can write your own "where was I ..." anecdote in the comments; in my case, ten years ago, I was in the thick of my Ph.D. at the University of Cape Town, working on the [ALICE](http://alice-collaboration.web.cern.ch/) experiment at [CERN](http://cern.ch). Part of my job was developing software for the alignment of the Dimuon spectrometer of the ALICE experiment, but we were also tasked with building part of the [Worldwide LHC computing Grid](http://wlcg.web.cern.ch/). Turns out it's quite hard to do that without a network... + +Skip ahead 10 years and in South Africa we're running jobs like a boss at several sites in the WLCG, including ALICE jobs at the [Centre for High-Performance Computing](http://www.chpc.ac.za) + +
+
+ +
Jobs at the CHPC run by the ALICE collaboration from 2006 to December 2015. Credit: ALICE Collaboration
+
+
+ +It's obvious to see things taking off around 2012. The availability of adequate bandwidth to South Africa via undersea cables around this period played a huge part in this continued success[^NotSimple]. This is just one case where NRENs are directly enabling research which couldn't be done without them; Several more can be found at [http://www.casefornrens.org](www.casefornrens.org)[^cas4nren]. It's worthwhile to remember that in times of plenty (which we in South Africa are experiencing now) *as well as* in times of scarcity, which many of our colleagues in Africa are living through. It is as a community that we grow and mutually support each other, and it's important to remember that this is how we achieve the greatest goals: through collective action. + + +Seeing continued investment in the network is one of the most satisfying feelings we can have as infrastructure developers, and it was therefore with great excitement that we heard that the [AfricaConnect 2](http://www.africaconnect.eu/MediaCentre/Pages/AfricaConnect2.aspx) project agreement had been signed : + +---- + +> AfricaConnect2 sets out to extend the success story initiated by AfricaConnect and EUMEDCONNECT to the whole African continent, thus accelerating the development of the Information Society in Africa. Whilst the connectivity boost will improve the lives of millions of Africans through accelerated research and education, it will equally benefit collaborative scientific research the world over, in areas such as climate change, biodiversity, crop research, malaria and other infectious diseases. +> AfricaConnect2 is expected to commence in July 2015 and will have a duration of 3.5 years. +> -- [AfricaConnect Project closing statement](http://www.africaconnect.eu/MediaCentre/Pages/AfricaConnect2.aspx) + +---- + +# Comments from the speakers + +There were several speakers of note at the first day of the meeting, who commented on these milestones. We had representatives of the African Association of Universities, the African Academy of Sciences, GEANT, the regional NRENs of course (Ubuntunet, WACREN and ASREN), as well as the Network Startup Resources Centre, who has been there for the African RENs amongst others for ... well, since the beginning ! A few things stood out as they gave their speeches. + +First of all, the realisation that Africa is a first-class citizen of the research world. Perhaps one with a tiny voice, but still a full citizen, participating and contributing to efforts at every scale and in every area. Research networking is needed more than ever now and this was noted by the AAU as well as the AAS. This may sound obvious to the casual observer, but for those of us who have been around 10 years or longer, we can appreciate how much of a change this is. Research networking and advanced services were scoffed at not so long ago as a luxury that could not be afforded (in the best cases), or as an outside influence (possibly even a corrupting one at that) of dubious value. + +Words of encouragement came from the regional NRENS in the North of Europe (Nordunet), Latin America (Clara) and the Caribbean (CKLN). Of course GÉANT's presence - in the person of Katrin Stover - was also warmly felt in the room. + +# Highlights + + +## ORCID + + +The first highlight was that ORCID made a huge showing at this meeting. Whether this was a coincidence, due to the fact that it is objectively gaining traction, or the fact that we had organised a pre-conference workshop on Open Science wherein ORCID and DataCite featured heavily, is hard to tell. At the end of the day, it doesn't matter - what matters is that the audience was hearing the same message consistently : + +> Unique identifiers and persistence are key to research output. + +Good to know we're all on the same page. + +## Service and Identity Federations + +The second big thing was the breakthrough of Identity Federations. I would perhaps be going out on a limb to say that they have "arrived" in Africa - and that's certainly not true across the board - but everyone in the room understood that Identity Federations were something that the research and education communities needed -- and what is more needed to develop amongst themselves. Federated services are being heavily promoted by all three cluster projects (MAGIC, TANDEM and Sci-GAIA) and I'm proud to say that we've helped to bring new identity providers and services online across the continent. If the old saying goes that *"You can take a horse to water, but you can't make it drink"* then perhaps in this case, the horses are starting to get thirsty ! + +With the work that Roberto Barbera and team is doing around the Catch-All Identity Federation, and the effort we're putting into the development of infrastructure services for these federations in African countries, we might well see a few new African Federations in edugain by the end of 2016. Hey, maybe it'll even be SAFIRE ! + +## e-Infrastructure and Collaboration Platforms + +The third big theme that came out of the conference was discussion around those phantomatic *"advanced services"*. Since the official theme of the Conference was "The Road to Maturity", this was on-topic, but what struck me was the maturity of the discussion and opinions. Gone is the euphoria of expectation for what "the almighty network" will bring us. "The Grid" is no longer referred to in capital letters, and we're getting a pretty good idea of what collaboration actually is : a long slog of a thousand dancers all dancing to a slightly different tune, continually stepping on each others toes and only apologising when it suits them. The real world is a harsh place ! But it's the only one we've got for now. Making it any better, unfortunately, means making it better for all - and that means working together, collectively where possible, and as I've said above, trying to support each other wherever we can. + +It was very encouraging however to see that there are new computing resources coming to light, and new investments in data capacity and people in areas of the region. Mozambique, Zambia, Kenya, Sudan, DRC, Ghana, Nigeria, all bringing systems online. I hope that we will be able to coalesce around some common goals and work together to build a platform which will benefit us all. This is clearly a pipe dream - there's no way we could even design something that broad - but I think it's a worthy ideal. In order to get anything done in the long run, we will have to pick our battles carefully - especially when the opponents are our own brothers and sisters, academically speaking ! + +## Videoconferencing, Security and Open Science + +There were as usual a very good selection of presentations from across the NREN world at the conference. I was particularly happy to see presentations on very mature videoconferencing platforms[^VidyoMconf] as well as a much-needed presentation on the development of a CSIRT in Kenya. There were a lot of good talk about Open Access and Open Science activities in Mozambique and beyond. There were also some demonstrations of mature services such as Collaboratorio and the Open Science Commons Platform being developed by Sci-GaIA. More about these in the future... + +# Thoughts + +As I sat through the presentations, I considered how all ideas and technologies sort of *have their time*. When things come ahead of their time, they fail because of lack of perceived need or a general comprehension of how things work... Nicola Tesla might have something to say about that. When ideas come to fruition after their time has passed, for whatever reason, they also fail because they are born obsolete. + +Well distributed computing is such an idea - particularly this idea that we can build common platforms for different kinds of research. It all makes sense on paper, but it's ***not paper that decides what works***, it's the communities out there. We started building massive community-based distributed computing facilities in preparation for the the LHC data... and hey - they worked very well ! Then, they took a look around and said "hey, everyone's like us - they need this too". And so the general-solution of grid computing was born. + +To be fair, a lot of people believed this over the years and many hundreds of millions of euros were spent. Some communities got productive use out of it, but not many. Especially, this was not a solution for the "generalised case"... but was it because the technology of grid computing was premature, or that the factors behind it's success in a few fields were not generally applicable ? There is no answer, this is just a point to reflect on as we embark on the construction of yet another panacea - the academic cloud. I'm willing to bet that the architects will make many of the same logical connections drawn from successful use cases and eventually convince themselves that they are doing the right thing. User communities will also be bombarded with the message : ***"You're doing it wrong"*** + +If you take umbrage, dear reader, at this crude analysis, I certainly can't fault you. However, the point of this discussion is not to find fault with the past, but to learn from it; and more even more to the point, the discussion is aimed entirely at yours truly - there's no greater critic than yourself, they say. + +So, as we embark on the development of new infrastructure in our region, moving on and learning from the good old grid paradigm, trying to make things cloudier and user-friendlier and more flexible and whatnot, I would like to keep in mind a few things : + +## **If it ain't broke don't fix it.** + +There's a lot of juice to be squeezed from the "good old grid" yet, and indeed, the Africa-Arabia Regional Operations Centre still has resources to consume. So, don't decide that we need to build something new just because it's new. + +## **Let's build _with_ users, not _for_ users** : + +Whether it's Science Gateway user interfaces, new publishing platforms, or distributed computing and data infrastructure, user experience needs to be included from the start. Sure, many communities don't know what's possible and may feel constricted in their approach, and a new analysis of the situation may bring them more productivity, but let's be on the look out for that ever present, oh-so-tempting "You're doing it wrong." + +## **Building community is better than building impunity**[^somethinglikethat] + +Perhaps "impunity" is the wrong word, but hey, it rhymes with community :smile:... + +There has to be a symbiotic relationship between research communities and research infrastructures. e-Infrastructures should probably _not_ be built by individual research communities, since that would result in huge duplication of effort, which means that true e-Infrastructures (as opposed to, say an ICT component of a research infrastructure) need to be built _with_ researchers, not simply _for_ researchers. As we need to understand their way of doing things, they need to understand by we can't just do anything they want; they - like we - would be entwined in an ecosystem. This would emphasise the long-term benefits of a healthy community over the shorter term benefits of specific project outputs. This may be hard for research groups to hear, but it may be even harder for ***funders*** to swallow, since they want to know that their money is going to the cause they want to support _right now_. + +There's no easy fix to this and not every case would follow this co-design route. We can't run a workshop or send an email or make a position paper that will make things better, because this is about a culture of sharing and collaboration and an emphasis on the "big picture", rather than a technical challenge. + +Perhaps what we can aim for is a common understanding, better and more open communication, and most of all, some ***empathy*** between those building and those using the tools of the knowledge economy. + +----- + +On that note, I leave you. Until the next meeting, somewhere warm[^Durban]. + +

Bruce Becker

+ +---- + + + + +----- + +# Footnotes and References + +[^NotSimple]: It should be pointed out that if one were to try and figure out who could take credit for this work, we'd be here until :santa: :christmas_tree: ... let's all just be happy that it works :smile: +[^cas4nren]: Thanks to Katrin Stover for reminding me of this great website. +[^VidyoMconf]: See [Kasandra's talk](http://www.ubuntunet.net/sites/default/files/23.%20Isaac%20-%20UbuntuNet%20presentation_KIsaac.pdf) on Mconf and [Rob's talk](http://www.ubuntunet.net/sites/default/files/27.%20Bristow%20-%20Rob%20Bristow%20for%20UConnect15.pdf) on Vidyo. +[^somethinglikethat]: Or something like that - it sounded right at the time. +[^Durban]: The next Ubuntunet Connect will be held in Durban, which is _very_ warm :smile: diff --git a/_posts/2015-12-07-CODE-RADE-Foundation-Release-1.md b/_posts/2015-12-07-CODE-RADE-Foundation-Release-1.md new file mode 100644 index 0000000..e24ab0a --- /dev/null +++ b/_posts/2015-12-07-CODE-RADE-Foundation-Release-1.md @@ -0,0 +1,166 @@ +--- +layout: post +title: 'CODE-RADE Foundation Release 1' +description: 'Stuff you can use to build other stuff and a few demo applications' +headline: "It's finally public" +category: blog +tags: [blog, CODE-RADE, Release] +image: + feature: tumblr_mw87ofGfHW1sfie3io1_1280.jpg + attribution: "Image courtesy of New Old Stock - http://nos.twnsnd.co/image/69699793933" +comments: false +mathjax: false +discourse: true +--- + + +- [Announcing CODE-RADE Foundation Release 1](#announcing-code-rade-foundation-release-1) +- [Goal and Design](#goal-and-design) + - [CODE-RADE is Open Source](#code-rade-is-open-source) + - [Targets](#targets) + - [Artifacts](#artifacts) + - [Dependencies](#dependencies) + - [Build Configurations](#build-configurations) +- [Repositories](#repositories) +- [Using CODE-RADE](#using-code-rade) +- [Roadmap and planning](#roadmap-and-planning) + + +# Announcing CODE-RADE Foundation Release 1 + +We are pleased to announce the first **Foundation Release** of the CODE-RADE project : + +
+

Continuous Delivery of Research Applciations in a Distributed Environment.

+ +

Build Test Execute Everywhere

+
+ +This release has been the result of the efforts of several people, and in particular the input of Sakhile Masoka, Fanie Riekert and Dane Kennedy is warmly acknowledged. + +# Goal and Design + +Simply put,the goal of the CODE-RADE project is to provide a user-driven, high-quality, continuous delivery platform for research applications to any site which wants them. The platform has been designed based on widely-used components and tools : + + * Source code repositories : Github + * Continuous Integration : Jenkins + * Continuous Delivery : CVMFS + * Service Orchestration : Ansible + +CODE-RADE fills a gap between the user or research software engineer who wants to have their applications available on a distributed computing infrastructure, and the site administrator who is tasked with keeping resources available and properly configured. This user- and test-driven approach allows for continuous integration and delivery of new research applications into a common repository which can be permanently configured at all participating sites. + +
+ +
CODE-RADE workflow and actors. doi: 10.15169/sci-gaia:1463574603.05
+
+ +## CODE-RADE is Open Source + +The platform itself is expressable in terms of Jenkins configurations and build, test and deploy scripts. The entire platform can be reproduced, although this is not currently automated. Source configuration for the platform, as well as other supporting configurations can be found at : +
+ The CODE-RADE repo in AAROC on Github +
+ +## Targets + +CODE-RADE aims to deliver prebuilt applications to any site that wishes to execute them. In order to do this, the applications need to be compiled for a range of target sites, which may vary in operating system, CPU architecture, or in other ways such as network interconnect, availability of GPU's, etc. Each of these aspects are axes in the build system and define a build matrix as follows: + + + + + +
SITEA code used to describe the particular nature of the site. Currently only generic is used for all sites.
ARCHThe CPU architecture used at the site. Currently only x86_64 is used for all sites.
OSThe operating system used at the sites. Currently only sl6 and u1404 are used for RedHat6 and derivatives and Ubuntu 14.04 LTS are used respectively
+ +## Artifacts + +Foundation Release 1 publishes three CVMFS repositories and several base libraries necessary for compiling other applications. + +***For this reason, the release is called a "Foundation" - this provides you stuff to build other stuff.*** + +Several projects have been built: + + * [GCC Compiler toolchain](http://www.africa-grid.org/applications/#compilers) + * [Math libraries](http://www.africa-grid.org/applications/#libraries) + * [HPC libraries](http://www.africa-grid.org/applications/#libraries) + * [Python framework](http://www.africa-grid.org/applications/#python) + +Libraries are compiled with their dependencies expressed using module files and where possible several versions of the library are built in order to check for consistency and provide a wide as possible coverage. A tradeoff has had to be made between coverage and build times due to the limited resources of the build slaves. + +Details of the projects and builds can be seen on the [Foundation Release 1](http://ci.sagrid.ac.za/view/Foundation%20Release%201/) page. + +## Dependencies + +Dependencies are managed using the bash modules tool, and by relevant build triggers in Jenkins. Software dependencies have been expressed using these build triggers and inspiration has been taken from the [Easybuild](https://easybuild.readthedocs.org/en/latest/) project. Other information on the dependencies of applications have been obtained from the project description pages. + +The artifacts are built from the lowest-lying dependencies, up through the dependency chain, to end-user applications. Each build is responsible for creating it's own modulefile. + +## Build Configurations + +All build configurations are kept in change control. CODE-RADE has been designed to execute builds and tests of user-provided configuration on every commit to the source code management system. As the default SCM, we have chosen git and rely on the Github API to trigger most builds in Jenkins. While we do not have an explicit internal API, there is a working model of how builds should be configured, relying on three separate scripts executed in conditional sequence : + + 1. `build.sh` - This starts the configuration and compilation of the application, with relevant dependencies added + 1. `check-build.sh` - if the compilation has been performed without error, this script performs application-specific checks, usually provided by the project itself (typically runnning `make check` or similar) + 1. `deploy.sh` - Once the application has been checked and staged to the continuous integration environment, this script reconfigures the build to the actual CVMFS target. This usually just involves a cleanup of the configuraiton and a re-installation to a different prefix. + +There are several limitations to this approach, not least the capacity for user error, since there are almost no checks on the content of the scripts. The possibility of using a domain-specific language or a build-flow approach has been considered, but + +# Repositories + +CVMFS is used to distribute the artifacts to the sites. There is a Stratum 0 CVMFS server at the University of the Free State at `apprepo.sagrid.ac.za`. Three repositories have been created for differing use cases : + + + + + + + + + + + + + +
fastrepo: Repository containing all successful builds
devrepo: Repository containing successful builds which have been tested by humans
apprepo: Repository containing all production software used at all sites.
+ +For more information on the repositories and how to use them, see [the AfricaGrid webpage](http://www.africa-grid.org/cvmfs) + +# Using CODE-RADE + +With this release, the tools necessary for integrating new applications from any user are available. They can be used by mounting the repositories directly on your laptop or cluster, using the [Ansible playbook](https://github.com/AAROC/DevOps/blob/master/Ansible/cvmfs.yml) or [scripts](https://github.com/AAROC/CODE-RADE/tree/master/cvmfs) provided. The repositories are usually mounted under `/cvmfs`, _e.g._ `/cvmfs/fastrepo.sagrid.ac.za` + +## Adding and using modules + +Modules can be used by adding them to your module library : + + module use /cvmfs/fastrepo.sagrid.ac.za/compilers + module avail + ---- /cvmfs/fastrepo.sagrid.ac.za/modules/compilers ---- + gcc/4.9.2 gcc/5.1.0 + ---- /usr/share/modules/versions ---- + 3.2.10 + ---- /usr/share/modules/modulefiles ---- + dot module-git module-info modules null use.own + +The environment variables `SITE`, `OS`, `ARCH` and `CVMFS_DIR` are needed to use the modules properly on your site. You can set them by hand or use the [set script](https://github.com/AAROC/CODE-RADE/blob/master/modules.sh) in the CODE-RADE repo. + +## Contributing + +Should you be interested in contributing to the CODE-RADE project, you can : + + 1. Add applications - Use the [demo repo](https://github.com/SouthAfricaDigitalScience/my-first-deploy) to see how to build and test applications. We can create the job in Jenkins and from there on out, your commits will trigger builds. + 1. Review applications - Have we configured the builds properly ? Are the applications properly configured ? You can see all of the applications that we support at github.com/SouthAfricaDigitalScience. + 1. Applications can also be discussed at the [African e-Infrastructures Forum](https://discourse.sci-gaia.eu) under the [Applications category](https://discourse.sci-gaia.eu/c/applications). + + +# Roadmap and planning + + +This is the first release of the CODE-RADE platform; new applications and builds are continuously added to the repositories. Further releases will contain more tooling (different compilers, application libraries and application dependencies). The [Release Milestone](https://github.com/AAROC/CODE-RADE/milestones/Infrastructure%20foundation%20release%201) issues have all been closed. + + * Issues and requests can be made via the [project board](https://waffle.io/AAROC/CODE-RADE). + * Milestones are described describe at [the CODE-RADE repo](https://github.com/AAROC/CODE-RADE/milestones) on github. + + +We use Slack to keep in touch while developing, and automation talks to us in [\#code-rade](https://africa-arabia-roc.slack.com/messages/code-rade). If you would like to help us deliver software better to researchers, get in touch and come hang out with us (and our trusty bots.). + +---- diff --git a/_posts/2016-01-02-CODE-RADE-roadmap.md b/_posts/2016-01-02-CODE-RADE-roadmap.md new file mode 100644 index 0000000..55bb4e2 --- /dev/null +++ b/_posts/2016-01-02-CODE-RADE-roadmap.md @@ -0,0 +1,158 @@ +--- +layout: post +title: 'CODE-RADE Roadmap' +description: 'When will we have flying cars ?' +category: blog +tags: [blog, CODE-RADE, Release] +image: + feature: cb174b18a69d470e8fee59a90d5698ba.jpg + attribution: +comments: false +mathjax: false +discourse: true +--- + +# TL;DR Most major components are in place, it's time to start expanding + +# What is this old-school release business ? + +I know, you're probably thinking "Hey ! This was supposed to be a _continuous_ integration project, what's with the whole ***release*** thing ? Aren't *releases* so old school ?". And you know what,you're right, dear reader. Not to say that we're doing this continuous thing _right_, but we have gone to some lengths to do away with the waterfall and be more agile - when builds pass, they really do get shipped, at every pass. What we're talking about here is more about the planning of the _effort_ of the project, and trying to give end users some idea of _when_ components might be ready. +We have organically defined two kinds of releases : + + - **Foundation Releases**: for developers + - **Public Releases**: for users + +The utility of separating these releases is to allow us to provide a stable foundation to users who want to work on their own applications, whilst also providing the possibility to flesh out the core capabilities of the system without impacting on the user-side. + +## Continuous and Staged Integration and Delivery. + +A few words about how continuous our continuous integration actually is. + +### What is tested ? + +While we _do_ do continuous integration and delivery of every component of CODE-RADE, this is only true for one of the CVMFS repositories which we provide - fastrepo. Fastrepo is configured to contain every application which passes automated tests. While we _do_ insist that users who propose applications include these tests in their build scripts, there is currently no actual independent check on the build artifacts to see whether they are beningn and actually executable from the repository. There are _impicit_ checks in the sense that if the application needs components which are not in the repository and not available in the execution environment, then builds will fail, but the main point is that we don't actually check that the scripts provided by the user are actually building anything. There is also the technical aspect of the CVMFS repository, since repositories need to be declared "volatile" if they are expected to be changing rapidly. + + +## Human checks + +So, we have a tradeoff between automation and certification, by separating the build artifacts into separate CVMFS repositories. Everything that passes goes into fastrepo, and things that are checked by humans go into the next repo - devrepo. This process requires a recompilation to point the code to the new filesystem root, and we haven't implemented that yet. + +The current repository fastrepo is currently the only one with the full set of applications, and is continuously integrated and delivered. We will be implementing staged delivery from Foundation Release 3. + +# Foundation Release 2 + +We have released only one Foundation ([Foundation Release 1]), which contained a basic set of tools necessary to build other tools. Foundation Release 2 will include : + + * further base libraries which are not guaranteed to be available on the execution nodes[^SameVersion] + * More versions of math libraries such as various versions of, BOOST, LAPACK and BLAS, as well as sparse matrix libraries in SuiteSparse + * More versions of the GCC compiler and MPI libraries, including MPICH[^OpenMPI]. + * I/O libraries such as HDF5 + * common tools such as gnuplot, octave + * Python and associated libaries and such as the SciPy suite. + +This Foundation Release will allow users to build a wider set of useful applications, thanks to the wider set of libraries which can be used. These applications will be included in the Public Releases. + +**Foundation Release 2 is scheduled for 1 March 2016.** + +# Public Release 1 + +Public Releases include the _end-user_ applications. For Public Release 1, these include : + + * [AbInit](http://www.abinit.org) + * [GAMESS](http://www.msg.ameslab.gov/gamess/) + * [Repast Symphony](http://repast.sourceforge.net/) + * [ABySS](http://www.bcgsc.ca/platform/bioinfo/software/abyss) + * [OpenFOAM](http://www.openfoam.org/) + * [AutoDock](http://www.openfoam.org/) + * [Velvet](https://www.ebi.ac.uk/~zerbino/velvet/) + * [OASES](https://www.ebi.ac.uk/~zerbino/oases/) + * [GROMACS](http://www.gromacs.org) + * [WEKA](http://www.cs.waikato.ac.nz/ml/weka/) + * [WRF](http://www.wrf-model.org) + * [PLink](http://pngu.mgh.harvard.edu/~purcell/plink/) + * [HEASoft](http://heasarc.nasa.gov/lheasoft/) + * [Pythia8](http://home.thep.lu.se/~torbjorn/Pythia.html) + * [freefem++](http://www.freefem.org/ff++/) + * [CosmoMC](http://cosmologist.info/cosmomc/) + * [Gadget-2](http://wwwmpa.mpa-garching.mpg.de/gadget/) + * [HTK](http://htk.eng.cam.ac.uk/) + * [MITLM](https://github.com/mit-nlp/mitlm) + * [quantum-espresso](http://www.quantum-espresso.org/) + * [GAMA-platform](https://github.com/gama-platform/gama/wiki) + * [IMA2-deploy](https://bio.cst.temple.edu/~hey/software/software.htm) + +The full list of applications and their state can be seen at [africa-grid.org/applications](http://www.africa-grid.org/applications) + +**Public Release 1 is expected on 30 April 2015**. + +# Collaborating. + +The CODE-RADE project has been designed with the lowest possible barrier to entry and contrbutions and collaborators are very welcome. There are several ways in which you could contribute or collaborate : + +## Requesting new applications + +If you would like to have an application included in CODE-RADE, simply [make a request](https://github.com/AAROC/CODE-RADE/issues/new?title=%22Application%20Request%22&labels=request). The collaborators will evaluate the request and decide on which release (and thus priority) it should be assigned to, based on the dependencies and complexity of the application. + +## Bring your own application + +If you are entirely responsible for your application, we can create the job in Jenkins and allow you to independently develop the scripts which build and deploy it. Self-service ! +
+
+

+
+
+ +## Improve and learn + +If you would like to help us improve the system, or individual sub-projects in CODE-RADE, there are many ways to do this. You can adopt an application which is currently failing and help us diagnose build failures. Code review is also a helpful way of improving the quality of the project. + + +## Request CODE-RADE at your university or lab + +If you're interested in using CODE-RADE, why not ask the administrator of your local computing facility to enable it. Adding CODE-RADE to a site is a once-off procedure, since the project is designed to reduce overhead for system administrators. See the [Africa-Grid website](http://www.africa-grid.org/cvmfs/) for instructions. +
+
+

+
+
+ + + +# CODE-RADE works Open + +Everything in CODE-RADE is Open with a capital O. From the design to the process to the validation, we welcome input and contrbutions from any researcher with an interest in delivering and using high-quality, easy-to-use research applications. Here are some contact points : + +
+
+
All the code we use to build applications is in the CODE-RADE repository as submodules. Individual repositories are in the SouthAfricaDigitalScience organisation. However, if you want to work on your own application, you can host your scripts in your own repository on github.
+
+
+
+ +
+
The CODE-RADE project planning is done on the Waffle Board which is publicly visibile.
+
+
+
+
+
You can see the details of each build at the CODE-RADE build server which is publicly visible. +
+
+
+
+
+
Discuss the development of the project itself or individual components at the African e-Infrastructures Discussion Forum +
+
+ + +Finally, we will be using CODE-RADE as part of the [Sci-GaIA winter school](http://www.sci-gaia.eu/winter-school/) for application porting to science gateways. In preparation for this, we are working on a short self-paced course in order for those interested in developing for CODE-RADE to understand how the system works and gain the necessary skills to contribute efficiently. The course will be delivered via the [Sci-GaIA online learning platform](http://courses.sci-gaia.eu). + +Looking forward to great things + +
+ +# Footnotes and References + +[^OpenMPI]: We initially only served OpenMPI, however some applications such as WRF require MPICH explicitly. +[^SameVersion]: These include widely-used, but sometimes absent libraries, such as bzlib, curl, freetype, libpng, sqlite, tcltk, _etc_. In most cases, we build the same version as is by default found in the OS repositories is built, along with the most recent version. diff --git a/_posts/2016-01-12-CODE-RADE-modules.md b/_posts/2016-01-12-CODE-RADE-modules.md new file mode 100644 index 0000000..ad7be6e --- /dev/null +++ b/_posts/2016-01-12-CODE-RADE-modules.md @@ -0,0 +1,72 @@ +--- +layout: post +title: 'CODE-RADE submodules' +description: 'Consolidating work' +category: blog +tags: [blog, CODE-RADE, Release] +image: + feature: tumblr_mxah7dcExT1sfie3io1_1280.jpg + attribution: "" +comments: false +mathjax: false +discourse: true +--- + +# TL;DR - All the apps we build and test are linked from a single repo. + +This is just a short update on progress with the CODE-RADE project with a description of where to find the code and how to contribute. + +# How testing works. + +A huge aspect of CODE-RADE is modularity - we build and test nodes in a dependency tree, from base dependencies all the way up. Instead of providing a single binary result (yes, the repo is working, no there are problems), we provide a result for each node in the tree. Specifically, that means that every application is compiled against its dependencies and tested before the next node in the tree is done. + +A second aspect of CODE-RADE is continuous integration - tests would run at _every commit_ of code to a repository. Modularity implied that only the node that has changed should be tested, and that this test should trigger all of the upstream tests in order to see if there were regression problems. The alternative would be to have monolithic testing where the full tree was traversed on a predetermined schedule, taking into account any changes that had been made. + +While these two approaches are not necessarily contradictory, the first had the agility which we felt was one of the strong points of CODE-RADE for community adoption, and the benefit of giving fairly fast responses[^fast] to any changes made by a contributor. + +Originally, we had the idea that everything would go into a [single repository](https://github.com/SAGridOps/SoftwareInstallation), making it easy to publish and collaborate. However, when it came to configuring the triggers of the Jenkins, it was easiest to have a single repository to listen to: + +
+ +
Jenkins jobs can be assocated with a github repository, using the Github plugin
+
+ +
+ +
Jenkins provides for many build triggers which determine under which condition or event the job will be executed. Using the Github API, changes made the repository associated with the job can act as these triggers. +
+
+ +This meant that we made the choice to separate each node in the dependency tree into its own git repository - most of them under the [SouthAfricaDigitalScience Github organisation](https://github.com/SouthAfricaDigitalScience/). This made testing the components easier, as well as the creation of the dependency tree - and while all of the repos were in one organisation, it may even be manageable - but as soon as we start including different repos, the complexity may become an inhibiting factor. + +
+ +
Jenkins jobs can be configured with source code management (SCM). One of these methods is git, and each project can have one git repository, depending on the plugins in use.
+
+ +So we have a dilemma : In order to keep testing atomic, we need to have individual repositories for nodes in the dependency graph, but in order to present a coherent code base to promote collaboratation, we need a single repository ? + +# Git submodules to the rescue. + +Fortunately, this is an issue often encountered by software built on dependencies, with external plugins or similar. One of the most common solutions to the problem is to add the external bits as [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules). Indeed from the git submodules documentation[^submodules] : + +> It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. + + +This indeed seems like our case. We want to have a single point of entry for collaborators and applications - [the CODE-RADE main repository](https://github.com/AAROC/CODE-RADE), while still keeping the modularity which allows atomic testing and integration. + +# Onward, then ! + +So, I've started adding submodules to a [subdirectory](https://github.com/AAROC/CODE-RADE/tree/master/applications) of the CODE-RADE repo, and will soon have all of them included. The CODE-RADE repo itself will not get tested, but it will be possible to fork it including the submodules and send pull requests. These will get tested only by the specific job which is configured to listen to changes in the submodule repository, _i.e._ if changes are made in the `gcc-deploy` submodule, and this pull request is sent to the CODE-RADE repo, only the [gcc-deploy](http://ci.sagrid.ac.za/job/gcc-deploy/) job will get triggered. + +Modules, yo. + +For more information, see the [build server](http://ci.sagrid.ac.za) +
+ +
+ +# References and Footnotes + +[^fast]: Of course "fast" here depends on the time needed for the actual compilation. The longest compilation time we have is for the [GCC project](http://ci.sagrid.ac.za/job/gcc-deploy) which can take up to 10 hours. +[^submodules]: Taken from the [Git submodules documentation page](https://git-scm.com/book/en/v2/Git-Tools-Submodules). Accessed 16-01-2016. diff --git a/_posts/2016-02-08-CODE-RADE-sitrep.md b/_posts/2016-02-08-CODE-RADE-sitrep.md new file mode 100644 index 0000000..7f3c3d9 --- /dev/null +++ b/_posts/2016-02-08-CODE-RADE-sitrep.md @@ -0,0 +1,329 @@ +--- +layout: post +title: 'CODE-RADE sitrep Feb 2016' +description: 'CODE-RADE Situation Report for February 2016' +category: blog +tags: [blog, CODE-RADE] +image: + feature: photo-1453814279372-783dc5b638ae.jpeg + attribution: "Image courtesy of New Old Stock - http://nos.twnsnd.co/image/69699793933" +comments: false +mathjax: false +discourse: true +--- + +# TL;DR - Two releases coming up : Where we at ? + +[A recent post]({{ site_url }}/blog/2016/01/02/CODE-RADE-roadmap/) discussed the roadmap for the CODE-RADE project, and put forward [two important dates for releases](https://github.com/AAROC/CODE-RADE/milestones) : + + * [Infrastructure Foundation Release 2](https://github.com/AAROC/CODE-RADE/milestones/Infrastructure%20foundation%20release%202) - ***01/03/2016*** + * [Public Release 1](https://github.com/AAROC/CODE-RADE/milestones/CODE-RADE%20Public%20Release%201) - ***29/04/2016*** + +Here's a quick update of where we're at[^Public] + +# Things in + + +## Abinit + +Abinit is configured to build for: + + * OS : **u1404**, **sl6** + * VERSION : **7.10.5** + * GCC Version : **4.9.2**, **5.1.0** + +All of the dependencies of Abinit are passing : + + * fftw3 + * gsl + * lapack + * netcdf + +This is a good place to be, but abinit itself is failing on all targets due to the FFTW3 dependency. The error is described in [#4](https://github.com/SouthAfricaDigitalScience/abinit-deploy/issues/4). + +**TODO** - check what kind of FFT Abinit wants. + +## GADGET-2 + +GADGET is configured to be compiled with + + * fftw2 + * openmpi + * gsl + * hdf5 + +The job is not yet complete, since the `check-build.sh` and `deploy.sh` scripts are missing. There seems to be some misconfiguration with the makefiles, which need to be checked. + +## GROMACS + +Gromacs is configured for the targets: + + * VERSION : **5.1.1** + * GCC Version : **4.9.2**, **5.1.0** + * OpenMPI version : **1.8.1**, **1.8.8** + +Gromacs depends on + + * boost + * fftw3 + * lapack + +as well as the aforementioned GCC and OpenMPI. GROMACS is currently suffering from the wrong FFTW configuration. The build is configured as : + +{% highlight shell %} + +cmake ../ \ +-G"Unix Makefiles" \ +-DCMAKE_C_COMPILER=mpicc \ +-DCMAKE_CXX_COMPILER=mpicxx \ +-DGMX_X11=OFF \ +-DGMX_FFT_LIBRARY=fftw3 \ +-DGMX_DOUBLE=OFF \ +-DGMX_GPU=OFF \ +-DGMX_OPENMP=ON \ +-DGMX_MPI=ON \ +-DGMX_EXTERNAL_BLAS=on \ +-DGMX_BUILD_MDRUN_ONLY=ON \ +-DCMAKE_PREFIX_PATH=${BOOST_DIR}/boost;${LAPACK_DIR};${FFTW_DIR};${OPENMPI_DIR} \ +-DREGRESSIONTEST_DOWNLOAD=ON \ +-DCMAKE_INSTALL_PREFIX=${SOFT_DIR}/${VERSION}-gcc-${GCC_VERSION}-mpi-${OPENMPI_VERSION} + +{% endhighlight %} + +However, this is failing with the following error message : + + +> -- pkg-config could not detect fftw3f, trying generic detection +> Could not find fftw3f library named libfftw3f, please specify its location in CMAKE_PREFIX_PATH or FFTWF_LIBRARY +> by hand (e.g. -DFFTWF_LIBRARY='/path/to/libfftw3f.so') +> CMake Error at cmake/gmxManageFFTLibraries.cmake:81 (MESSAGE): + +> Cannot find FFTW 3 (with correct precision - libfftw3f for mixed-precision +> GROMACS or libfftw3 for double-precision GROMACS). Either choose the right +> precision, choose another FFT(W) library (-DGMX_FFT_LIBRARY), enable the +> advanced option to let GROMACS build FFTW 3 for you +> (-DGMX_BUILD_OWN_FFTW=ON), or use the really slow GROMACS built-in fftpack +> library (-DGMX_FFT_LIBRARY=fftpack). + + +The error doesn't seem to be in `CMAKE_PREFIX_PATH`, so it is likely in one of the FFTW variables. + +**TODO** : Find out how to specify the correct FFTW3 configuration + +**Update** : 10/02 - fixed in [d8e48ec5](https://github.com/SouthAfricaDigitalScience/gromacs-deploy/commit/d8e48ec5b480af486d95e3daaf2270a97bee9636), however GROMACS in the repo only contains `mdp_mpi` and none of the other executables. Need to revisit the configuration. + +## Python + +Python is one of the generic frameworks which is difficult to treat like the other applications in CODE-RADE, because it has it's own package management tools and internal dependency management. It also doesn't usually deal with modules, rather using it's own `virtualenv` to deal with different versions of Python and different modules within it. However, it can still be built from source, and the supporting applications which it uses - `pip`, `easy_install`, *etc* can be added to it. Care should be taken to use the python environment variables properly in order to ensure that the subsequent python modules such as those in the SciPy suite, are installed and delivered correctly. + +The current overview of the status of python is : + +
+ +
Snapshot of the status of Python at build 26 - current at the time of writing
+
+ +Python currently depends on + + * bzlib + * ncurses + * readline + * sqlite + * tcltk + * zlib-deploy + +which are all currently passing. + +Python 2.6 and Python 2.7 are failing as follows. + +### Python 2.6 + +Python 2.6 needs setuptools. This is downloaded as part of the build script, but fails immediately with : + +{% highlight python %} +Traceback (most recent call last): + File "setup.py", line 21, in + exec(init_file.read(), command_ns) + File "", line 11, in + File "/var/lib/jenkins/workspace/python-deploy/ARCH/x86_64/GCC_VERSION/4.9.2/NAME/python/OS/u1404/SITE/generic/VERSION/2.6.9/Python-2.6.9/setuptools-18.3.2/setuptools/__init__.py", line 12, in + from setuptools.extension import Extension + File "/var/lib/jenkins/workspace/python-deploy/ARCH/x86_64/GCC_VERSION/4.9.2/NAME/python/OS/u1404/SITE/generic/VERSION/2.6.9/Python-2.6.9/setuptools-18.3.2/setuptools/extension.py", line 8, in + from .dist import _get_unpatched + File "/var/lib/jenkins/workspace/python-deploy/ARCH/x86_64/GCC_VERSION/4.9.2/NAME/python/OS/u1404/SITE/generic/VERSION/2.6.9/Python-2.6.9/setuptools-18.3.2/setuptools/dist.py", line 16, in + from setuptools.depends import Require + File "/var/lib/jenkins/workspace/python-deploy/ARCH/x86_64/GCC_VERSION/4.9.2/NAME/python/OS/u1404/SITE/generic/VERSION/2.6.9/Python-2.6.9/setuptools-18.3.2/setuptools/depends.py", line 6, in + from setuptools import compat + File "/var/lib/jenkins/workspace/python-deploy/ARCH/x86_64/GCC_VERSION/4.9.2/NAME/python/OS/u1404/SITE/generic/VERSION/2.6.9/Python-2.6.9/setuptools-18.3.2/setuptools/compat.py", line 28, in + import urllib2 + File "/apprepo/generic/u1404/x86_64/python/2.6.9-gcc-4.9.2/lib/python2.6/urllib2.py", line 93, in + import hashlib + File "/apprepo/generic/u1404/x86_64/python/2.6.9-gcc-4.9.2/lib/python2.6/hashlib.py", line 138, in + sha224 = __get_builtin_constructor('sha224') + File "/apprepo/generic/u1404/x86_64/python/2.6.9-gcc-4.9.2/lib/python2.6/hashlib.py", line 66, in __get_builtin_constructor + import _sha256 +ImportError: No module named _sha256 +{% endhighlight %} + +It seems that Python has not built the sha256 library. + +## Python 2.7 + +Python 2.7 seems to have passed `build` and `check-build`, but when cleaning the build directory at the start of `deploy` we get the following error : + +{% highlight shell %} ++ ./deploy-2.7.11.sh +rm: cannot remove `build/lib.linux-x86_64-2.7': Directory not empty +{% endhighlight %} + +This is thrown by the lines + +{% highlight shell %} +cd ${WORKSPACE}/Python-${VERSION}/build-${BUILD_NUMBER} +rm -rf * +{% endhighlight %} + +This could easily be circumvented by a quick hack, but the origin of the problem is not understoo _(yet)_ + + +## Quantum Espresso + +Quantum Espresso is having issues compiling against the LAPACK libraries provided. + + +## WRF + +The Weather Research and Forecasting model is very widely used in meteorology and climatology. It depends on + + * hdf5 (compiled with MPI) + * jasper + * mpich + * netcdf (compiled with MPI) + +all of which are passing. + +The project files are not yet ready, so this build is failing to find the scripts. Although the build has been tested locally using the artifacts in `fastrepo`, this has only been done by hand and the scripts have not yet been committed to the repo. + +## The rest + +There are [several applications](http://www.africa-grid.org/blog/2016/01/02/CODE-RADE-roadmap/) which have been proposed for the Public Release. Apart from those described above, we have the list below. A short summary of the status of each is given. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDependenciesComment
GAMESSHDF5Dependencies all fulfilled, but not tested locally
Repast SymphonyJavaDependencies all fulfilled, but not tested locally
ABySSBOOST, Sqlite, SparseHashSparseHash is not yet in Foundation Release, but is WIP.
OpenFOAMBOOST, OpenMPI, gnuplot, readline, ncursesgnuplot is not yet in Foundation Release.. The OpenFOAM job and repo are present, but only the build script is prepared.
AutoDockNone, apparentlyLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
VelvetOpenMPLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
OASESOpenMP, zlib, VelvetLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
WEKAJava JDKJDK has been added with build 113 of fastrepo and WEKA has been tested manually. Compilation is not clear yet.
PLinkzlib (uses it's own compiled version), LAPACKManual tests have passed.
Pythia8Several CLHEP and CERN libraries necessaryThis one will take a while still.
FreeFem++GSL, OpenMPI/MPICH, PETSc, LAPACK, BLAS, SuiteSparse, FFTW3, HDF5. Most of these can be downloaded by the compilation scripts proivded by the package, but that would be a bit couter to the CODE-RADE philosophy.
CosmoMCpmclib, CAMB, GSL, FFTW3, LAPACK, WMAP, fitsioWMAP, pmclib, CAMB and WMAP are missing. The rest have been integrated. CAMB needs HealPix and Fisher. Work has started on Healpix
Gadget 2FFTW2, GSL, HDF5Work has started, the repo has been created as well as the job. Check and deploy scripts are still to be committed. FFWT2 needs to be compiled with MPICH, it is currently only compiled with OpenMPI
HTKnoneLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
MITMLnoneLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
GAMA-PlatformJava JDKJDK has been added with build 113 of fastrepo and Gama has been tested manually. Compilation is not clear yet.
IMA-2noneLow hanging fruit ? Need to add the scripts to the repo and create the Jenkins job.
+
+ +# Next steps. + +The applications which have been described as low-hanging fruit are going to be added over the next few days. Significant work needs to be done for a few of the other ones, and lower-lying dependencies need to be added and compiled for different targets. We look forward to having some contribution from those interested, and using some of these as example applications in the upcoming [Sci-GaIA winter school](http://www.sci-gaia.eu/winter-school). + +For now, let's keep +
+
+
+
+ +
+
+
+
+ +# Footnotes and References + +[^Public]: We'll report only on the user applications in the Public Release diff --git a/_posts/2016-02-17-EGI-SVG-CVE-2015-7547.md b/_posts/2016-02-17-EGI-SVG-CVE-2015-7547.md new file mode 100644 index 0000000..b75e8eb --- /dev/null +++ b/_posts/2016-02-17-EGI-SVG-CVE-2015-7547.md @@ -0,0 +1,25 @@ +--- +layout: post +type: status +title: 'A CRITICAL-severity risk has been announced : glibc remote code execution.' +description: 'EGI SVG Advisory : glibc' +headline: "glibc remote code execution" +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2015-7547 ] +image: + feature: '' + attribution: +comments: false +--- + +# Update glibc by 20/02/2016 ! + +There is a CRITICAL-severity vulnerability in `glibc`. This affects almost every process running on a Linux system, so EGI reccomends applying the patch and simply re-booting the machine after applying package updates. + +## Site administrators - please schedule a downtime in the GOC + +The downtime should be minimal, however, if anything goes wrong, this will protect your reliability computation. + +# For more information + +Please see [the EGI SVG wiki](https://wiki.egi.eu/wiki/SVG:Advisory-SVG-CVE-2015-7547) for further details and updates. diff --git a/_posts/2016-03-02-DROWN.md b/_posts/2016-03-02-DROWN.md new file mode 100644 index 0000000..82629da --- /dev/null +++ b/_posts/2016-03-02-DROWN.md @@ -0,0 +1,58 @@ +--- +layout: post +type: status +title: 'DROWN Attack vulnerability' +description: 'CSIRT Vulnerability advisory : DROWN' +headline: "Check your SSL layers !" +category: security +tags: [AAROC, CSIRT, operations, security, updates, DROWN, CVE-2016-0800 ] +image: + feature: '' + attribution: +comments: false +discourse: true +--- + +# TL;DR - SSLv2 is vulnerable, use TLS + +We have received notification from the [SANREN CSIRT](mailto:csirt@sanren.ac.za) of the [DROWN Vulnerability - Decrypting RSA using Obsolete and Weakened eNcryption)](https://drownattack.com), AKA **CVE-2016-0800** : + +> Although there is much hype around such vulnerabilities it is rated as IMPORTANT and seems serious enough for us to send out this notification particularly as the tester identifies weak SSL configurations / vulnerable library versions which may be subject to other vulnerabilities. +> Please see this [drownattack.com](https://drownattack.com) to see if you are vulnerable +> You should test your domains at the above site and mitigate if necessary. + +# Mitigation + +If you discover a problem affecing one or more web serivces at your site, the CSIRT recommends the following action for mitigation : + +> ... mitigation involves disabling support for SSLv2 and possibly updating SSL libraries (e.g. OpenSSL). +> Shared keys/certificates with a vulnerable server also present a risk. + +# AAROC DevOps Vulnerability and Mitigation + +We do not currently have a check in our [DevOps](https://github.com/AAROC/DevOps) repo for the Ansible or Puppet configurations of services such as the web interface for the IdP. There is no proactive monitoring of this vulnerabity. If necessary, a playbook to apply mitigation strategies could be developed. + +This vulnerability should *not* have been introduced by any AAROC playbooks, since the web services orchestrated by our Ansible roles explicitly disable SSLv2 : + +{% highlight bash %} +grep -ir sslv2 * +Ansible/roles/glassfish/templates/etc/httpd/conf.d/virtualhost.conf.j2:# connect. Disable SSLv2 access by default: +Ansible/roles/glassfish/templates/etc/httpd/conf.d/virtualhost.conf.j2:#SSLProtocol all -SSLv2 +Ansible/roles/glassfish/templates/etc/httpd/conf.d/virtualhost.conf.j2:#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW +Ansible/roles/glassfish/tem.conf:# connect. Disable SSLv2 access by default: +Ansible/roles/glassfish/tem.conf:#SSLProtocol all -SSLv2 +Ansible/roles/glassfish/tem.conf:#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW +Ansible/roles/glassfish/files/etc/httpd/conf.d/virtualhost.conf:# connect. Disable SSLv2 access by default: +Ansible/roles/glassfish/files/etc/httpd/conf.d/virtualhost.conf:#SSLProtocol all -SSLv2 +Ansible/roles/glassfish/files/etc/httpd/conf.d/virtualhost.conf:#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW +Ansible/roles/liferay-csgf/templates/etc/virtualhost.conf.j2:# connect. Disable SSLv2 access by default: +Ansible/roles/liferay-csgf/templates/etc/virtualhost.conf.j2:#SSLProtocol all -SSLv2 +Ansible/roles/liferay-csgf/templates/etc/virtualhost.conf.j2:#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW +Ansible/roles/fts/files/etc/httpd/conf.d/webfts.conf: SSLProtocol all -SSLv2 +Ansible/roles/fts/files/etc/httpd/conf.d/webfts.conf: SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW +{% endhighlight %} + + +## For more info, contact the [SANREN CSIRT](mailto:csirt@sanren.ac.za). + +Thanks to Roderick Mooi from SANREN CSIRT for the heads-up. diff --git a/_posts/2016-03-06-DevOpsPrep.md b/_posts/2016-03-06-DevOpsPrep.md new file mode 100644 index 0000000..0fbb900 --- /dev/null +++ b/_posts/2016-03-06-DevOpsPrep.md @@ -0,0 +1,44 @@ +--- +layout: post +title: 'Prep for DevOps Bootcamp' +description: 'Getting ready for the DevOps for Federation course' +category: blog +tags: [blog, Sci-GaIA, DevOps, eko-Konnect] +image: + feature: 220110409213151001_4957481_ver1.0_640_480.JPG + attribution: "" +comments: false +mathjax: false +discourse: true +--- + +# It's DevOps time again ! + +We're very proud to announce that we are teaming up with [Eko-Konnect](http://www.eko-konnect.org.ng/) and [WACREN](http://wacren.net/) to bring the [DevOps for Federation](http://www.eko-konnect.org.ng/content/devops-federated-services-8-10-march-2016) workshop to Lagos, from 8-10 March 2016. This will be an iteration on the first course run in collaboration with [GARR](www.garr.it) last year and will consist of three days of training in DevOps tools and culture, and their application to the deployment of federated identity and service providers. + +# Preparation + +For those who will be attending the course[^ForkMyCourse], there is a bit of suggested preparation, in order to come to the event with guns blazing. The event will consist of almost equal parts lectures and hands-on work, and you will be writing your own code which will be used to orchestrate services on a test infrastructure which will be provided. You need not bring anything in particular, but you will need a personal computer to work on. + +In order to prepare for the course and ensure that things go smoothly for you, there are a few simple actions which we ask you to take, or to confirm. + + 1. You will be writing and typing a lot, and most of it will be code. If you are not comfortable with ssh, your favorite shell (we'll be using bash), your favourite editor (I recommend [Atom](http://atom.io)), basic git and git workflows, I suggest that you take the time to brush up on these skills. A good place to start is the [Software Carpentry Lessons](http://software-carpentry.org/lessons/) , and for the more curious out there, see + 1. [The Altassian git collaboration tutorial](https://www.atlassian.com/git/tutorials/syncing) + 1. [The Github Flow help article](https://guides.github.com/introduction/flow/) + 1. Ensure that you have a working [Github](http://github.com) account. If not [signup](https://github.com/join). This will be used to create and fork the repositories of the code needed in the course and also give you a place to keep your work for after the course. + 1. Github is really useful to share public keys. If you don't already have an ssh keypair, generate one and add it to your github profile : [github.com/settings/ssh](https://github.com/settings/ssh). See [Github SSH Help](https://help.github.com/categories/ssh/) for more info. + 1. If you really want to get going, why don't you fork the DevOps Repo of the [Africa-Arabia Regional Operations Centre](https://github.com/AAROC/DevOps) ? This contains much of the actual code which we use to orchestrate services and we will be referring to it during the course. + 3. Ensure that you have an account on at least one federated identity provider. You can see a list at [eduid.wacren.net/](https://eduid.wacren.net/registry/p/page/idp-list) This will be needed to use the discussion forum where we discuss the course and provide support, as well as other federated services + 4. We will be focussing on two main technology stacks during the course : [Ansible](http://www.ansible.com) and [Docker](http://www.docker.com). Ensure that you have these websites bookmarked, especially their documentation sections below. If you're felling bold, go ahead and install them on your laptop ! We will be covering how to do this during the course, but if you do it before hand, you'll have more time to concentrate on the course and help your fellow participants. + * Ansible : [docs.ansible.com/](http://docs.ansible.com/) + * Docker : [docs.docker.com/engine/quickstart/](https://docs.docker.com/engine/quickstart/) + 7. DevOps requires testing and continuous integration. We will be covering this during the course, but there are several hosted services which can be used to run continuous integration on the code that we'll be writing. Sign up at [Travis](https://travis-ci.org/) with your github account. + +Don't worry if you don't manage to do all of this before the course, we will be covering it during the sessions. However, it is advisable to try it before the course so that you can either come prepared, or have specific questions to answer when we get started. + +# *Flame on !* + + +# References and Footnotes + +[^ForkMyCourse]: Or, for those who wish to fork the course and run it independently. diff --git a/_posts/2016-04-11-ORCID-impact.md b/_posts/2016-04-11-ORCID-impact.md new file mode 100644 index 0000000..70e9ce3 --- /dev/null +++ b/_posts/2016-04-11-ORCID-impact.md @@ -0,0 +1,77 @@ +--- +layout: post +title: 'ORCID - Y U NO sort by impact ? ' +description: 'That list of works is going to get long, and indeed not all research output is created equal' +category: blog +tags: [blog, Sci-GaIA, e-Science, ORCID, DataCite, persistent] +image: + feature: filter.jpg + attribution: "Courtesy of SplitShire http://www.splitshire.com/wp-content/uploads/2015/01/SplitShire-6806-1800x1200.jpg" +comments: false +mathjax: false +discourse: true +--- + +# TL;DR : It would be nice if my ORCID works list could be ordered according to e.g. impact factor + +Every year, we have an annual review of output by my institute[^Generic], which I'm sure is a common thing amongst research institutes, laboratories and probably universities. Now, I have my ORCID account connected with the [DataCite](http://www.datacite.org) "search and link", which automatically imports new works from DataCite-connected datacentres[^DataCiteCentres]. So, when my manager asked me for the year's scientific output instead of trawling through emails, files, calendar, _etc_, I simply went to [my ORCID profile](http://orcid.org/0000-0002-6607-7145 )[^yourORCID], and pulled out a list of works, which I then just handed over[^Actually]. Five seconds later, still patting myself on the back, my enthusiasm for this self-service mode of output evaluation was somewhat curbed. I had a feeling it was too good to be true... + +# Easy, Tiger. + +It turns out that at my institute, as at probably any serious research institute or university, not all scholarly output is created equal. Leaving aside the aspects of wider[^better] impact assesment in terms of _what_ kind of contributions count for assesment - ie, departing from the "traditional" list of journal article, conference proceeding, _etc_ and counting posters, blog posts, technical reviews, software, educational material, peer reviews, _etc_ - and concentrating only on the **quality** of the contribution, my manager was faced with a problem. Although ORCID did indeed show a comprehensive view of my research outputs, it did not say annything about which ones were eligible for inclusion in my _institutional_ assessment, because there was no way to map the object to the "publication count" as defined by my institute. + +> I have project notes, conference posters, software releases, reproducible workflows, educational courses, and of course the "good-old" peer reviewed journal articles - +> How is the institutional librarian or group leader to know which ones are applicable ? + +Hm. Fair enough... + +# Institutional membership to the rescue ? + +Now, it may be that if my institute has an [institutional ORCID membership](http://orcid.org/organizations/institutions), they would be able to [proactively obtain](http://members.orcid.org/profile-systems) my contributions for internal records, instead of relying on me to send them my (perhaps biased) report. This would allow them to both pull in works from sources which recognise my ORCID, and update my profile within the institute, as well as filter the works accorcding to their internal criteria, before harvesting them and submitting them to the institutional repository. Perhaps... + +However, the single most important factor in _what_ to select from my list of works was whether or not the work was published in an accredited journal or publication. Whilst there are a few nuances to this, it essentially comes down to whether or not the publication is peer reviewd, and has [an impact factor](http://wokinfo.com/essays/impact-factor/). + +# Sorting by impact factor + +So even though I had to go through my list of works and send through a filtered list, selecting works based on the internal criteria of my institute, the integration of ORCID with the publishers (including DataCite) really saved an incredible amount of time. I could be fairly certain that if my work was _not_ in my ORCID profile, it would not satisfy the institutional criteria, since it would not have been published in an accredited journal, so I didn't have to spend those hours trawling my email, calendar, filesystem, looking for articles which I may have published by forgotten about. Yay ORCID ! + +However, I still had a fairly long list to go through, which was sorted chronologically. Whilst going through this list I had to check which source the contribution came from (which was pretty easy) + +
+ +
Sample of works in my ORCID profile, retrieved 11/04/2016. The data source is clearly seen by the DOI prefix/suffix. The list is sortable by date, contribution type or title.
+
+ +However, to make things _even easier_ it would be awesome if that list could be sorted by **impact factor** instead of date. This would not only make my annual reporting much easier, but also allow those visiting my profile to see my **most impactful works first**. + +# Ideas on implementation + +## Repository Metadata ? + +This is probably not trivial to implement, but if I had to think of a solution, it would need the impact factors of the data sources. I'm not sure if the [OAI-PMH protocol](https://www.openarchives.org/pmh/) allows for data centres to include their impact factor in their repository metadata (or if this even makes sense), but that might be one way. Another way would be for an ORCID service to cross-reference the contribution with Web of Knowledge data on impact factors, and try to guess what impact factor to weight the article with. + +## Webometrics ? + +Another aspect of a repository is it's [repository webometrics](http://repositories.webometrics.info/) score, where available. This is what we decided to implement in the [CHAIN-REDS](http://www.chain-project.eu) [Semantic Search](http://www.chain-project.eu/linked-data) tool. The issue here might be cross-referencing the DataCite data center identifier (the prefix, essentially) with the webometrics identifier. Of course, it would be even better if webometrics used the same persistence and uniqueness infrastructure as the rest of the academic publishing world, but we can't have _everything_ now, can we ! + +## Altmetrics ? + +An alternative approach might be to forget about the publication and focus on the object; the works could be ranked by the [Altmetric score](https://www.altmetric.com/about-altmetrics/the-donut-and-score/), although this may imply some kind of relationship between [Altmetric](http://www.altmetric.com) and ORCID. The work should have a persistent, unique identifier and this should allow a unique Altmetric score, which seems to imply a well-formed algorithm for ranking works in the ORCID list... but here I confess my ignorance of whether or not this is actually feasible. + +# Long story short : rank by importance. + +So, basically : wouldn't it be nice to have an ORCID profile which at least tried to list my works ranked by "importance" ? We could have multiple definitions of what "important" means, but any of them would be better than ranking by something as insignificant as "title"[^nooffence]. This would really make the ORCID profile a more powerful tool in evaluation of researchers, both "at a glance", as well as during annual reviews as was my case. + + +# Disclaimer + +Bruce Becker writes in his personal capacity and this post in no way reflects the policy or position of the Council for Scientific and Industrial Research. This article serves as a personal account and does not reflect any relationship between the CSIR and ORCID, DataCite or any other entity mentioned. It was written in the context of the [THOR Ambassador programme](https://project-thor.eu/become-an-ambassador/), which he is a member of. + +# Footnotes + +[^yourORCID]: *My* ORCID is orcid:0000-0002-6607-7145 +[^DataCiteCentres]: These are datacentres which have a DataCite DOI prefix associated with their repositories. +[^Actually]: Actually, I just sent the link to my profile. Ok, ***actually***, I just told him that the link was in every mail that I've sent in the past few months, because I've put my ORCID profile in my email signature, so *actually* there was no reason for all this email to be flowing around... but *actually* things weren't that clear cut as the discussion shows. +[^better]: Some would say "better". +[^Generic]: I'm keeping this post itentionally generic, since I feel that these issues will be experienced by many researchers and institutes, and that they are not specific to my institute. For the record, "my institute" is the [Council for Scientific and Industrial Researcher] +[^nooffence]: No offence meant, ORCID developers, you guys are awesome. It's just that "title" is not a good way to rank works, for obvious reasons. diff --git a/_posts/2016-05-18-Performance-Studies.md b/_posts/2016-05-18-Performance-Studies.md new file mode 100644 index 0000000..ed5ca10 --- /dev/null +++ b/_posts/2016-05-18-Performance-Studies.md @@ -0,0 +1,148 @@ +--- +layout: post +title: 'Performance studies' +description: 'Initial description of performance studies on the grid' +category: blog +tags: [blog, VO, gLite, grid] +image: + feature: + attribution: "" +comments: false +mathjax: false +discourse: true +--- + +# TL;DR + +We started to run some real-world performance studies on the grid. This post details the design of the experiment, as well as infrastructure and services used. + + +- [TL;DR](#tldr) +- [Background](#background) +- [Design of the experiment](#design-of-the-experiment) +- [Platform and services](#platform-and-services) + - [Computing](#computing) + - [Data storage](#data-storage) + - [Coming Soon.](#coming-soon) +- [References and Footnotes](#references-and-footnotes) + + + +# Background + +A few weeks ago, we were contacted by a student at the [University of the North West](http://www.nwu.ac.za) who was undertaking a study of the relative performance of computing tasks on various architectures, using a series of common applications and data sets. The distributed computing architecture under consideration was indeed our very own AfricaGrid, specifically a sub-set of sites which support the [SAGrid Virtual Organisation](https://voms.sagrid.ac.za:8443/voms/sagrid/configuration/configuration.action). + +# Design of the experiment + +The experiment we had in mind was to determine the time required to process a set of standard data sets[^PublishedSoon], using two machine-learning applications : + + 1. The [Hidden Markhov Toolkit](http://htk.eng.cam.ac.uk/)[^HTK] + 2. the [SVM library](http://www.csie.ntu.edu.tw/~cjlin/libsvm)[^LibSVM] + +These applications were integrated into the [CODE-RADE](http://ci.sagrid.ac.za) platform in builds [148](http://ci.sagrid.ac.za/job/repo%20transaction/148/) and [146](http://ci.sagrid.ac.za/job/repo%20transaction/146/) respectively. Sites which supported the SAGrid VO were contacted by the VO manager, in order to see that they correctly mounted the CVMFS repository `fastrepo`[^SeeCVMFSPage]. Once this was done, the applications were available to all submitted jobs. + +The processing of the data consisted in several tasks including training models with training data sets and then using them to perform characterisation on other data sets using those models. The questions that we aimed to answer, amongst others were : + + 1. Can this processing be done efficiently in a distributed environment ? + 2. If the processing can be parallelised, what is the level of parallelism which gives the best efficiency ? + 3. What overhead is there due to the geographically-distrbuted nature of the platform ? + +Typically, these questions were answered quantitatively, by measuring the average amount of time required to perform various tasks in the workflow. Initially these were identified as : + + 1. Time taken to stage data from online storage endpoints to the compute facility + 2. Time taken to perform estimation of the SVM "C value"[^CValue] + +Since this was conducted in a real-world scenario, where other applications, users and services are vying for the same resources (compute time, network capacity, _etc_ ) as our work, we expect there to be fluctuations in these times. In particular the following aspects are expeccted to impact on the average and shape of the distribution of these timing values : + + 1. Whether the site has local online storage - if not, data would have to be staged large distances over SANREN to the compute endpoint. + 2. The performance tuning of the online storage and compute cluster frontend + 3. The make and model of CPU on the compute cluser worker nodes. + +# Platform and services + +The platform used consisted of three sites on the South African National Compute Grid, a subset of the Africa-Arabia Regional Operations Centre. These sites where : + + * **ZA-UJ** : [University of Johannesburg](http://physics.uj.ac.za/cluster) + * **ZA-WITS-CORE** : [University of the Witwatersrand](http://grid.core.wits.ac.za/). + * **ZA-CHPC** : [Centre for High-Performance Computing](http://www.chpc.ac.za) + +These were selected due to their current state of support for the SAGrid VO. They also are fully certified in the ROC, providing middleware and operational compliance[^EGIOLA]. The OLA stipilates that these sites should have a certain level of operation of a pre-defined set of services. In particular: + +> High-Throughput Computing Platform +> - Grid compute - allows scientists to run computational tasks on high quality IT resources, accessible via a standard interface and supporting authentication/authorisation based on a membership within a virtual organisation. +> - Grid storage - allows files to be stored in and retrieved from high quality IT resources, accessible via a standard interface and supporting authentication/authorisation based on a membership within a virtual organisation. + +These services are published by the sites, via the site BDII in the GLUE Schema[^GLUE12]. Using the default top-level information index for the ROC[^top-bdii], the expected resources computing resources are : + + + + + + + + + + + + + + +
Site Logical CPUs CPU VendorClock SpeedSMP Size
ZA-WITS-CORE 280 Intel 1900 13
ZA-UJ 2018 AMD 2600 8
ZA-CHPC 4032 Intel 2800 48
+ + +## Computing + +The computing services in use at the sites is the CREAM-CE[^CREAMPaper][^CREAMPaper2], which is part of the [Unified Middleware Distribution](http://repository.egi.eu/)[^UMD]. These provide endpoints for job requests to be submitted to. The job requests were written in the [JDL](https://edms.cern.ch/file/590869/1/WMS-JDL.pdf) language, based on the Condor ClassAds. Job descriptions were written, as well as scripts which would set up the environment and execute the applications in the desired way and were published in the "CODE-RADE LibSVM release"[^CODE-RADElibsvm]. Workflows were submitted directly to CREAM interfaces using the command line `glite-ce-job-submit` tool. Authentication and authorisation was done by personal x.509 certificate and VOMS-signed proxies of that certificate. + +## Data storage + +Data storage used during the study refers to protected online storage provided to the VO by the sites. Due to the high usage of storage by the big WLCG VOs (ATLAS and ALICE), capacity for smaller user communities is limited in South Africa. The services providing the online storage capability are UMD Disk Pool Managers (DPM)[^DPM] exposing various transfer interfaces, such as SRM and GridFTP. The capacity (total and available) of these endpoints as published by their sites is shown in table below: + + + + + + + +
Site Total Online Storage (GB) Available Online Storage (GB)
ZA-UJ 2931 1962
ZA-WITS-CORE 10491 524
+ +In order to ensure that the files were readily available locally at sites where online storage was available, the files were replicated to the respective storage endpoints. However this would have created a complication for the user, since data locality is lost. We therefore used the Logical File Catalogue (LFC) to replicate the files with a single namespace, and passed to the JDL as data input. For _e.g._ the `NCHLT_2K` data set, we thus have a single logical directory : +{%highlight bash %} +lfn:/grid/sagrid/nwu-hlt/NCHLT/ +{%endhighlight %} + +containing all of the data sets, which have been replicated across storage elements. + +{%highlight bash %} +DataRequirements = { + [ + InputData = {"lfn:/grid/sagrid/nwu-hlt/NCHLT/NCHLT_2K.tar.gz"}; + DataCatalogType = "DLI"; + DataCatalog = "http://lfc.magrid.ma:8085"; + ] + }; +{%endhighlight %} + +As can be seen here[^JDLSnippet], we are using the catalogue provided by the Moroccan National Grid Initiative (MAGrid), which is a member of the Africa-Arabia Regional Operations Centre. By registering the data sets in a single namespace, we can easily select the "closest" one to the computing element and improve the efficency of data transfer at job submission time. + +## Coming Soon. + +This has been the first post on our performance study. Coming in the next one, we will describe the tasks that were done and the parameter scans, as well as how we used the gLibrary-2.0 metadata service to keep records of the timing performance. + +# References and Footnotes + +[^PublishedSoon]: The data will soon be published in an open acces data repository. +[^HTK]: See ["The HTK Book"](http://htk.eng.cam.ac.uk/docs/docs.shtml) Young et al., 2009. Available online at [https://www.researchgate.net/publication/236023819_The_HTK_book_for_HTK_version_34](https://www.researchgate.net/publication/236023819_The_HTK_book_for_HTK_version_34) +[^LibSVM]: Chih-Chung Chang and Chih-Jen Lin, LIBSVM : a library for support vector machines. ACM Transactions on Intelligent Systems and Technology, 2:27:1--27:27, 2011. Software available at http://www.csie.ntu.edu.tw/~cjlin/libsvm +[^SeeCVMFSPage]: The `fastrepo` was used. See [www.africa-grid.org/cvmfs](http://www.africa-grid.org/cvmfs) for a description of the various repositories. +[^CValue]: See http://www.svms.org/parameters/ for a discussion of SVM parameters. +[^EGIOLA]: These are specified in the [Resource Centre Operational Level Agreement](https://documents.egi.eu/public/ShowDocument?docid=31), Malgorzata Krakowian and Christos Kannelopoulos, 2014, EGI. +[^CREAMPaper]: P. Andreetto et al., CREAM: A simple, Grid-accessible, Job Management System for local Computational Resources, Proc. XV International Conference on Computing in High Energy and Nuclear Physics (CHEP'06), Feb 13-17, 2006, Mumbay, India, Macmillan, p. 831-835, ISBN 10:0230-63017-0, ISBN 13:978-0230-63017-8. +[^CREAMPaper2]: C. Aiftimiei, P. Andreetto, S. Bertocco, S. Dalla Fina, A. Dorigo, E. Frizziero, A. Gianelle, M. Marzolla, M. Mazzucato, M. Sgaravatto, S. Traldi, L. Zangrando, Design and Implementation of the gLite CREAM Job Management Service, Future Generation Computer Systems, Volume 26, Issue 4, April 2010, pp. 654-667, [doi: 10.1016/j.future.2009.12.006](http://dx.doi.org/10.1016/j.future.2009.12.006). A preliminary version is available as INFN Technical Note INFN/TC_09/3, may 5, 2009 +[^UMD]: M. David, G. Borges, J. Gomes, J. Pina, I. Campos Plasencia, E. Fernández-del-Castillo, I. Díaz, C. Fernandez, E. Freire, Á. Simón, K. Koumantaros, M. Dreschner, T. Ferrari, and P. Solagna, “Validation of Grid Middleware for the European Grid Infrastructure,” Journal of Grid Computing, vol. 12, no. 3, pp. 543–558, 2014. [doi:10.1007/s10723-014-9301-z](http://dx.doi.org/10.1007/s10723-014-9301-z) +[^CODE-RADElibsvm]: Bruce Becker et al.. (2016). CODE-RADE: Libsvm Release. Zenodo. [doi: 10.5281/zenodo.51591](http://dx.doi.org/10.5281/zenodo.51591) +[^GLUE12]: Sergio Andreozzi, Stephen Burke, Laurence Field, Steve Fisher, Balasz Konya, Marco Mambelli, Jennifer M Schopf, Matt Viljoen, Antony Wilson, R Zappi (2005) "GLUE Schema Specification-Version 1.2". Available online at https://forge. gridforum. org/sf/go/doc14185 +[^top-bdii]: There are several top-bdii services for the ROC, the default being `top-bdii.africa-grid.org`. +[^GOC]: The site name as defined in the [Global Operations Database](http://goc.egi.eu) +[^DPM]: Akos Frohner _et al_. "Data management in EGEE", J.Phys.Conf.Ser. 219 (2010) 062012 ([doi: 10.1088/1742-6596/219/6/062012](http://dx.doi.org/10.1088/1742-6596/219/6/062012)) +[^JDLSnippet]: This snippet was taken from one of the JDLS in the [CODE-RADE grid examples for libsvm](https://github.com/AAROC/CODE-RADE/tree/master/grid/libsvm). diff --git a/_posts/2016-05-26-e-Infra-dev-guides.md b/_posts/2016-05-26-e-Infra-dev-guides.md new file mode 100644 index 0000000..0e5ab81 --- /dev/null +++ b/_posts/2016-05-26-e-Infra-dev-guides.md @@ -0,0 +1,131 @@ +--- +layout: post +title: 'e-Infrastructure and Science Gateway Development Guides' +description: 'Part of the Sci-GaIA deliverable series' +category: blog +tags: [blog, VO, gLite, grid] +image: + feature: + attribution: "" +comments: false +mathjax: false +discourse: true +--- + +We had a discussion yesterday about Deliverable 1.1 - **"e-Infrastructure & Science Gateway Development Guide for NRENs and Communities of Practice"**. I would like to have some further discussion on the scope and content and explain what we've got so far in the ROC. + + + +- [Scope](#scope) +- [Deployment guides](#deployment-guides) + - [Upstream providers](#upstream-providers) + - [Services covered](#services-covered) +- [Operations Guides](#operations-guides) +- [Where to find material](#where-to-find-material) + - [DevOps Documentation](#devops-documentation) + - [Services and components](#services-and-components) +- [Summary](#summary) + + + +# Scope + +The deliverable talks about development guides but we are really referring to _deployment_ guides, except in very few cases. It doesn't make sense to talk about middleware development guides, since the the middleware development guides are scoped purely to the few projects which are actually developing the middleware. However, it _does_ make sense to talk about community portal and science gateway development guides, I think, since these are always somewhat different from each other. + +# Deployment guides + +Which ***deployment*** guides are we talking about here specifically ? The starting assumption is that the intended audience is on the *ops* side of the field and that. People in ops are expected to provision the relevant hardware and use the relevant orchestration tool to deliver the service. In most cases, this means running an Ansible playbook against an inventory. The guide here should tell the operator : + + 1. What suggested resources to provision + 1. What their inventory should look like + 1. Which playbooks are relevant + 1. Which variables need to be configured + +The model is that _services_ map to _roles_ and these _roles_ are the responsibility of the _dev_ side. The developers of the ROC team are responsible for developing and testing their roles, while the site administrators are responsible for deploying the services accordingly. This nice, clean model can never work 100% in practice, due to the scale, scope and heterogeneity of our ROC, so it should be treated as _just a model_. The general principle however that services are encoded into something that is executable should be upheld. + +In the case of services deployed with Ansible, the information and required action referred to above should be written in the README relevant roles. The roles thus express the services, albeit in an abstract way. The playbooks which express the "proper" way of deploying services, and thus combined with the group variables of the site, as well as any specific customations that the site may want to apply, are the specific expression of how those services are instantiated. + +## Upstream providers + +Where we are consumers of middleware from upstream providers, such as in the case of FedCloud or grid sites, the documentation of the service as provided by the middleware provider should be used as the reference material, and we should avoid re-writing site administrator and user manuals. However, a series of pages may be maintained describing issues arising, workarounds, specific tweaks and aspects _not_ covered in the upstream documentation. The goal is to avoid writing as far as possible, since this has implications for future commitments. + + +## Services covered + +This section describes what services need to be covered. We consider services which make sense to talk about in the context of the Regional Operations Centre, which goes beyond compute and data services, but stops short of NOC-level services. In terms of the Virtual Research Environment stack, with user-facing applications on the top and network infrastructure on the bottom, we should cover the services which are _not_ in the domain of either the user community themselves or the underlying site _resource_ owners. These are : + + * Catania Science Gateway Framework + * web application container + * tracking database + * Federated Identity Services + * Federated Identity providers + * Local identity store + * Federated Service providers + * Open Access data repository + * Identity Management service (ie Perun) + * Grid Services + * Site services (According to [EGI RC OLA](https://documents.egi.eu/document/31)) + * information provider capability + * compute capability + * storage capability (optional) + * accounting capability + * user interface (optional) + * FedCloud services (According to [EGI FedCloud Manual](https://wiki.egi.eu/wiki/MAN10) ) + * Cloud management framework (OpenStack/Synnefo/OpenNebula) + * Information provider capability + * Accounting capability + * VM replication capability + * OCCI endpoint (optional) + * Nova endpoint (optional, for Native OpenStack) + * Core services + * Top-level information provider capability + * monitoring capability + * workload management capability (optional) + * metadata service (optional) + * VOMS (optional) + * Data movement service (optional) + +This may be expanded upon later. In particular it would be nice to have at least a default implementation of HPC cluster deployment, which could be integrated into the ROC via OCCI. + +# Operations Guides + +The responsibility of the developer to provide documentation and testing of the services ends with the deployment guides referred to above. However, this does not cover the day-to-day operation of the services - what standard procedures need to be taken into account regarding common activities. Since the ROC is a collaboration beyond merely a distribution of resources, these _procedures_ are extremely important. + +The operations _guides_ are very sensitive to the operating _environment_. The ROC only needs to define the lowest common denominator in terms of operations producers, on a service-by-service basis, in order to improve the effectiveness of the collaboration. Most of this common set of procedures has bee written by EGI, and can safely be adopted for use by sites providing sets of the services referred to above. However, sites which are part of large community infrastructure such as H3A, WLCG, Earth System Grid Federation, etc need to ensure that they _also_ respect the operating guides of those communities. + +Importantly, we do _not_ yet have guides on how to contribute either to the dev or ops side in most cases. There is a `CONTRIBUTING.md` file (as per the suggested good practice of the [Mozilla Science Working Open Workshop](http://mozillascience.github.io/working-open-workshop/contributing/)) for the [DevOps](https://github.com/AAROC/DevOps) repo, but it is as yet incomplete. Most of the other services have no such contribution guide. + +# Where to find material + +It makes sense that the deployment and operations guides be easily findable from the [AAROC website](https://www.africa-grid.org). To this end, we have created a page [for operators](http://www.africa-grid.org/operators) as well as one for [service developers](http://www.africa-grid.org/developers). The former has sections on : + + * Overview and intended audience + * Regional Operator on Duty + * Operational Security + * Site Operations + * Deployment guides + * Reference + +Most of these sections still need to be fleshed out entirely. + +## DevOps Documentation + +We have tried to persuade site operators to commit any relevant _code_ which is used to configure their sites and services to the common [DevOps](https://github.com/AAROC/DevOps) repo - either as a submodule, by sending pull requests from their forks, or by commiting directly where possible. This has the advantage of having most of the functional expression of our services in one place, so that there can be some peer review and oversight. However, since tools such as Ansible and Puppet encourage proper software development principles, including inducing developers to document their code, **we can use this repo to generate a complete set of documentation** for our services. + +Using Github Pages, we can also ensure that the documentation is in an easy-to-find place : + +> [africa-grid.org/DevOps](https://www.africa-grid.org/DevOps) + +This documentation has just been started, and uses the READMEs of the various modules and roles to generate the documentation pages. We still need to write the specific guideson how to define sites, which variables are necessary for which services and so on, but the structure is now in place to commit decent documentation via the repo itself. + +## Services and components + +Components such as Ansible roles are easy to document since they are abstract and need only refer to internal aspects. However, combining these components into properly-configured services at a site, which in turn respect various OLA and standard operating procedures, is a nontrivial task, since it requires some institutional knowledge of the collaboration and the distributed computing platform. We _do_ need to provide human-readable guides at a very high level, as well as the machine-readable guides, in order for newcomers to get bootstrapped as well as work as autonomously as possible. + +# Summary + +Given the scope of the audience - NRENs, communities of practice, and e-Infrastructure operators - it is a huge ask to develop deployment guidelines for an exhaustive set of e-Infrastructure services. It is also not reasonable to expect that there is a single entry point for _all_ documentation. However, by defining the suite of services as we have done here, we come up with a more formulaic approach to providing documentation for how things are _done_ and what to do when things go wrong. By providing a single page : + +> [africa-grid.org/operators](http://www.africa-grid.org/operators) + +we can provide a fairly comprehensive anchor for operators of most e-Infrastructure services to refer themselves and their collaborators to. diff --git a/_posts/2016-06-09-CODE-RADE-in-CVMFS-global-repositories.md b/_posts/2016-06-09-CODE-RADE-in-CVMFS-global-repositories.md new file mode 100644 index 0000000..6b32353 --- /dev/null +++ b/_posts/2016-06-09-CODE-RADE-in-CVMFS-global-repositories.md @@ -0,0 +1,39 @@ +--- +layout: post +title: 'CODE-RADE in CVMFS global repositories' +description: 'How do we construct the namespace of our repos' +category: blog +tags: [blog, CODE-RADE, CVMFS] +comments: false +mathjax: false +discourse: true +--- + +# TL;DR - We need to get our repo configuration for CODE-RADE into EGI + +# Deploying CODE-RADE is kinda manual :wrench: No Likey :frowning: + +At the moment, if you want to use CODE-RADE repositories at your site, you need to [follow some manual steps](http://www.africa-grid.org/CODE-RADE/site-admin-quickstart/) to get everything configured. This puts us at a bit of a disadvantage compared to the other organisations who are automatically configured when you install the CVMFS packages. This _can_ of course be addressed, simply by including our configuration into the way EGI distributes the repo information for various communities. We therefore have some choices to make, no matter how trivial they may seem. + +# CVMFS Global Repository configuration + +We have been in discussions with the CVMFS Task Force for quite a while now to decide how to do this. Recently we got this email : + +> We discussed about the option to have everything under `/cvmfs/.egi.eu//...` , +> but also there might be a solution to setup something like `'africa-arabia.org'` name space +> (i.e. `/cvmfs/.africa-arabia.org/...` and `/cvmfs/.africa-arabia.org/...` +> etc repositories). + +So, what to do ? + +# Current and future situation + +At the moment, we have one, perhaps two Stratum-0's in South Africa. The CODE-RADE Stratum-0 has in principle 3 repositories (`fastrepo`,`devrepo`, and `apprepo` - describing the quality assurance of the hosted apps), but this is still discussing only application delivery. CODE-RADE is in some sense community infrastructure, and supported by the ROC. + +It's conceivable that more Stratum-0's would come online from other providers in the region, which may fall into the ROC - the region is certainly large enough for there to be scope for this. So, perhaps using the AAROC namespace might be the way to go. It's not clear to me yet if there is any pro or con to either choice[^discuss], but it seems to me that **we should choose the "namespace" option**. The most important thing is to ensure that it's easy to add a new repo under the namespace with minimal manual reconfiguration on the part of the Stratum-1's and sites. + +---- + +# Footnotes and references + +[^discuss]: Be sure to discuss this on the related topic in [the forum](http://discourse.sci-gaia.eu) diff --git a/_posts/2016-07-05-RASR-project.md b/_posts/2016-07-05-RASR-project.md new file mode 100644 index 0000000..2f79c49 --- /dev/null +++ b/_posts/2016-07-05-RASR-project.md @@ -0,0 +1,134 @@ +--- +layout: post +title: "A plan for the Summer Hackfest" +description: "Some initial thoughts on a speech recognition science gateways" +headline: "A quick sketch of an environment for reproducible ASR processing" +category: blog +tags: [blog, Sci-GaIA, hackfest, projects, rasr] +comments: false +mathjax: false +image: + feature: Jr0F2ay.jpg +discourse: true +codrops: false +--- + +# TL;DR : A quick sketch of an environment for reproducible ASR processing + +We are about to get started on work to develop a virtual research environment for human language researchers, in the context of the [Sci-GaIA hackfest](http://www.sci-gaia.eu/summer-hackfest). The main focus is on reproducibility and re-analysis of published results. We have thus chosen the most awesome name for the project : + +> RASR - Reproducing Automatic Speech Recognition + +# Background + +This work comes out of a collaboration with [David Risinamhodzi](https://github.com/DavidR2016) at the [University of the North West](https://www.nwu.ac.za). That project was in essence a performance study, to investigate the real-world performance of running human language workflows on the distributed infrastructure in South Africa. Whilst quite limited in scope, the results showed great promise and we took the opportunity of the Hackfest to work on a web interface so that other speech researchers could use it and provide feedback. There has been close discussion with the [National Centre for Human Language Technologies (NCHLT)](http://rma.nwu.ac.za/index.php) regarding usage, workflows and proper procedure. The main applications that are being used in the project are the [HTK toolkit](http://htk.eng.cam.ac.uk/)[^htk] and a [library for Support-Vector Machine](https://www.csie.ntu.edu.tw/~cjlin/libsvm/)[^libsvm] - both of which are in [CODE-RADE](http://www.africa-grid.org/CODE-RADE) + +# Design considerations. + +The design of a web application is not something we do every day here in the ROC, but due to recent developments such as the [Indigo DataCloud project](https://www.indigo-datacloud.eu/), and in particular the development of the REST APIs of the [FutureGateway](https://github.com/FutureGateway/), we thought it was the perfect time to experiment with developing an interface to cross-platform distributed computing services. Indeed there is a major shift in general to writing "small" interfaces which use the REST APIs of external services in order to accomplish complicated workflows. + +## Web development framework + +Starting from scratch gives us the perfect opportunity to critically evaluate prior choices and explore new avenues. Whereas in the past the GridEngine component (which provides the interaction between the web-services and the computing platforsm) was integrated into the Liferay portal framework, this is no longer the case. The benefit was that we had freedom of choice in the selection of the web application framework, at the expense of existing scaffolding. With this freedom, the first choice we needed to make was which web development framework to use. This is in a sense an arbitrary choice, since the only functionality we really needed was a good REST API library. However, other factors such as maturity and scale of the community, richness of the development environment, supporting documentation, and ease of integration with external authentication providers came into play. The choice was initially whittled down to a toss-up between the + + * :gem: ruby-based **[Ruby on Rails](http://rubyonrails.org/)** :gem: + * :snake: python-based **[Django](https://www.djangoproject.com/)** + +toolkits[^JavaScriptduJour]. Both[^OkMTV] are based on the [Model-View-Controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) architecture and have good front-end and back-end libraries. + +An alternative would have been to use something very lightweight such as [Flask](http://flask.pocoo.org/), [sinatra](http://www.sinatrarb.com/intro.html), or similar[^MicroComparison]. However, the main criterion was the abililty to easily generate the web pages for the public-facing parts of the application. Since we had good experience with [Jekyll](http://jekyllrb.com/), which is Ruby-based, we decided to use Ruby as the language of choice. The choice to use Rails instead of Sinatra was based on the need to have a mature authentication framework. This is available in the form of [OmniAuth](https://github.com/intridea/omniauth/wiki) which would give us a great deal of flexibility over how to authenticate users. + +**So, our front-end stack would consist of :** + + * Ruby on Rails with : + * Devise with OmniAuth for authentication + * [HTTParty](https://github.com/jnunemaker/httparty) for REST calls + +This is only the front-end though. The application would use REST APIs from several other services in order to work. Let's take a deeper look into the overall architecture. + +## Architecture + +The architecture refers both to which _components_ we are using, as well as _how they are integrated_. + +## Components + +The components necessary to build the service consist of generic : + +* Web components +* Identity components +* Data components +* Compute components + +These components can take one or more forms, depending on the design and intent of the service, as well as which kind of environment it is going to be used in. + +
+ +
+Overview of RASR architecture components +
+
+ +We will go into deeper detail of each of these components in later posts. + +## Integration + +With the basic architecture of the service components sketched out, the integration can focus on the flow of information and data through the various services. This is in essence the core of the RASR project, since most of the components are already-existing external services, and we are developing a mashup of existing services. The integration of the services depends in some sense on the desired workflows of the researchers which will be using the service. + +## Typical ASR workflows + +The first issue to flesh out in designing the web +From discussion with [David](https://github.com/DavidR2016), typica workflows would look something like this : + + 1. Researcher identifies themselves. We are inclined to enable [ORCID auth](https://orcid.org/blog/2014/04/29/beta-participants-wanted-public-authenticated-ids?lang=ru), which would uniquely identify the researcher, but other methods are possible + 2. Researcher selects a language that they would like to study. They select a **corpus**. Language corpora are previously-published on open-access repositories. + 2. Researcher can + 3. browse previously-run experiments made on that copora, and re-run with a modified recipe **or** + 4. configure a new experiment and provide a recipe + 5. Each submission creates a new research object in a catalogue which consists of a combination of : + * Corpus + * Recipe + * Provenance (author and originating dataset) + 6. Analyses can be _published_ via the application to an open access repository if they pass certain quality criteria. Note that it is important to publish both _positive_ and _negative_ results, _i.e._ experiments which give a good as well as bad result when running speech recognition. + +The experiment itself consists of applying a _recipe_ of various tasks to input data : + + * Feature extraction + * Applying a training model on specified ranges of and sets of training data + * Evaluating the model + +## Reproducibility and Re-Use + +The end goal is to be able to ascertain whether a particular model and recipe is capable of giving reproducible results across corpora, etc. + + +# Goal Posts + +Here is a first stab at what we aim to achieve in the hackfest... call these our movable goalposts ! It's not clear how much we'll be able to get done in 2 weeks, but it's important to have a realistic roadmap that maps to functionality that is actually desirable by the end-user community. The main roadmap is a set of issues in a Github repo : + +[https://github.com/SouthAfricaDigitalScience/Project-RASR/milestones](https://github.com/SouthAfricaDigitalScience/Project-RASR/milestones). The main goal of the hackfest is thus 3 : + + 1. Basic website up + 2. ASR template ported into CODE-RADE + 3. Architecture Finished + +These milestones have been achieved so far and we are continuing to work on [the further issues](https://github.com/SouthAfricaDigitalScience/Project-RASR/issues). The main design issues and broad questions have been tagged with the [Epic](https://github.com/SouthAfricaDigitalScience/Project-RASR/issues?q=is%3Aopen+is%3Aissue+label%3AEpic) tag on Github and we are mowing through these as implementation-specific issues arise. There is more to come in a further post where we go into deeper detail of the specific components and integration issues. But for now, we have an architecture design, a badass project name ... and an idea for a logo : + +
+ +
+ +# Acknowledgements + +We had very fruitful discussions with all of the facilitators of the hackfest, but owe particular thanks to Marco Fargetta, Riccardo Bruno, Antonio Calanducci and Giuseppe Larocca for their valuable input. + +This work was supported by the [Sci-GaIA project](http://www.sci-gaia.eu) under Grant 654237 of the European Commission's Horizon2020 programme. + +# Footnotes and references + +[^htk]: Young, Steve, et al. ***"The HTK book."*** **Cambridge university engineering department** 3 (2002): 175. Available online at [http://htk.eng.cam.ac.uk/docs/docs.shtml](http://htk.eng.cam.ac.uk/docs/docs.shtml) +[^libsvm]: Chih-Chung Chang and Chih-Jen Lin, ***LIBSVM : a library for support vector machines***. **ACM Transactions on Intelligent Systems and Technology, 2:27:1--27:27, 2011**. Software available at [http://www.csie.ntu.edu.tw/~cjlin/libsvm](http://www.csie.ntu.edu.tw/~cjlin/libsvm) +[^OkMTV]: Ok, apparently [Django prefers to call it MTV](https://docs.djangoproject.com/en/1.9/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names), but you get the drift. +[^JavaScriptduJour]: Some JavaScript _du jour_ library such as EmberJS or AngularJS could have been used as well, but 1) Ugh. 2) Bleah, can't read that stuff +[^MicroComparison]: See [this article](https://realpython.com/blog/python/python-ruby-and-golang-a-web-Service-application-comparison/) for a recent comparison of Ruby, Python and Go-based microframeworks. + +[^discuss]: Be sure to discuss this on the related topic in [the forum](http://discourse.sci-gaia.eu) diff --git a/_posts/2016-07-19-CODE-RADE-FMD.md b/_posts/2016-07-19-CODE-RADE-FMD.md new file mode 100644 index 0000000..48c6833 --- /dev/null +++ b/_posts/2016-07-19-CODE-RADE-FMD.md @@ -0,0 +1,87 @@ +--- +layout: post +title: "CODE-RADE : Fermionic Molecular Dynamics" +description: "Care and Feeding of the FMD application" +headline: "So you want to Fermi some molecules, eh ?" +category: blog +tags: [blog, CODE-RADE, projects, FMD] +comments: false +mathjax: false +image: + feature: fluid.jpg +discourse: true +codrops: false +--- + +# TL;DR : Getting started with Fermionic Molecular Dynamics + +We've recently ported an application from the physical sciences domain used to make nuclear calculations using Fermionic Molecular Dynamics models[^FMD]. The application was requested[^InitialTopic] by [Katharine Henninger](http://discourse.sci-gaia.eu/users/katharinehenninger_f/) from iThemba L.A.B.S. + +# Fermionic Molecuar Dynamics in CODE-RADE + +[FMD-deploy](http://ci.sagrid.a.za/job/Fermionic-Molecular-Dynamics-deploy) was added to CODE-RADE on [July 4th](http://ci.sagrid.ac.za/job/Fermionic-Molecular-Dynamics-deploy/1/). After some discussion[^DiscourseTopic] +The application has a pretty simple dependency tree, as seen by the [Jenkins config](http://ci.sagrid.ac.za/job/Fermionic-Molecular-Dynamics-deploy/api/json?pretty=true) : + + + +The dependencies were all passing, so it was just a matter of a few modifications to the source code, [the application was included in the CODE-RADE `fastrepo`](http://discourse.sci-gaia.eu/t/fmd-integration/2158/4?u=brucellino). + +# Getting started + +:tada: Great ! :tada: so the application is in the repo and available at the sites - now what ? I've started work on a few examples to explain how to run the application on the grid. Thes are in the [CODE-RADE FMD examples directory](https://github.com/AAROC/CODE-RADE/tree/master/grid/fmd). I tested these and they give the expected results from a run at ZA-WITS-CORE: + +{% highlight bash %} + +you are using fastrepo.sagrid.ac.za version +Build 199a +Checking whether you have modules installed +you are using CODE-RADE version Build 199a +Great, seems that modules are here, at /usr/share/Modules +Append CVMFS_DIR to the MODULEPATH environment + +------------ /cvmfs/fastrepo.sagrid.ac.za/modules/physical-sciences ------------ +FMD/0.1 +... reading Interaction from file AV18-UsrgD2000f-v11ls-2.0.int +... reading Parameters from file He4.fmd + +initial: E = -25.246 MeV + +step: 0 E = -25.246 MeV +step: 1 E = -12.864 MeV +step: 2 E = -25.246 MeV +... Ozzz: -0.00000 +... writing Parameters to file He4.fmd +... 0.00 minutes computing time used + +{% endhighlight %} + + +Coming soon we'll add some more complicated submission examples and some further discussion on how to use gLibrary to manage the output. + +What we'd like to do now is take FMD to the next level and make some MPI runs with more demanding scenarios. + +# References and Footnotes + +[^InitialTopic]: See [the initial topic](http://discourse.sci-gaia.eu/t/connecting-to-the-sa-grid-facilities-as-a-researcher/2147) +[^DiscourseTopic]: See [the discussion on the initial functional test cases](http://discourse.sci-gaia.eu/t/fermionic-molecular-dynamics/2149) +[^FMD]: See **"Molecular Dynamics for Fermions"**, H. Feldmeier and J. Schnack _Rev.Mod.Phys.72:655-688,2000_ [doi: 10.1103/RevModPhys.72.655](http://dx.doi.org/10.1103/RevModPhys.72.655) diff --git a/_posts/2016-07-26-New-GCC.md b/_posts/2016-07-26-New-GCC.md new file mode 100644 index 0000000..35bb75e --- /dev/null +++ b/_posts/2016-07-26-New-GCC.md @@ -0,0 +1,36 @@ +--- +layout: post +title: "New GCC anyone ? " +description: "Quick update on the new GCC builds" +headline: "All your compiler are belong to us" +category: blog +tags: [blog, CODE-RADE, compilers, gcc] +comments: false +mathjax: false +image: + feature: +discourse: true +codrops: false +--- + +# You can never have too many compilers + +Well, you can, I guess, but the whole point of CODE-RADE is to make any possible combination of applications available to researchers anywhere. So, during the [Summer Hackfest](http://www.sci-gaia.eu/summer-hackfest/) it came to our attention that a new version of GCC had been released - [GCC-6](https://gcc.gnu.org/gcc-6/). It was time to add a few more ticks to the [GCC-deploy matrix jobs](http://ci.sagrid.ac.za/job/gcc-deploy) + + +# You can totally have too many compilers + +Well, enthusiasm is great and all, but it turns out that disk space is limited at tiny build cluster, which made the last few jobs of GCC fail. This is only going to be exacerbated when we start extending the list of targets that we support - currently only one kind of CPU and two operating systems. It's going to be time to distribute the load across clouds soon... + +# A shift in CODE-RADE architecture ? + +The original Jenkins setup at UFS was conceived to be as simple as possible - two slaves connected to a master, which built applications into an integration environment locally, then published the build results to a CVMFS repository on site. Basically what happens during integration gets built into `/apprepo`, while what happens during deploy gets built into `/cvmfs/fastrepo.sagrid.ac.za`. Both of these are local directories on the slave's hard disk. + +This locality is clearly not scalable, which was indeed forseen by Fanie during initial discussions. He suggested building relocatable tarballs of the artifacts and keeping them in a central repository for use during integration, shifting them down to arbitrary build slaves as needed. I argued against this for simplicity reasons, suggesting instead that we mount the shared directories over NFS. This would have worked as long as + + 1. The build slaves had infinite local disk storage + 2. The build slaves were on the same LAN as the other components (CI server and CVMFS repo) + +Both of those conditions are now close to being hard to fulfill. One potential way around this, whilst not sacrificing too much efficiency, is to keep atomic tarballs of integration builds, similar to how [Homebrew](https://github.com/Homebrew/homebrew-science) keeps bottles, or perhaps how Python keeps eggs. These could be pulled down to a build slave at execution time as dependencies and unpacked just before compilation of the requested application. One might figure what the heck, why not just fork Homebrew or EasyBuild entirely and use that to build everything... and that's something we need to discuss at some point. + +For now, let's just see how we can distribute the builds and highlight where there are serious structural weaknesses in the architecture. diff --git a/_posts/2016-08-01-Hackfest-feedback.md b/_posts/2016-08-01-Hackfest-feedback.md new file mode 100644 index 0000000..4fb1b29 --- /dev/null +++ b/_posts/2016-08-01-Hackfest-feedback.md @@ -0,0 +1,32 @@ +--- +layout: post +title: "The fest is over ! Long Live the Hack !" +description: "Tell us your experience of the Hackfest" +headline: "All your compiler are belong to us" +category: blog +tags: [blog, sci-gaia] +comments: false +mathjax: false +image: + feature: e-research-summer-hackfest-2016-group-photo-1st-edition.jpg +discourse: true +codrops: false +--- + +# TL;DR + +Now that we're all back home and some of us are looking forward to a well-deserved break, we want to reach out and ask you to tell your story from the hackfest. We want to gather some highlights and feedback from the Summer Hackfest held in Catania. + +> This is a call to all participants to give us their feedback and comment on how they thought things went. + +# Hackers + Experts = Something Awesome + +As you all know, we had two kinds of participants : technology providers and hackers. The goal of the event was to mash these two groups of beautiful people together in the hopes that something awesome would come out of it. This "something awesome" was left intentionally open-ended; in terms of the projects supporting the event ([Indigo](https://www.indigo-datacloud.eu/), [COST-ENEL](http://www.elexicography.eu/) and [Sci-GaIA](http://www.sci-gaia.eu)), we were of course looking forward to finished products - but getting something from scratch to even prototype after having been exposed to the tools of the hackfest, in just a few days, is of course unrealistic. We will be following up with you regarding the products and tools which you've developed, looking for those of you could be regarded as "champions of the cause", if you will. For now, we want to know what lights went on for you. If you came as a technology provider, what did you get out of discussion with the participants ? Have you found ways in which your tool could be improved, based on discussion during the event ? + +# The story is in the telling + +They say that "the story is the telling" - the main value that we get out of participating in these events is hidden in the experience, rather than just represented by the end result. We want to hear your stories. We don't want to focus only the the positive end-results. We want to know what was hard for you. We want to know what you wish you would have known before you arrived, and what you would have done differently if we had to run the event again. + +The hackfest is about stimulating community as much as it is about developing e-Science tools. We want to know what connections you made with others during the event, and if perhaps making those connections was hard, hindered or secondary, please try to tell us why. This can often be hard to express, so perhaps you could just write an anecdote of something that happened which could illustrate the issue for us. Of course, we want to hear those positive stories too - that time you discovered a better way to do something, the challenges you overcame just getting to the event, the hopes and aspirations that you have for your future work and collaboration, thanks to this event. + +[Come and tell your story](http://discourse.sci-gaia.eu/t/the-fest-is-over-long-live-the-hack/2202) - just reply to the topic with whatever you want to say. diff --git a/_posts/2016-08-05-SAGrid-AUP.md b/_posts/2016-08-05-SAGrid-AUP.md new file mode 100644 index 0000000..aa9cb55 --- /dev/null +++ b/_posts/2016-08-05-SAGrid-AUP.md @@ -0,0 +1,110 @@ +--- +layout: post +title: "Updated SAGrid VO AUP" +description: "Asking for your support of our support" +headline: "Sites supporting the SAGrid Virtual Organisation are asking members to do them a solid." +category: blog +tags: [blog, sci-gaia, thor, datacite, data, citation] +comments: false +mathjax: false +image: + feature: aup-post-header.jpg +discourse: true +codrops: false +--- + +# TL;DR : If you use it, support it. + +Provisioning e-Infrastructure is a thankless job, take it from us. Nobody wants to hear about how you've configured your services _"just right"_, how you're collaborating behind the scenes, how you're constantly putting out fires big and small so that research can be done. Usually, folks just skip ahead to the research bit and the researchers get the kudos. + +This is as it should be. Everybody has their part to play, and we know that the reason that we build and maintain distributed computing services is not for their own sake, but rather to enable scientific progress and discovery. You may be expecting a "but", right about now - and you'd be totally right. + +# You are all awesome, but... + +Here's the thing : + +> We can't do this without a positive feedback loop. + +A positive feedback loop is a process which enables long-lived features in complex systems[^feedback], by enhancing small perturbations and bringing a form of order to an otherwise chaotic system. This order is exactly what the Africa-Arabia Regional Operations Centre aims to bring to the vast pool of computing resources in our region, and by doing so, better support and stimulate research outputs. A positive feedback loop in this case may just be as simple as pointing back to the original perturbation[^feature], by citing that work in your subsequent research outputs. + +# What, When, How ? + +Having dealt with the "why", you may be saying to yourself : + +> Great, I'll buy that - but how _exactly_ are we to go about this ? + +What do we cite ? Where do we cite it and when is it appropriate to cite, rather than acknowledge the work of the VO ? Most importantly, _how_ should one cite this properly ? + +## What + +Let's start with the easy bit - what to cite. The new [Acceptable Use Policy](https://voms.sagrid.ac.za:8443/voms/sagrid/aup/load.action) states : + +> All research output (articles, data sets, analytic results, etc) which result directly from the use of the resources which support this VO shall contain \\ + 1.1 Citation of the paper describing the infrastructure: \\ + "The South African National Compute Grid" \\ + B. Becker et al. \\ + IST-Africa 2009 Conference Proceedings, Paul Cunningham and Miriam Cunningham (Eds), IIMC International Information Management Corporation, 2009, ISBN: 978-1-905824-11-3\\ + OR \\ + 1.2 Acknowledgement of the use of the resources in the relevant section, using the following phrase : \\ + "The authors acknowledge the support of the Africa-Arabia Regional Operations Centre and EGI.eu. This work was produced in part thanks to the resources of the sites supporting the sagrid VO. + +So, you know, you've got options. The first of these options is the "first post" of the old SAGrid project, where the original motivation, implementation and so on was described. + +## When and How + +So, now you know _what_ to cite, the question becomes - _when_ do you add acknowledgement support ? We foresee this sort of acknowledgement statement or citation of prior art in two different scenarios: + + * if you are writing a paper which contains results obtained by the usage of the sites supporting the virtual organisation, **or** + * if you have had direct support from the staff of participating sites, in the preparation of your paper, + +you should use the acknowledgement phrase, in the section of your paper's template (usually towards the end). This usually applies to domain-specific research - climate, chemistry, machine-learning, bioinformatics, _etc_. + +If, however, you are working on a **platform** or **service** which uses AfricaGrid services via their APIs, or specific endpoints, and supports the users of the Virtual Organisation[^AAROCCite], you should cite the "first post" paper we mention above. This is especially important when you can consider your work a kind of "derivative" of the infrastructure and which depends on the open nature of it. Our access and intellectual property policies depend on this kind of reciprocation of support, in order to engender the positive feedback loop which keeps the infrastructure in place, and justifies further investment. + +# Hold on a second : data. + +Before we end off here, let's talk for a second about data. Here, we are referring to data which has been generated on the sites supporting the VO, and published in an open access data repository. Data like this should in principle e issued a [DataCite](http://datacite.org) [DOI](https://www.datacite.org/dois.html) - that is a persistent identifier which allows people to both retrieve and identify that data for the forseeable future. When such data is published, it should follow the [DataCite metadata schema](https://schema.labs.datacite.org/meta/kernel-4.0/)[^DataCiteSchema4], which makes provision for certain kinds of acknowledgement of support, including ``. The [`ContributorType`](https://schema.labs.datacite.org/meta/kernel-4.0/include/datacite-contributorType-v4.xsd) can include "other" : + +{% highlight xml %} + + + + The type of contributor of the resource. + + + + + + + + + + + + + + + + + + + + + + + + + + +{% endhighlight %} + +This space can be used to acknowledge the support of the VO, and you can simply put the reference referred to above in there. Now, this may not be the perfect way to acknowledge the contribution that the infrastructure has made towards your work, and right now there may not even _be_ a perfect way to do this. We do, however _need_ it - so please help by [continuing the discussion](http://discourse.sci-gaia.eu/c/commons) on the African e-Infrastructures discussion forum, or over at the [THOR project knowledge base](https://project-thor.readme.io/). + +Rock on, beautiful scientists... + +# Footnotes and References + +[^feedback]: We use the analogy of the gridcloud as a [complex system](https://en.wikipedia.org/wiki/System_dynamics) often. The first known reference and exploration of this idea was a [talk](discoverability-of-african-scholarship/) given to a workshop in Nairobi on the discoverability of African Scholarship. +[^feature]: Call it a _feature_, an _intervention_, whatever - it's something that externally drives the system past equilibrium. In this case, equilibrium is a chaotic mess. Thermodynamic equilibrium is a terrible way to get work done. +[^AAROCCite]: We will have a similar page on the ROC's website to explain how to cite or acknowledge support of the ROC as a whole when dealing with infrastructure developments, which are not specific to individual communities. +[^DataCiteSchema4]: Here, we are referring to version 4 of the [**"DataCite Metadata Schema for the Publication and Citation of Research Data. Version 4.0. DataCite e.V."**](https://schema.labs.datacite.org/meta/kernel-4.0/metadata.xsd) diff --git a/_posts/2016-08-30-Sci-GaIA-3rd-Workshop.md b/_posts/2016-08-30-Sci-GaIA-3rd-Workshop.md new file mode 100644 index 0000000..1809c30 --- /dev/null +++ b/_posts/2016-08-30-Sci-GaIA-3rd-Workshop.md @@ -0,0 +1,60 @@ +--- +layout: post +title: The Third Sci-GaIA Workshop is coming to Dar es Salaam +description: and boy, are we excited ! +headline: It is going to be a cracker. +category: blog +tags: + - blog + - sci-gaia + - events + - datacite + - data + - citation + - open infrastructures + - discourse +comments: false +mathjax: false +image: + feature: banner-3rd-workshop.jpg +discourse: true +codrops: false +--- + +# Sci-GaIA comes to Dar es Salaam + +The [third Sci-GaIA workshop](http://www.sci-gaia.eu/3rd-sci-gaia-workshop-dar-es-salaam-tanzania-september-5-2016-register-now/) will be held soon in Dar es Salaam. We've got over 100 registrants so far, and [a great programme](https://agenda.ct.infn.it/event/1233/) lined up, which means we're **very** excited for this event. + + +## More Openness + +In our previous events in [Maputo]() and [Dakar](), we have had participants talk about the need for **Openness**, and how this improves research and society. Open Infrastructures, in particular [Open Data](http://www.sci-gaia.eu/osp-od/) and [Open Science](http://www.sci-gaia.eu/osp-oscience/) infrastructures underpin much of the advance in research fields, even though they are somewhat invisible to the general public or even research communities. Sci-GaIA is one of several projects[^OtherProjects] which is working to improve access to these infrastructures, for researchers such as yourselves and your peers, and we're really looking forward to showcasing the work that some of our "champions" have done during our recent hackfest. These should give some idea of how open infrastructures are enabling researchers and communities. In fact, we feel so strongly about Openness that we took a stand on the issue and published the [Dakar Declaration on Open Science](http://www.sci-gaia.eu/dakar-declaration/). + + +## What do we mean by Open Infrastructures ? + +When we say "Open infrastructures", we are essentially the talking about combinations of tools and services which enable research. During the workshop, you'll hear more about them (and we're hoping this will be a two-way discussion), which include: + +- [computational infrastructures like grids, clouds and HPC centres](http://www.sci-gaia.eu/osp-einfra/) +- data infrastructures like [Open Access data and document repositories](http://www.sci-gaia.eu/osp-oar/), [metadata harvesters](https://www.openaire.eu/) and semantic enrichment +- [identity federations](http://www.sci-gaia.eu/osp-fa/) such as edugain and the various [national identity federations](http://www.sci-gaia.eu/federated-services/) for researchers in Africa +- persistence and uniqueness infrastructures, like [ORCID](http://orcid.org) for researchers and [DataCite](http://www.datacite.org) for digital objects +- [e-Learning platforms providing online courses](http://www.sci-gaia.eu/osp-oc/) +- web-based access portals, which we refer to as [science gateways](http://www.sci-gaia.eu/osp-sg/) + +Some of these tools and services are in what we refer to as the "Open Commons" - things which we all need, but which we can't provide by ourselves - whilst others may be built and shared by specific organisations or institutes. All of this comes together in what we term an "Open Science Platform" - you can see what we mean by this at [www.sci-gaia.eu/osp](http://www.sci-gaia.eu/osp) + +# The most important infrastructure + +However, the most important aspect is **community**, is people like you and I. Without people working together, collaborating and sharing, the fancy tools we have at our disposal will always be insufficient. It is the asking of questions, the discussion in the open, the mutual support, _the understanding that one is not alone in the world_, that makes it possible for us to get anything done in modern research. Community takes many forms, and lives in many places, and we would like to hear about where your community lives online. For our part, we are providing the [African e-Infrastructures Discussion Forum](http://discourse.sci-gaia.eu). + +I want to take this opportunity before the workshop to invite you to come to the discussion forum and tell us about yourself. There's no signup procedure, just log in with an identity provider near you ([or use the Catch-All identity provider, where anyone can register](http://idpopen.garr.it/register)). This is a forum where a community of over 160 experts from across Africa and Europe learn, build, and discuss issues across the board from research and community projects, to integration of web applications with e-Infrastructures, and more. This is a place for you to feel at home - to speak your own language, and to engage with your own peers and collaborators - but also to easily exchange ideas and information with the movers and shakers in the e-Infrastructure world. We've worked hard to make it welcoming and accessible, and are very keen to hear your suggestions for improvement. + +See to find out more. + + +------ + +# References and Footnotes + +[^OtherProjects]: See for example the great work being done by the [THOR]() project, our sister project [TANDEM](), the [MAGIC]() project and of course the [Indigo DataCloud]() projects. We've chosen these examples since we work closely with them, but they are by no means even the tip of the iceberg when it comes to open science projects ! Please feel free to [let us know](http://discourse.sci-gaia.eu) diff --git a/_posts/2016-08-31-Paths-to-success.md b/_posts/2016-08-31-Paths-to-success.md new file mode 100644 index 0000000..d7c183a --- /dev/null +++ b/_posts/2016-08-31-Paths-to-success.md @@ -0,0 +1,97 @@ +--- +layout: post +title: 'Paths to Success for Open Science in Africa' +description: An ICRI fringe event +headline: Will you have a hand in paving the way ? +category: blog +tags: [ICRI, Sci-GaIA, e-Infrastructure, Open Science, Open Infrastructures, Open Standards, cloud, educaton] +image: + feature: icri-fringe-event.jpg + attribution: +comments: false +mathjax: false +discourse: true +--- + +# ICRI Fringe Event 2016 + +----- + +**Title: Paths to Success for Open Science in Africa** + +**Sponsors** : + + * [Sci-GaIA project](http://www.sci-gaia.eu) (Horizon 2020) + * [UCT e-Research Centre](http://eresearch.uct.ac.za) + +**Themes** : + + * Open Infrastructures + * Open Science + +---- + +# ICRI 2016 + +The [3rd International Conference on Research Infrastructures (ICRI)](http://icri2016.co.za) will be held from **3 - 6 October 2016** in Cape Town, South Africa. We are proposing a "fringe event" to the conference, organised by the [Sci-GaIA](http://www.sci-gaia.eu) project and [UCT e-Research Centre](http://www.eresearch.uct.ac.za). Participation is entirely open, and will be discussed with the communities involved. See below for more information, and **comment on the [topic](http://discourse.sci-gaia.eu/t/paths-to-success-for-open-science-in-africa-africa-arabia-regional-operations-centre/2303) if you're interested.** + +## Context + +It should be noted that this fringe event is being organised both by a local Institute - the University of Cape Town - as well as an international project-based consortium (Sci-GaIA). This is by no means incidental: it is an interesting time in terms of research infrastructure in South Africa, and in particular the Western Cape. For one thing, a regional e-Infrastructure has recently been created - the [Inter-university Data-Intensive Astronomy](http://www.uct.ac.za/dailynews/?id=8767) partnership. The [Human Heredity and Health in Africa (H3A)](http://www.h3africa.org/) consortium has their e-Infrastructure project ([H3ABioNet](http://h3abionet.org/)) also has a significant presence in the region. + +The University of Cape Town has [recently been awarded](http://www.eresearch.uct.ac.za/news/uct-led-consortium-build-first-regional-data-node-national-cyberinfrastructure) a centre as part of the National Integrated Cyberinfrastructure Initiative. A similar [announcement was made about the data science](http://www.wits.ac.za/news/latest-news/general-news/2016/2016-08/wits-to-lead-national-e-science-consortium.html) platform proposed at Wits University. Along with the existing investments across the country, a coherent national platform is emerging, but it is still in its formative phase. Therefore, we hope that this fringe event can help inform the development of these important institutional initiatives. + +However, the question of international scientific collaboration and open reserach platforms across countries still looms. How are events in South Africa driving the rest of the African continent if at all ? If we could look ahead 5 years, what kind of research infrasructures await, for example, the [Next Einstein Forum fellows](http://nef.org/nef-fellows/), or their prodiges, count on ? Are the research methods we teach and adopt in universities now compatible with the vision of Open Science, and is the infrastructure that supports that research ready for it ? + +These are not issues for a particular institute or country. These are issues for the wider community and are part of a conversation which no single project or institute can answer, but need to be considered and discussed in the open. + + +# Paths to Success for Open Science in Africa. + +Recently, the [Dakar Declaration on Open Science in Africa](http://www.sci-gaia.eu/dakar-declaration) was made, recognising issues of access, reproducibility, re-usability, discoverability and impact of African scholarship. The declaration has been signed by several prominent university and research infrastructure bodies in Europe and Africa. + +Research infrastructures – in particularly e-Infrastructures – can of course play a crucial role in the enabling of an Open Science paradigm. Indeed, many aspects of Open Science cannot be enabled without access to network, data, repositories and computational infrastructures, as well as platforms for the publication and re-use of scientific software. + +> **However, to what extent are our current and planned research infrastructures actually able to implement our Open Science aspirations ?** + +Several related questions arise : + + 1. What does current experience in using our research infrastructures say about motivators and inhibitors of the actual endeavour of Open research ? + 1. The European Commission has developed high-level roadmap on an [Open Science Cloud](http://ec.europa.eu/research/openscience/index.cfm?pg=open-science-cloud) - how is Africa situated with respect to this view ? + 1. How will e-Infrastructures being developed to satisfy the needs of specific research communities be able to accommodate sharing and interoperability with existing and peer infrastructures ? + 1. What role do e-Research centres play in enabling the full exploitation of the wide range of research infrastructures available to researchers ? + 1. To what extent are Open principles embedded in STEM curricula, and what can be done to improve this ? + +> **There are many paths to success in opening science, but also many roadblocks.** + + +# Aim of the fringe event + +This fringe event will tackle two main questions of Open Science as it pertains to Research Infrastructures, particularly e-Infrastructures : + + 1. How are individual African scientists and students adopting open science practices ? + 1. What does the African research infrastructures ecosystem inhibit or promote open science ? + +## Organisation of the event + +Our event will : + + 1. Invite champions on various scientific fields in the region to express their challenges and solutions to issues facing them, during their open science endeavour + 1. Relate the recent UCT e-Research experience in enabling open science at an institutional and regional level + 1. Demonstrate a open science platform developed in the context of the Sci-GaIA project. + 1. Provide a space to investigate and critically examine the issues around open science, through a brainstorming and discussion session + + +## Audience : + +The event will be open to researchers, content creators, educators, developers and policy makers in research infrastructures, with specific use cases in fields including, but not restricted to bioinformatics, health, agent-based simulation, human language technologies, earth sciences, climate, weather etc. + +There will be particular focus on infrastructure interoperability and reproducibility of research using collaborative platforms. + +There will be invited speakers from research communities across Africa, including but not restricted to, the communities of practice supported by the Sci-GaIA project. + +----- + +If you are at all interested in this event and would like to contribute or participate, please [let us know](http://discourse.sci-gaia.eu/t/paths-to-success-for-open-science-in-africa-africa-arabia-regional-operations-centre/2303) + +---- diff --git a/_posts/2016-09-24-FutureGateway-Deployment.md b/_posts/2016-09-24-FutureGateway-Deployment.md new file mode 100644 index 0000000..35ccbb7 --- /dev/null +++ b/_posts/2016-09-24-FutureGateway-Deployment.md @@ -0,0 +1,68 @@ +--- +layout: post +title: 'Future Gateway API Deployment' +description: '' +headline: +category: blog +tags: [FutureGateway, API, DevOps, Docker] +image: + feature: + attribution: +comments: false +mathjax: false +discourse: true +--- + +# Future Gateway - always an appropriate name. + +[FutureGateway](https://github.com/FutureGateway) is a project to develop an API and related services which will allow web applications to interact with back-end distributed infrastructure of almost any kind. Its design principles are to provide a platform-agnostic bridge between front-end (web) interfaces and back-end interfaces. It adopts the philosophy of using open standards when it comes to implementation choices as far as possible, and thus relies on the [SAGA]() standard - specifically the [jSAGA](http://software.in2p3.fr/jsaga/latest-release/index.html) implementation for interacting with grid, cloud and HPC sites. For different cloud stacks, the gateway uses [OCCI](http://occi-wg.org/) + +The reliance on standards means that the front-end developer needs to implement far less functionality, and has access to far more potential resources, as compared to having to implement native functionality for each different kind of backend - different grid, cloud, HPC stacks. + +Future Gateway - aside from being the most future-proof name possible for such a project, is part of the [Indigo Datacloud](https://www.indigo-datacloud.eu/) project, which is working on a full stack PaaS for scientific cloud computing. Of course, we're not aiming for that scale, but we want to provide an easy means for deploying and orchestrating the services necessary for a FutureGateway. + +# FutureGateway components + +The FutureGateway stack consists essentially of three components : + + 1. REST API[^CurrentAPI] + 1. event and job tracking database + 1. SAGA interpretation library + +One might think that it would be easy to create independent containers for each of these services and spin them up as needed - however that would be just slightly too simplistic: it would only solve the issue of deployment. In fact containers have been or will soon be created to _contain_ the services necessary to put up a functional science gateway, but the creation of the images is only a minor aspect of the problem. + +## The problem of orchestration. + +The problems faced here are those of _orchestration_ and _configuration_. While the container running the tracking database is simply a mysql container[^MysqlContainer], which can be easily configured - the **variables** needed for configuration _also_ need to be passed to the API Server in order for it to understand how to connect and write to the relevant tables. The need to share these variables across services makes an orchestration engine which can _also do configuration management_ very attractive. Docker does orchestration nicely, but is not so great (or rather, does not encourage or enforce) good configuration management habits. However, DevOps is your friend here, since you can express variables associated to concepts such as groups or roles[^Ansible]. Solving this problem will mean creating the base images necessary to start off with, and then applying the correct configuration when they are instantiated. + +One issue remains - where to write persistent data. It is widely recommended that the SQL databases are written _outside_ of the running container - either on the host filesystem, or on docker volumes. The [best practice](http://stackoverflow.com/questions/18496940/how-to-deal-with-persistent-storage-e-g-databases-in-docker) is recommended to use a _data only_ container to manage the data for databases[^DockerDocs]: + +> If you have some persistent data that you want to share between containers, or want to use from non-persistent containers, it’s best to create a named Data Volume Container, and then to mount the data from it. + +These data containers do nothing more than expose the volumes for other containers to mount and therefore write to, and provide us with a means to have _portable deployment_ and orchestration. + +## Orchestration in plain English + +The following steps are required to get the stack up : + + 1. :whale: **Create base Docker images prior to deployment**: + * **API DB**: The [official mysql server](https://hub.docker.com/_/mysql/) image + * **Data Container**: the empty container which holds the sql data (the mysql image will be used) + * **API Server**: Base OS image with the flask application installed. + * **SAGA Tomcat Server**: The official [tomcat](https://hub.docker.com/_/tomcat/) image + 1. :arrow_down: Pull the containers: + * [docker-image](http://docs.ansible.com/ansible/docker_image_module.html) module will pull down the relevant images + 1. :arrow_forward: Start the containers + * Ansible will be used to start the containers (using [docker-container](http://docs.ansible.com/ansible/docker_container_module.html)) + * Ansible roles are used to configure the containers. + +Variables from the _group_ are applied across containers as needed, and need not be redundantly defined in several places. In this way, a single playbook and a few roles can be easily distributed to wherever you want to deploy the science gateway, ensuring portability of both the configuration and the data. + +---- + +### Footnotes and References + +[^CurrentAPI]: The API is currently implemented as a python flask application. The SAGA libraries are written in java, and need to be included in a tomcat application, which means that the SAGA and REST applications are separated. Future developments will re-implement the API as a Java application, and have the SAGA libraries internally contained, reducing the need from 3 components to two. +[^MysqlContainer]: In fact we have just used the official [MySQL container on Docker Hub](https://hub.docker.com/r/mysql/mysql-server/). +[^Ansible]: Roles are an Ansible-specific concept - any Puppetmasters out there want to let us know what the equivalent for Puppet is ? +[^DockerDocs]: Quoted from the [definitive guide](https://docs.docker.com/engine/tutorials/dockervolumes/#/creating-and-mounting-a-data-volume-container) on managing data in docker containers. diff --git a/_posts/2016-10-20-EGI-ADV-SVG-CVE-2016-5195.md b/_posts/2016-10-20-EGI-ADV-SVG-CVE-2016-5195.md new file mode 100644 index 0000000..6d79530 --- /dev/null +++ b/_posts/2016-10-20-EGI-ADV-SVG-CVE-2016-5195.md @@ -0,0 +1,32 @@ +--- +layout: post +type: status +title: Linux kernel Vulnerability CVE-2016-5195 +description: EGI SVG Advisory 'Critical' risk - apply OS patches +headline: Sites running Debian and RedHat - apply patches! +category: security +tags: [AAROC, CSIRT, operations, security, updates, CVE-2016-5195] +comments: false +discourse: true +--- +# Heads-up from EGI: CVE-2016-5195 + +EGI CSIRT (Software vulnerability Group) has alerted us to a critical vulnerability in the linux kernel affecting most distros. + +> 'CRITICAL' Risk CVE-2016-5195 Linux kernel privilege escalation [EGI-SVG-CVE-2016-5195](https://wiki.egi.eu/wiki/SVG:Advisory-SVG-CVE-2016-5195) +A kernel vulnerability has been found concerning a race condition allowing an unprivileged local user to gain write access to otherwise read only mappings and increase their privilege in the system. + +At present this is a 'Heads up'. However sites running an OS where patches are available should urgently install the new version. (Currently Debian and Ubuntu.) + +Actions required/recommended +============================ + + - Sites running an OS where patches are available (currently Debian and Ubuntu) are advised to install the new version *within the next 7 days*. + - Machines allowing unprivileged user access, such as Grid Worker Nodes, should be prioritised. + - **At this stage a rolling update and reboot is recommended as sufficient.** + +Other sites, running an OS where patches are not available yet should prepare the update, which they will be required to apply within 7 days when new version will be available. Sites are also encouraged to investigate workarounds (e.g. systemtap) for systems with direct unprivileged user access, such as User Interfaces. + +Sites failing to act and/or failing to respond to requests from the EGI CSIRT team risk site suspension. + +----- diff --git a/_posts/2016-12-22-CODE-RADE-containers.md b/_posts/2016-12-22-CODE-RADE-containers.md new file mode 100644 index 0000000..474bd87 --- /dev/null +++ b/_posts/2016-12-22-CODE-RADE-containers.md @@ -0,0 +1,54 @@ +--- +layout: post +title: 'Containers for CODE-RADE (Part 1)' +description: 'Part 1' +headline: 'Story of a Dubious Idea' +category: blog +tags: [CODE-RADE, containers, docker, bad ideas] +image: + feature: bad-idea.jpg + attribution: "Image courtesy http://www.gratisography.com/" +comments: false +mathjax: false +discourse: true +--- + +# CODE-RADE Foundation Release 3 + +Long story short, Foundation Release 3 was mean to "widen" CODE-RADE, by eliminating central points in the design. Foundation Release 2 was based on a Jenkins server with build slaves was limited in several aspects, mainly due to the kind of infrastructure we were using, but also due to the architecture. FR2[^FoundationReleases] + + 1. **Build coverage**: Only CentOS-6 and Ubuntu-14.04 operating systems were covered. These were provided as static, standalone virtual machines on a local cluster at UFS. In order to provide wider coverage in terms of target operating systems, we needed to add further VMs - however these would need to be tied to the local cluster, thereby competing with the other activities at the site. + 1. **Geographic coverage**: Adding new resources to the platform required them to be physically located at UFS, where the build slaves mounted the shared storage, and were accessible by the jenkins slave launcher. + 1. **Technology coverage**: The architeture of CODE-RADE FR2 is tightly bound to the technology used to build it, as well as the artefacts. We specifically needed a more abstract way of expressing build pathways, so that other sites could contirbute continuous integration services, as well as provide other forms of testing services. + +## Moving from static to cloudy architecture + +The biggest bottleneck of CODE-RADE in FR2 was the central repository of CI artefacts, to which all nodes wrote their builds. This was a NFS-mounted share exported from the jenkins server, which experienced severe performance hits when builds wiht large configuration matrices were invoked. In order to speed up the builds, it was hoped that we could parallelise much of the work, by encapsulating the build into self-contained environments, which could then be instantiated anywhere. + +Another bottleneck was the availability of build slaves. Using statically provisioned build slaves, and a central repository of artefacts, there were severe bottlenecks and large integration times, especially for applications which had large and complex dependency trees. The capability to create build slaves as they were requried, rather than rely on a queue for a single resource, represented a possibility to more efficiently use the available resources. However, a move from static virtual machines of a specific kind of operating system, to a build environment based on containers needed to take into account a few crucial differences between these two environments. + +# Differences between virtual machines and containers. + +There are three main differences between virtual machines exposing entire operating systems, and linux containers. These differences imply certain choices and nuances in approach. + + 1. **Single process**: Linux container should run single processes[^DockerSingleProcess] + 1. **Persistence**: Containers should be ephemeral[^DockerEphemeral]. + 1. **Data sharing**: Containers are encapsulated, but we need to re-use artefacts from lower in the dependency tree. + +Having speedy builds means using as many CPU resources as possible, in order to complete the build tasks as fast as possible; typically this means using "make"-level parallelism[^ParMake], although several other means are available, for other build systems, such as Ninja[^ParNinja] and Apache Ant[^ParAnt]. Speeding up the build, almost by definition, means that there will be more than one process. + +## Re-use of build artefacts + +The ephemeral nature of containers is a benefit to the project, since builds can reliably be performed in clean environments. However, the _result_ of builds - in particular the build artefacts - need to be accessible to subsequent containers. This is one of the key aspects of the platform - atomic components, which can be re-used. This re-use of artefacts is not only necessary during the _integration_ phase, but also during deployment and of course re-usage at sites. + +Apparently, ensuring data persistence is nontrivial in the docker world. The first aspect we would need to address seriously, was this. Since this is a topic for a whole other post, we will deal with it in Part 2. + +# Footnotes and References + +[^FoundationReleases]: We refer to foundation releases with the prefix "FR" and numerical tags (1, 2, 3, etc). Thus Foundation Release 1 is "FR1", Foundation Release 2 is "FR2", _etc_ +[^ParMake]: Several technologies are used to build applications, although the most common is make. Speeding up a build usig make is often possible, depending on the resources available, by passing the -j <integer> flag where integer specifies the level of parallelism requested. See [GNU Make documentation on parallel builds ](https://www.gnu.org/software/make/manual/make.html#Parallel). + +[^ParAnt]: See [Ant documentation](http://ant.apache.org/manual/Tasks/parallel.html) +[^ParNinja]: See [Ninja's comparison to make](https://ninja-build.org/manual.html#_comparison_to_make) +[^DockerSingleProcess]: See [the Docker best-practices guide](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/run-only-one-process-per-container) +[^DockerEphemeral]: See the [Docker best-practices guide](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) diff --git a/_posts/2017-01-11-How-To-ROD.md b/_posts/2017-01-11-How-To-ROD.md new file mode 100644 index 0000000..666cb22 --- /dev/null +++ b/_posts/2017-01-11-How-To-ROD.md @@ -0,0 +1,121 @@ +--- +layout: post +title: 'How to ROD' +description: "Taking the bull by the nose ring" +headline: ' ' +category: blog +tags: [AAROC, EGI, ROD, procedures, blog] +image: + feature: tumblr_oihkemAUKP1sfie3io1_1280.jpg + attribution: "Image courtesy New Old Stock" +comments: false +mathjax: false +discourse: true +--- + +# 2017 : Off to a ... start. + +Once more round the sun we go. Oh yay. Whatever, the holidays are over, we'd best just get used to the idea. +
+ +
Whee ! A new beginning :smile: Doh ! Same old problems. :anger: :weary:
+
+ All the same, it's time to get the year off to a solid start in the Africa-Arabia Regional Operations Centre. The main activity that we undertake here is to ensure operations coordination, which is the responsibility of the so-called **Regional Operator on Duty**, or ROD. The term was coined long ago during the EGEE projects, and survived into the current EGI world of federated infrastructure. + +> ROD (Regional Operator on Duty) is a role which oversees the smooth operation of EGI infrastructure in the respective NGI. ROD team is responsible for solving problems on the infrastructure within own Operations Centre according to agreed procedures. They ensure that problems are properly recorded and progress according to specified time lines. They ensure that necessary information is available to all parties. The team is provided by each Operations Centre and requires procedural knowledge on the process. The role is usually covered by a team or people and is provided by each NGI. Depending on how an NGI is organised there might be a number of members inthe ROD team who work on duty roster (shifts on a daily or weekly basis), or there may be one person working as ROD on a daily basis and a few deputies who take over the responsibilities when necessary. This latter model is generally more suitable for small NGIs. +> +> the [EGI description of Regional Operator On Duty](https://wiki.egi.eu/wiki/Regional_Operator_on_Duty) + +## Operations == Stability + +Operations is a plce where you typically want as little as possible to change. The art of ROD is making sure that there is as little disruption as possible to the services in the federation. Of course, things _do_ happen from time to time (and yes, bad things also happen). Avoiding these disruptions is in practice impossible, so the responsibility of ROD is to ensure that the relevant actors are informed and that any mitigating actions necessary are taken. + +This typically means checking the [ROD dashboard](https://operations-portal.egi.eu/rodDashboard/ngi/AfricaArabia/) on the [Operations Portal](https://operations-portal.egi.eu/) for new alarms from the [ARGO](http://argo.egi.eu/) monitoring service. When there's a new alarm generated by ARGO due to a service failure or problem, a [GGUS ticket](http://ggus.eu/) is opened by ROD and assigned to the site. Already open tickets are checked on, to see whether the probe that generated them has changed state (we always hope for the beloved green probe, meaning that the issue has been fixed); if not, an update is requested from the responsible site. + +The [Site Operating Level Agreement](https://documents.egi.eu/document/31) describes the acceptable levels of availability and reliability of services (A/R), and the expected timeframes within which issues should be addressed. If issues are not fixed or acknowledged by the site administrator within the timeframe specified in the OLA (typically 5 working days), the ticket starts to **expire** and should be **escalated** by ROD, to a relevant support unit perhaps in the case that expert advice is needed. The goal is to always achieve maximium **reliability** even when services aren't 100 % **available**. + +## Stability == Good communications + +This emphasis on reliability even in imperfect operating conditions translates to humans taking appropriate actions. They may require just a short amount of time, and minimal effort but help to keep user communities and peer infrastructures alike informed of the state of our services. Most importantly, however, ROD has to ensure that where support is required at site-level, that the experts who can provide that support are informed and are able to help. The worst-case scenario is where a site administrator is told that they have problems at their site, but have not idea how to fix it, and feel that they have been abandoned to their fate by a team that instead was supposed to support them. + +The relationship beteween the sites (and of course the people who staff them) and the Regional Operations Centre is a deicate one, based on compromise and mutual support, for the greater benefit of infrastructure over the limited benefit of isolated control. Often the need to respond to operations issues, make changes to serivces, or indeed maintai services necessary for interoperation can seem like unnecessary overhead to a site administrator which has to deal with the incessant demands of an active local user group. It's ROD's job therefore to ensure that the federation's need for a transparent and reliable infrastructure are met, as well as the site's need to satisfy their users' demands, local policies and the demands that the rest of their job makes on their time. + +# How we roll. + +The ROD duty is in principle shared amongst two institutes in the region - CSIR Meraka and CNRST. Since the activity is not very demanding for experienced operators, it is usually done by CSIR Meraka. A few minutes each day (typically 2 [pomodoros](https://en.wikipedia.org/wiki/Pomodoro_Technique) :tomato: ) is sufficient to go through the alarms, tickets and issues, reminding the people that they've been assigned to that action is needed, and closing them where possible. + +## Duties and procedures + +The ROD Duties are well-described on the [EGI Wiki](https://wiki.egi.eu/wiki/ROD_Duties). Quoted from their wiki page : + +> The ROD on duty is required to: +> +> - check alarm notifications in the Dashboard at least twice a day; +> - close alarms which are in the OK state; +> - handle non-OK alarms less than 24 hours old (notify the site administrators according to your NGI's procedures); +> - create tickets for alarms older then 24 hours that are not in an OK state; +> - escalate tickets to NGI Management/EGI Operations if necessary (in the Dashboard); +> - monitor and update any GGUS tickets up to the solved status (preferably via the Dashboard); +> - handle the final state of GGUS tickets not opened from the Dashboard by changing their status to verified. + +Complementing this list of duties is an outline procedure to be followed. Following common procedures is an important part of ensuring interoperability between AAROC and other infrastructures. For this reason, we try to follow the [standard operation procedures](https://wiki.egi.eu/wiki/PROC01_EGI_Infrastructure_Oversight_escalation) when addressing issues. + +
+ROD escalation procedure, from EGI.eu +
ROD escalation procedure. Image credit: EGI.eu
+
+ +While the operations portal really helps in ensuring that raised alarms are indeed associated with a ticket, the last item in the list of the ROD's duties - _"handle the final state of tickets not opened from the Dashboard"_ - is not the easiest thing in the world to keep track of. Especially since a few times issues are not specifically related to the _operations_, but rather various _campaigns_ which are undertaken either at the ROC or EGI level. Keeping track of these - specifically their deadlines and followups - is a black art. + +# Things we do in Africa-Arabia + +Every region or NGI organises things their own way. Some have weekly meetings face-to-face, some rely on common task trackers, email lists, whiteboards, etc. We have the privelige of living in the largest region (bar, perhaps, Russia) that EGI interoperates with, and have sites which are vastly different between them, both in the nature of the hardware and services, as well as the actual people who staff them. In the early days of SAGrid, we had the luxury of at least inhabiting the same country, speaking the same language, being more or less on the same technical level. With the fusion of ex-SAGrid sites with the ex-EUMedGrid sites during [CHAIN](http://www.chain-project.eu), we were able to operate at a large scale, thereby making interoperation with peer infrastructures feasible, but we also introduced some new complexity. + +Too much complexity can cause chaos, and inhibit the capacity of a system to do work (in a thermodynamic sense, you understand), but just the right amount can be a good thing. In order to organise the work that's requested of the sites, we need tasks to be properly assigned, with clear responsibilities, deadlines and checking. Often this is done with a periodic teleconference where a task list is taken item by item to get feedback and see what still needs to be done. In my opinion however, this is more of a time-eater in an environment which is already tight on that precious commodity, so we turned to the web to make things better. + +## Slack + +We use Slack a lot at the [Africa-Arabia Regional Operations Centre Slack](https://africa-arabia-roc.slack.com), for all kinds of situational awareness and collaboration. We have an operations channel for each site, which typically only has the site admin for that site in it, as well as anyone who is working on technical issues related to the site. The idea here is to keep things focussed. ROD also creates a new channel each month to give the the operators a place to discuss quickly whatever issues are faced by the region as a whole. Some pertinent aspects of this channel : + + * **Operators Only**: Only site operators and bots which help operations issues are in the chanel. + * **Issues at scale**: The channel is for dealing with collective issues, not site-specific issues. There are dedicated channels for that. + * **Get Stuff Done ™**: Or in other words : "A little less talk, a little more action please". This is not a place for discussion, but for ensuring that people are informed of relvant issues timeously. + * **Best Before**: The channel lasts a month. This makes it easy to summarise the events of the month into a handover message. + * **Bots, bots bots**: We use several bots and integrations to help us keep track of who needsd to do what. + +The builtin `/remind` command in slack helps ROD and operators to gently remind each other of things that need to be looked at by a particular time. The Trello integration is also very useful in organising work. + +## Trello Board + +The Africa-Arabia Regional Operations Centre [Trello Board](https://trello.com/b/WmqbaO8t/operations) is organised into columns per-site, as well as an incoming "triage" column, and a ROD column. The site columns are integrated into the site-specific ops channel in slack, so that changes to cards in those columns are propagated specifically to the people in the channel responsible for the site. + +Site operators can also create cards for ROD, triage etc on Trello directly from Slack using the `/trello` integration. This makes it much easier to stay in Slack and update ROD and other teammates on progress or new issues, as well as file tasks away as "done". Another great thing about Trello is the ability to update cards via email. + +One of the things we've got in "triage" is the full list of GGUS tickets : + +This allows ROD to keep a more comprehensive list of GGUS tickets than are present on the ROD dashboard, as well as add other issues or tasks that need to stay in context. + + +## Discussion Forum + +Finally the ability to generate and retain knowledge about technical issues was for a long time relegated to the capability of individuals to trawl their email to find that one mail that contained the magic fix for the thing that keeps breaking. Well, clearly there are better ways of communicating and remembering things than using email. Slack isn't great for this either since it's a more private, real-time place to chat, so we've turned to [Discourse](http://discourse.org) to build a discussion forum where longer-form discussions can be started - and most importantly _ended_ - by marking them as "solved". + +The [African e-Infrastructures Discussion Forum](http://discourse.sci-gaia.eu) has a category related to [GridOps](http://discourse.sci-gaia.eu/c/devops/gridops) category which is starting to gain traction. + +# Let's get it together in '17 + +So, the tools are pretty much in place to make sure that we can sustain stable operations in 2017. Whether or not we actually do, as a ROC or as individual sites, really depends on our commitment to respecting the procedures we've set out - discussing them and updating them where necesary, but most importantly sticking to them for the most part. Let's get the year off with the traditional "New Year's resolution". Although 2017 promises to be a year of tremendous activity and very demanding, let's set a few goals for ROD this year : + + 1. **Honour the Deal**: We will try to stick to the deadlines specified in the [ROD procedure](https://wiki.egi.eu/wiki/PROC01_Grid_Oversight_escalation) + 1. **Use Downtimes better**: We will put sites into downtime rather than allow tickets to expire + 1. **Improve Core Services**: Site A/R has often suffered from problems in core services. We need to improve the performance of these, and be more proactive on dealing with issues which impact them. + 1. **Tell the story**: We undertake to write a monthly summary of the region's infrastructure status and issues, by summarising the ops channel for that month, and writing a handover blog post. + + +----- + +Ok, 2017. Time to take you on. + +
+ +
diff --git a/_posts/2017-01-13-New-DevOps-Start.md b/_posts/2017-01-13-New-DevOps-Start.md new file mode 100644 index 0000000..e12f172 --- /dev/null +++ b/_posts/2017-01-13-New-DevOps-Start.md @@ -0,0 +1,64 @@ +--- +layout: post +title: 'A new start for AAROC/DevOps' +description: "Detaching AAROC/DevOps from it's past" +headline: "Detaching AAROC/DevOps from it's past" +category: blog +tags: [AAROC, code, DevOps, Github] +image: + feature: separate.jpg + attribution: "cc-by Mandy Goldberg on Flikr" +comments: false +mathjax: false +discourse: true +--- + +A few years back, we came to the conclusion that operating services manually was a pretty bad idea. The feeling that the proper configuration of grid middleware[^gLite32] was a dark art was pervasive - so many configuration files, so many separate services, so many configuration options ! Impossible to do _right_, impossible to _test_ and most of all, no way to keep knowledge about _what_ was supposed to be done, let alone _how_ it was supposed to be done. Deploying new sites or even individual services had to be done with the physical presence of an experienced operator, and rarely was there enough time to transfer whatever knowledge that person had to the staff at the new site. + +# Genesis of DevOps in AAROC + +During the [All-Hands meeting](http://agenda.ct.infn.it/event/895/)[^AllHands] in Pretoria, we had a few good presentations[^HazelhurstPuppet] [^KannelopoulosAnsible] on tools which we used by site administrators. The term "DevOps" was new back then and just gaining traction as a practice, but this meeting was the genesis of what would be come a rich and widely-used repository of code for the services in the Regional Operations Centre. Originally only [Puppet](https://puppet.com/), and then [Ansible](http://www.ansible.com) were used - a precursor to the many, many tools which would come in the future, particularly to manage cloud and container platforms. However, we have never argued about which tool is the right one, or tried to standardise on _one_, because the important thing is that whatever service is being offered to the community, that it is reliabily and reproducible deployable. The concept of "executable infrastructure" has been put forward several times[^ExeInfraUC2015] [^ExeInfraDI4R] as encapsulating this idea. + +# Much more than Operations + +We've worked hard to promote the DevOps culture in the region, because we're a distributed, multi-cultural group of people with widely varying skill sets. This diversity is a great asset if it can be properly harnessed, and if the right level of adherence to common practice and empathy with those who may do things differently from you can be achieved. The repository of code has really helped us deploy services in new places, better debug issues, manage upgrade cycles, middleware releases, etc. However, the importance of this repository extends far beyond the important, but somewhat staid world of infrastructure operations. We use it to generate documentation, research output and even run training and teaching events. + +## Documentation + +Much of the need for a DevOps culture is for increased transparency in the _procedures_ - the need for them to be reproducibly executed by even new members of the collaboration. The tools which are used to _implement_ this culture go a long way to reducing the need for "manuals" and other forms of documentation. In the case of Ansible playbooks, the code itself is as easy to read as it is to write, which is to say that it is written in "plain English." This is all well and good as far as it goes, but what about our colleagues whose first language is _not English_, but French, Arabic, Aramaic, Yoruba, _etc_ ? No matter the level of intent to keep code expressive and clear, there is always some level of connotation or opacity in the way things are implemented, if you're new to the project, so some form of "getting started" manual for service deployment is necessary. There are some steps, for example, which are not automatable (such as site-specific variables or passwords), and thus need to be described specifically for human consumption. + +The typical procedure for writing this information is to maintain it in the "README" file of the module, role _etc_ which is being used. We have been using [`mkdocs`](http://www.mkdocs.org/) to generate html documentation from these README files, which are typically written in Markdown or RST. This documentation is currently hosted at [afica.grid.org/DevOps](http://www.africa-grid.org/DevOps)[^WIPYO]. + +## Review and Publication + +[AAROC/DevOps](https://github.com/AAROC/DevOps) aims to be an executable expression of our _actual infrastructure_. It is both a software package as well as a dataset, and as such needs to respect a few quality criteria - it should for example be tested at some level, and the contents should have undergone some level of peer review and discussion where appropriate. [Recent additions]() to the Github API[^GithubAPI] allow [protected branches](https://help.github.com/articles/about-protected-branches/), which repo maintainers can enforce code review on, such as automated testing and [review by actual humans](https://help.github.com/articles/approving-a-pull-request-with-required-reviews/). While we still have a long way to go to improve the quality of these outputs, we have started to publish the repository release via [Zenodo](https://zenodo.org). Assigning DOIs to code which represents the specific state of infrastructure is a good way to get credit for work done. + +## Teaching + +At the end of the day, code has to be written by _people_ - developers. Sure, the AI revolution may be right around the corner, but until we get there, our best bet for taking the collaboration forward sustainably, is to have as many people as possible capable of reading and writing the code for services. More eyes can also translate into better reviews, and therefore better tested and more widely-used code. To this end, we've been working on a companion repository to DevOps, specifically to improve the capability of people we potentially may be working with in the region to use Ansible[^WhyAnsible]. This repository can be used to deliver a short, self-contained course[^BootCamp]. The general idea is to fork the ["Software Carpentry"](http://www.software-carpentry.org) idea into an "Infrastructure Carpentry" concept... Something to blog about another time though. + +# Time to stand on our own feet. + +We originally forked an existing repository to get started, and eventually stabilised on [DevOps repo for the region](https://github.com/AAROC/DevOps). Since the fork of the [GRNET Ansible code for grid services](https://github.com/auth-scc/grid-services-deployment) way back in 2013, there have been some major changes. + +Several releases of Ansible have come out, some of them major, with backward-incompatible code; a full refactor of the code was done[^DevOps2015]. We have also added several services in the identity-management, application delivery and cloud service deployment areas which are not specifically for grid infrastructures. There was also a large re-organisation of the repository to accommodate site-specific code, from whatever tool they are using. + +The repository has taken on a life of it's own. With [8 releases](https://github.com/AAROC/DevOps/releases), [12 contributors](https://github.com/AAROC/DevOps/graphs/contributors), [24 forks](https://github.com/AAROC/DevOps/network) and just over [1700 commits](https://github.com/AAROC/DevOps/commits/master) to the master branch, it has totally diverged from the original repository from which it was forked. This has started to create some issues - [particularly in the way contributions are counted](https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile/#commit-was-made-in-a-fork), and [the way in which GitHub indexes forks](http://stackoverflow.com/questions/33626326/how-to-search-a-github-fork-for-code-using-the-github-search-api) for searching. The time has come to detach the repository from the network it was forked from, and live it's own life. + +Apparently, though, [this is not trivial](https://www.quora.com/Git-revision-control-How-can-one-detach-a-forked-project-in-GitHub) - although it's certainly possible. Simply creating a new repository and populating it with the content of the fork, to force a "fresh start", will cause you to lose all of the important metadata related to the repo - forks, stargazers, issues, wiki, etc. However, a brief exchange with - it must be said, a very helpful - GitHub helpdesk ensured that the relevant information was backed up before the detach took place. + +We now have a stand-alone repository which far better reflects the work done by the community, and puts it on a better footing for the future. + +# References and Footnotes + +[^gLite32]: We're talking [gLite 3.2]() here kids... that was a LONG time ago ! +[^AllHands]: This was one of the last technical training sessions we had ever run, in conjunction with GRNET, one of the partners of the very successful [CHAIN-REDS project](https://www.chain-project.eu) which we participated in. +[^HazelhurstPuppet]: [Site Administration Tools : Puppet](http://agenda.ct.infn.it/event/895/contribution/22/material/slides/0.pdf) - Scott Hazelhurst, AAROC / CHAIN-REDS All Hands meeting, Pretoria, 2013. +[^KannelopoulosAnsible]: [Site Administration Tools : Ansible](http://agenda.ct.infn.it/event/895/contribution/23/material/slides/0.pptx) - Christos Kanellopoulos, AAROC / CHAIN-REDS All Hands meeting, Pretoria, 2013. +[^ExeInfraUC2015]: [Executable Infrastructure for Collaboration at Regional Level](http://www.ubuntunet.net/sites/default/files/19.%20Becker%20-%20Executable%20Infrastructure.pdf) - Bruce Becker, Ubuntunet Connect Conference 2015, Maputo, 2015. +[^ExeInfraDI4R]: [Executable Infrastructure for Africa and Arabia](https://www.digitalinfrastructures.eu/content/executable-infrastructure-africa-and-arabia) - Bruce Becker, Digital Infrastructures for Research Conference, Krakow, Poland, 2016. +[^DevOps2015]: Bruce Becker, Marco Fargetta, Chris Lee, Paschalis Korosoglou, Pavlos Daoglou, Bouchra Rahim, Gerrit Botha, (2015). AAROC DevOps pre-release [Data set]. Zenodo. http://doi.org/10.5281/zenodo.19100 [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.19100.svg)](https://doi.org/10.5281/zenodo.19100) +[^WIPYO]: It's definitely a work in progress still, but hey - better than nothing, right ? +[^GithubAPI]: We are referncing [GitHub API V3](https://developer.github.com/v3/) here, specifically the part which controls how [branches are managed](https://developer.github.com/v3/repos/branches/) +[^WhyAnsible]: We have chosen Ansible as the tool for the bootcamp, because in our opinion it has the lower barrier to entry compared to Puppet or other tools, and it's simple serverless architeture makes it easy to demonstrate and teach. +[^BootCamp]: Bruce Becker, Chris Rohrer, & Marco Fargetta. (2017, January). AAROC/AnsibleBootCamp: Ansible BootCamp - Entebbe. Zenodo. http://doi.org/10.5281/zenodo.242394 [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.242394.svg)](https://doi.org/10.5281/zenodo.242394) diff --git a/_posts/2017-03-18-CSIR-BootCamp.md b/_posts/2017-03-18-CSIR-BootCamp.md new file mode 100644 index 0000000..9e1ddfe --- /dev/null +++ b/_posts/2017-03-18-CSIR-BootCamp.md @@ -0,0 +1,99 @@ +--- +layout: post +title: 'DevOps Bootcamp : CSIR ' +description: ' ' +headline: ' ' +category: blog +tags: [DevOps, Ansible, Automation, CI, CD] +image: + feature: "AnsibleBootCampCSIR.jpg" + attribution: "[James Pond](https://stocksnap.io/author/41685)" +comments: false +mathjax: false +discourse: true +--- + +# Time to build some more awesome + +At the Cyberinfrastructure Unit of the CSIR, we're in the _infrastructure_ game. We build high-performance networking, compute and data infrastructure for research communities. However, that infrastructure is quite meaningless unless it is efficiently used, and this is done by exploiting the infrastructure through the services that it offers. Some of these services are built directly by our engineers, whilst others are built "out there" in the wild scientific world. But services should be easy to reproduce, scale, debug, share. + +The Africa-Arabia Regional Operations Centre (AAROC) operates a complex set of such services which run on infrastructure provided by several providers from across the continent. Orchestrating and maintaining a series of middleware stacks at several sites, which as a whole need to inter-operate with peer infrastructure abroad, is clearly a complex task. Ensuring that there is continuity in user experience (and indeed in some cases to user applications) is essential, as is reacting to changing environments, security threats and usage patterns. AAROC has adopted an "Executable Infrastructure" approach, focussing on the ability to express services and states _as code_, in order to better test, integrate and deliver them to sites. + +## Basic skills for infrastructure competency + +This philosophy emphasises agility, empathy, transparency, reproducibility and communication, and is part of the "DevOps" culture. During the course of the years, we have developed a format which aims to deliver _basic skills_ to infrastructure engineers, operations teams, and research software engineers - the _"bootcamp"_. This concept has been perfected by the [Software Carpentry](http://www.software-carpentry.org) movement, which aims similarly provide basic lab skills to modern scientists. In the case of Software Carpentry, the focus is on core tools for day-to-day research, such as using change control, or data analysis with Python or R. In the case of the DevOps bootcamp, we aim to do the same for e-Infrastructure. The goal is to build a common vocabulary, and wider understanding of how to best develop, deliver and deploy research platforms, and a better means for collaboration in doing so. + +## Recent bootcamps + +This will be the 4th DevOps Bootcamp, and the last one supported by the [Sci-GaIA project](http://www.sci-gaia.eu). During the course of the project - which will hold it's final conference in Pretoria[^FinalConf] to showcase the work done - we have held three bootcamps so far, in collaboration with : + + - [GARR](http://www.garr.it)[^GARR] - The [first bootcamp in Catania ](http://agenda.ct.infn.it/event/1180/other-view?view=indico_infn_meeting) aimed at delivering federated identity providers and services in a federation. + - [eko-Konnect](http://www.eko-konnect.org)[^eko] - The [Lagos bootcamp](http://indico.wacren.net/event/25/) also focussed on orchestration of federated identity + - [UbuntuNet](http://www.ubuntnet.net)[^UbuntuNet] - The [Entebbe bootcamp](https://events.ubuntunet.net/indico/event/5/) focussed more on core skills such as working with code, and then hacked participant projects related to eduroam deployment in the Great Lakes region. + +Each bootcamp is a bit different, and participants get out of it what they put in. There is a short feedback period _before_ the event, where skill levels are assessed and interested parties are probed on what kind of projects they'll be bringing to the event. Over the course of two days, the basics are laid down and participants come away with a new set of skills and confidence in serving their scientific communities. + +# What we'll cover + +The scope of DevOps can be all-encompassing; just covering the toolsets exhaustively could take days. Instead of focussing on _all the tools_, we pick a few and then use it to demonstrate methodology. A short introduction, aimed at giving some context and peripheral vision to what we are doing is covered in the first session. We cover the practices of + + * Service modelling + * Testing + * Continuous Integration and Delivery + * Code review + * [Working Open](https://mozillascience.github.io/WOW-2017/) and aspects of [Community Health]() + +and put them into action. The bootcamp alternates between short presentations and implementation sessions, where participants code[^OrIndividuals]. + +## Tools + +> This is my rifle.
+> There are many like it, but this one is mine + (From [The Rifleman's Creed](https://en.wikipedia.org/wiki/Rifleman's_Creed)) + +It is impossible to give a comprehensive insight to tools. There are several, each purporting to solve various problems faced in a DevOps environment. But DevOps is not a tool, it is a culture. We use [Ansible](http://www.ansible.com) as the basic tool for the bootcamp because of it's simplicity, human-readable nature, agentless architecture and vast set of built-in modules. However, we will also need others for testing[^Testing], communication, automation, _etc_. + +The course also relies on [GitHub](https://github.com/) and assumes that participants have accounts on GitHub[^NoGithub]. The GitHub API will be used to manage repositories and access tokens, amongst other things, and the web interface is suggested for code reviews. + +We will also be relying on [Linux Containers](https://en.wikipedia.org/wiki/LXC), and in particular [Docker](http://docker.com/) for a development environment and some testing. [Ansible Container](https://docs.ansible.com/ansible-container) will be used as part of the toolkit. + +# Interested in attending ? + +If all this sounds like fun, then come to the DevOps Bootcamp at the CSIR Meraka Institute **30 - 31 March 2017**. The sessions are open to all, space-permitting. Further details (venue, registration, etc) will be posted soon. In the meantime, why not take a quick look at what you can do to get yourself ready. + +## Preparation + +> "Be prepared" + ([Scouts Motto](https://en.wikipedia.org/wiki/Scout_Motto)) + +The bootcamp makes no assumptions about the skill of the participants, so there are zero formal requirements for attending the course. Participants should however have a need to fulfill - a pet project, a service they are responsible for. + +Familiarity with certain basic tools and skills will certainly be a bonus. The best place to work is on your own personal computer, so you should have : + + * Linux[^Duh] + * bash or other shell + * git client (and optional IDE) + * a good editor + * [Docker Engine](https://store.docker.com/search?type=edition&offering=community) + +... and a whole lot of grit. + +
+ +

+

See you all at the bootcamp !

+
+

+ +---- + +# References and Footnotes + +[^FinalConf]: The Sci-GaIA User Forum and Final Conference - 23 and 24 March 2016. See [www.sci-gaia.eu/final-event](http://www.sci-gaia.eu/final-event). All welcome ! +[^GARR]: GARR is the Italian NREN +[^eko]: eko-Konnect is the Lagos cluster of the Nigerian NREN (ngREN) +[^UbuntuNet]: The UbuntuNet Alliance is a regional REN for East and Southern Africa. +[^OrIndividuals]: This is usually done in pairs, but depends on the number of participants and projects. +[^Testing]: Tests can be written with [ServerSpec](http://serverspec.org/) or [Test Kitchen](http://kitchen.ci). For continuous integration, we will use mainly [Travis](https://travis-ci.org) +[^NoGithub]: If you have some kind of religious intolerance of GitHub, I guess we can find a way to accommodate that ¯\_(ツ)_/¯ +[^Duh]: Duh. I haven't checked this bootcamp with the Windows Subsystem for Linux yet - any takers ? diff --git a/applications.md b/applications.md index e8770c9..5742df1 100644 --- a/applications.md +++ b/applications.md @@ -5,7 +5,7 @@ title: Supported Applications headline: What you can run on the grid tags: [glite, tutorial, basic, job submission, information system, authorisation, data management] image: - feature: + feature: burn.jpg --- # What can I run ? @@ -14,7 +14,14 @@ In order to execute applications, they need to be on the remote execution enviro ## Straight from our Jenkins to you -Our build system performs continuous integration on applications which are supported by the infrastructure, as well as user-proposed applications. Below you can find the overview of the status of these. These are executable in local-only or under the [sagrid.ac.za](https://voms.sagrid.ac.za/voms/sagrid.ac.za). +Our build system performs continuous integration on applications which are supported by the infrastructure, as well as user-proposed applications. Below you can find the overview of the status of these. These are executable in local-only or under the [sagrid.ac.za](https://voms.sagrid.ac.za/voms/sagrid.ac.za) VO. + + +---- + +

You can access these applications directly from your laptop, or cluster Find out how

+ +----
@@ -22,17 +29,45 @@ Our build system performs continuous integration on applications which are suppo
  • Compilers
  • Libraries
  • Frameworks
    • +
  • Python
    • +
  • Chemistry
    • +
  • Language
    • +
  • Requested
    • + +
    {% include compilers.html %} {% include libraries.html %} {% include frameworks.html %} - - +{% include python.html %} +{% include chemistry.html %} +{% include language.html %} +{% include requested.html %}
    +
    + + + + + + + + + + + + + + +
    Legend
    Published in CVMFS `apprepo` and modulefile available. Used at production sites and your milage wil be good :smile:
    Published in CVMFS `devrepo` - modulefile not guaranteed to be available, used for integration testing and early adopters. YMMV :smirk:
    Not published anywhere yet.
    + +

    Want to help or follow the development ? Check out our waffle ironing board

    +

    Don't see what you want ? - Propose a new application

    + ## How about something Continental ? Want something from another VO ? Our sites support several [EGI](https://wiki.egi.eu/wiki/CVMFS_Task_Force#Configurations) and [WLCG](https://wiki.egi.eu/wiki/CVMFS_Task_Force#Configurations) VOs (ATLAS and ALICE primarily.) diff --git a/assets/css/bootstrap.css b/assets/css/bootstrap.css index d5ae699..605e677 100644 --- a/assets/css/bootstrap.css +++ b/assets/css/bootstrap.css @@ -270,10 +270,11 @@ th { font-family: 'Glyphicons Halfling'; src: url('../fonts/glyphicons-halflings-regular.eot'); src: url('../fonts/glyphicons-halflings-regular.eot?#iefix') format('embedded-opentype'), url('../fonts/glyphicons-halflings-regular.woff') format('woff'), url('../fonts/glyphicons-halflings-regular.ttf') format('truetype'), url('../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular') format('svg'); - */ + font-family: 'FontAwesome'; src: url('../font/fontawesome-webfontf77b.eot'); - src: url('../font/fontawesome-webfontf77b.woff') format('woff'), url('../font/fontawesome-webfontf77b.ttf') format('truetype'), url('../fontawesome-webfont.svg') format('svg'); + src: url('../font/fontawesome-webfontf77b.woff') format('woff'), url('../font/fontawesome-webfontf77b.ttf') format('truetype'), url('../fontawesome-webfont.svg') format('svg'); */ + font-family: inherit; } .glyphicon { position: relative; @@ -3241,7 +3242,7 @@ tbody.collapse.in { .dropdown-menu > li > a:hover, .dropdown-menu > li > a:focus { color: #7DB900; - text-decoration: bold ; +/* text-decoration: bold ; */ /* background-color: #7DB900; */ visibility: visible; } @@ -5603,7 +5604,7 @@ button.close { position: absolute; z-index: 1070; display: block; - font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; + font-family: "Lato", Lato, Arial, sans-serif; font-size: 12px; font-weight: normal; line-height: 1.4; @@ -5711,7 +5712,7 @@ button.close { display: none; max-width: 276px; padding: 1px; - font-family: "Lato Thin"; + font-family: "Lato"; font-size: 14px; font-weight: normal; line-height: 1.42857143; diff --git a/assets/css/font-awesome.css b/assets/css/font-awesome.css index 4040b3c..846191b 100644 --- a/assets/css/font-awesome.css +++ b/assets/css/font-awesome.css @@ -1,13 +1,15 @@ /*! - * Font Awesome 4.2.0 by @davegandy - http://fontawesome.io - @fontawesome + * Font Awesome 4.3.0 by @davegandy - http://fontawesome.io - @fontawesome * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) */ /* FONT PATH * -------------------------- */ +@fa-font-path: "../font"; + @font-face { font-family: 'FontAwesome'; - src: url('../fonts/fontawesome-webfont.eot?v=4.2.0'); - src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg'); + src: url('../fonts/fontawesome-webfont.eot?v=4.3.0'); + src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.3.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff2?v=4.3.0') format('woff2'), url('../fonts/fontawesome-webfont.woff?v=4.3.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.3.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.3.0#fontawesomeregular') format('svg'); font-weight: normal; font-style: normal; } @@ -18,6 +20,7 @@ text-rendering: auto; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; + transform: translate(0, 0); } /* makes the font 33% larger relative to the icon container */ .fa-lg { @@ -80,6 +83,10 @@ -webkit-animation: fa-spin 2s infinite linear; animation: fa-spin 2s infinite linear; } +.fa-pulse { + -webkit-animation: fa-spin 1s infinite steps(8); + animation: fa-spin 1s infinite steps(8); +} @-webkit-keyframes fa-spin { 0% { -webkit-transform: rotate(0deg); @@ -610,6 +617,7 @@ .fa-twitter:before { content: "\f099"; } +.fa-facebook-f:before, .fa-facebook:before { content: "\f09a"; } @@ -1259,7 +1267,8 @@ .fa-male:before { content: "\f183"; } -.fa-gittip:before { +.fa-gittip:before, +.fa-gratipay:before { content: "\f184"; } .fa-sun-o:before { @@ -1526,6 +1535,7 @@ .fa-history:before { content: "\f1da"; } +.fa-genderless:before, .fa-circle-thin:before { content: "\f1db"; } @@ -1670,3 +1680,124 @@ .fa-meanpath:before { content: "\f20c"; } +.fa-buysellads:before { + content: "\f20d"; +} +.fa-connectdevelop:before { + content: "\f20e"; +} +.fa-dashcube:before { + content: "\f210"; +} +.fa-forumbee:before { + content: "\f211"; +} +.fa-leanpub:before { + content: "\f212"; +} +.fa-sellsy:before { + content: "\f213"; +} +.fa-shirtsinbulk:before { + content: "\f214"; +} +.fa-simplybuilt:before { + content: "\f215"; +} +.fa-skyatlas:before { + content: "\f216"; +} +.fa-cart-plus:before { + content: "\f217"; +} +.fa-cart-arrow-down:before { + content: "\f218"; +} +.fa-diamond:before { + content: "\f219"; +} +.fa-ship:before { + content: "\f21a"; +} +.fa-user-secret:before { + content: "\f21b"; +} +.fa-motorcycle:before { + content: "\f21c"; +} +.fa-street-view:before { + content: "\f21d"; +} +.fa-heartbeat:before { + content: "\f21e"; +} +.fa-venus:before { + content: "\f221"; +} +.fa-mars:before { + content: "\f222"; +} +.fa-mercury:before { + content: "\f223"; +} +.fa-transgender:before { + content: "\f224"; +} +.fa-transgender-alt:before { + content: "\f225"; +} +.fa-venus-double:before { + content: "\f226"; +} +.fa-mars-double:before { + content: "\f227"; +} +.fa-venus-mars:before { + content: "\f228"; +} +.fa-mars-stroke:before { + content: "\f229"; +} +.fa-mars-stroke-v:before { + content: "\f22a"; +} +.fa-mars-stroke-h:before { + content: "\f22b"; +} +.fa-neuter:before { + content: "\f22c"; +} +.fa-facebook-official:before { + content: "\f230"; +} +.fa-pinterest-p:before { + content: "\f231"; +} +.fa-whatsapp:before { + content: "\f232"; +} +.fa-server:before { + content: "\f233"; +} +.fa-user-plus:before { + content: "\f234"; +} +.fa-user-times:before { + content: "\f235"; +} +.fa-hotel:before, +.fa-bed:before { + content: "\f236"; +} +.fa-viacoin:before { + content: "\f237"; +} +.fa-train:before { + content: "\f238"; +} +.fa-subway:before { + content: "\f239"; +} +.fa-medium:before { + content: "\f23a"; +} diff --git a/assets/css/font-awesome.min.css b/assets/css/font-awesome.min.css index ec53d4d..24fcc04 100644 --- a/assets/css/font-awesome.min.css +++ b/assets/css/font-awesome.min.css @@ -1,4 +1,4 @@ /*! - * Font Awesome 4.2.0 by @davegandy - http://fontawesome.io - @fontawesome + * Font Awesome 4.3.0 by @davegandy - http://fontawesome.io - @fontawesome * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) - */@font-face{font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v=4.2.0');src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.2.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff?v=4.2.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.2.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.2.0#fontawesomeregular') format('svg');font-weight:normal;font-style:normal}.fa{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.fa-lg{font-size:1.33333333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571429em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14285714em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14285714em;width:2.14285714em;top:.14285714em;text-align:center}.fa-li.fa-lg{left:-1.85714286em}.fa-border{padding:.2em .25em .15em;border:solid .08em #eee;border-radius:.1em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left{margin-right:.3em}.fa.pull-right{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s infinite linear;animation:fa-spin 2s infinite linear}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1);-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2);-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=3);-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1);-webkit-transform:scale(-1, 1);-ms-transform:scale(-1, 1);transform:scale(-1, 1)}.fa-flip-vertical{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1);-webkit-transform:scale(1, -1);-ms-transform:scale(1, -1);transform:scale(1, -1)}:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270,:root .fa-flip-horizontal,:root .fa-flip-vertical{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:"\f000"}.fa-music:before{content:"\f001"}.fa-search:before{content:"\f002"}.fa-envelope-o:before{content:"\f003"}.fa-heart:before{content:"\f004"}.fa-star:before{content:"\f005"}.fa-star-o:before{content:"\f006"}.fa-user:before{content:"\f007"}.fa-film:before{content:"\f008"}.fa-th-large:before{content:"\f009"}.fa-th:before{content:"\f00a"}.fa-th-list:before{content:"\f00b"}.fa-check:before{content:"\f00c"}.fa-remove:before,.fa-close:before,.fa-times:before{content:"\f00d"}.fa-search-plus:before{content:"\f00e"}.fa-search-minus:before{content:"\f010"}.fa-power-off:before{content:"\f011"}.fa-signal:before{content:"\f012"}.fa-gear:before,.fa-cog:before{content:"\f013"}.fa-trash-o:before{content:"\f014"}.fa-home:before{content:"\f015"}.fa-file-o:before{content:"\f016"}.fa-clock-o:before{content:"\f017"}.fa-road:before{content:"\f018"}.fa-download:before{content:"\f019"}.fa-arrow-circle-o-down:before{content:"\f01a"}.fa-arrow-circle-o-up:before{content:"\f01b"}.fa-inbox:before{content:"\f01c"}.fa-play-circle-o:before{content:"\f01d"}.fa-rotate-right:before,.fa-repeat:before{content:"\f01e"}.fa-refresh:before{content:"\f021"}.fa-list-alt:before{content:"\f022"}.fa-lock:before{content:"\f023"}.fa-flag:before{content:"\f024"}.fa-headphones:before{content:"\f025"}.fa-volume-off:before{content:"\f026"}.fa-volume-down:before{content:"\f027"}.fa-volume-up:before{content:"\f028"}.fa-qrcode:before{content:"\f029"}.fa-barcode:before{content:"\f02a"}.fa-tag:before{content:"\f02b"}.fa-tags:before{content:"\f02c"}.fa-book:before{content:"\f02d"}.fa-bookmark:before{content:"\f02e"}.fa-print:before{content:"\f02f"}.fa-camera:before{content:"\f030"}.fa-font:before{content:"\f031"}.fa-bold:before{content:"\f032"}.fa-italic:before{content:"\f033"}.fa-text-height:before{content:"\f034"}.fa-text-width:before{content:"\f035"}.fa-align-left:before{content:"\f036"}.fa-align-center:before{content:"\f037"}.fa-align-right:before{content:"\f038"}.fa-align-justify:before{content:"\f039"}.fa-list:before{content:"\f03a"}.fa-dedent:before,.fa-outdent:before{content:"\f03b"}.fa-indent:before{content:"\f03c"}.fa-video-camera:before{content:"\f03d"}.fa-photo:before,.fa-image:before,.fa-picture-o:before{content:"\f03e"}.fa-pencil:before{content:"\f040"}.fa-map-marker:before{content:"\f041"}.fa-adjust:before{content:"\f042"}.fa-tint:before{content:"\f043"}.fa-edit:before,.fa-pencil-square-o:before{content:"\f044"}.fa-share-square-o:before{content:"\f045"}.fa-check-square-o:before{content:"\f046"}.fa-arrows:before{content:"\f047"}.fa-step-backward:before{content:"\f048"}.fa-fast-backward:before{content:"\f049"}.fa-backward:before{content:"\f04a"}.fa-play:before{content:"\f04b"}.fa-pause:before{content:"\f04c"}.fa-stop:before{content:"\f04d"}.fa-forward:before{content:"\f04e"}.fa-fast-forward:before{content:"\f050"}.fa-step-forward:before{content:"\f051"}.fa-eject:before{content:"\f052"}.fa-chevron-left:before{content:"\f053"}.fa-chevron-right:before{content:"\f054"}.fa-plus-circle:before{content:"\f055"}.fa-minus-circle:before{content:"\f056"}.fa-times-circle:before{content:"\f057"}.fa-check-circle:before{content:"\f058"}.fa-question-circle:before{content:"\f059"}.fa-info-circle:before{content:"\f05a"}.fa-crosshairs:before{content:"\f05b"}.fa-times-circle-o:before{content:"\f05c"}.fa-check-circle-o:before{content:"\f05d"}.fa-ban:before{content:"\f05e"}.fa-arrow-left:before{content:"\f060"}.fa-arrow-right:before{content:"\f061"}.fa-arrow-up:before{content:"\f062"}.fa-arrow-down:before{content:"\f063"}.fa-mail-forward:before,.fa-share:before{content:"\f064"}.fa-expand:before{content:"\f065"}.fa-compress:before{content:"\f066"}.fa-plus:before{content:"\f067"}.fa-minus:before{content:"\f068"}.fa-asterisk:before{content:"\f069"}.fa-exclamation-circle:before{content:"\f06a"}.fa-gift:before{content:"\f06b"}.fa-leaf:before{content:"\f06c"}.fa-fire:before{content:"\f06d"}.fa-eye:before{content:"\f06e"}.fa-eye-slash:before{content:"\f070"}.fa-warning:before,.fa-exclamation-triangle:before{content:"\f071"}.fa-plane:before{content:"\f072"}.fa-calendar:before{content:"\f073"}.fa-random:before{content:"\f074"}.fa-comment:before{content:"\f075"}.fa-magnet:before{content:"\f076"}.fa-chevron-up:before{content:"\f077"}.fa-chevron-down:before{content:"\f078"}.fa-retweet:before{content:"\f079"}.fa-shopping-cart:before{content:"\f07a"}.fa-folder:before{content:"\f07b"}.fa-folder-open:before{content:"\f07c"}.fa-arrows-v:before{content:"\f07d"}.fa-arrows-h:before{content:"\f07e"}.fa-bar-chart-o:before,.fa-bar-chart:before{content:"\f080"}.fa-twitter-square:before{content:"\f081"}.fa-facebook-square:before{content:"\f082"}.fa-camera-retro:before{content:"\f083"}.fa-key:before{content:"\f084"}.fa-gears:before,.fa-cogs:before{content:"\f085"}.fa-comments:before{content:"\f086"}.fa-thumbs-o-up:before{content:"\f087"}.fa-thumbs-o-down:before{content:"\f088"}.fa-star-half:before{content:"\f089"}.fa-heart-o:before{content:"\f08a"}.fa-sign-out:before{content:"\f08b"}.fa-linkedin-square:before{content:"\f08c"}.fa-thumb-tack:before{content:"\f08d"}.fa-external-link:before{content:"\f08e"}.fa-sign-in:before{content:"\f090"}.fa-trophy:before{content:"\f091"}.fa-github-square:before{content:"\f092"}.fa-upload:before{content:"\f093"}.fa-lemon-o:before{content:"\f094"}.fa-phone:before{content:"\f095"}.fa-square-o:before{content:"\f096"}.fa-bookmark-o:before{content:"\f097"}.fa-phone-square:before{content:"\f098"}.fa-twitter:before{content:"\f099"}.fa-facebook:before{content:"\f09a"}.fa-github:before{content:"\f09b"}.fa-unlock:before{content:"\f09c"}.fa-credit-card:before{content:"\f09d"}.fa-rss:before{content:"\f09e"}.fa-hdd-o:before{content:"\f0a0"}.fa-bullhorn:before{content:"\f0a1"}.fa-bell:before{content:"\f0f3"}.fa-certificate:before{content:"\f0a3"}.fa-hand-o-right:before{content:"\f0a4"}.fa-hand-o-left:before{content:"\f0a5"}.fa-hand-o-up:before{content:"\f0a6"}.fa-hand-o-down:before{content:"\f0a7"}.fa-arrow-circle-left:before{content:"\f0a8"}.fa-arrow-circle-right:before{content:"\f0a9"}.fa-arrow-circle-up:before{content:"\f0aa"}.fa-arrow-circle-down:before{content:"\f0ab"}.fa-globe:before{content:"\f0ac"}.fa-wrench:before{content:"\f0ad"}.fa-tasks:before{content:"\f0ae"}.fa-filter:before{content:"\f0b0"}.fa-briefcase:before{content:"\f0b1"}.fa-arrows-alt:before{content:"\f0b2"}.fa-group:before,.fa-users:before{content:"\f0c0"}.fa-chain:before,.fa-link:before{content:"\f0c1"}.fa-cloud:before{content:"\f0c2"}.fa-flask:before{content:"\f0c3"}.fa-cut:before,.fa-scissors:before{content:"\f0c4"}.fa-copy:before,.fa-files-o:before{content:"\f0c5"}.fa-paperclip:before{content:"\f0c6"}.fa-save:before,.fa-floppy-o:before{content:"\f0c7"}.fa-square:before{content:"\f0c8"}.fa-navicon:before,.fa-reorder:before,.fa-bars:before{content:"\f0c9"}.fa-list-ul:before{content:"\f0ca"}.fa-list-ol:before{content:"\f0cb"}.fa-strikethrough:before{content:"\f0cc"}.fa-underline:before{content:"\f0cd"}.fa-table:before{content:"\f0ce"}.fa-magic:before{content:"\f0d0"}.fa-truck:before{content:"\f0d1"}.fa-pinterest:before{content:"\f0d2"}.fa-pinterest-square:before{content:"\f0d3"}.fa-google-plus-square:before{content:"\f0d4"}.fa-google-plus:before{content:"\f0d5"}.fa-money:before{content:"\f0d6"}.fa-caret-down:before{content:"\f0d7"}.fa-caret-up:before{content:"\f0d8"}.fa-caret-left:before{content:"\f0d9"}.fa-caret-right:before{content:"\f0da"}.fa-columns:before{content:"\f0db"}.fa-unsorted:before,.fa-sort:before{content:"\f0dc"}.fa-sort-down:before,.fa-sort-desc:before{content:"\f0dd"}.fa-sort-up:before,.fa-sort-asc:before{content:"\f0de"}.fa-envelope:before{content:"\f0e0"}.fa-linkedin:before{content:"\f0e1"}.fa-rotate-left:before,.fa-undo:before{content:"\f0e2"}.fa-legal:before,.fa-gavel:before{content:"\f0e3"}.fa-dashboard:before,.fa-tachometer:before{content:"\f0e4"}.fa-comment-o:before{content:"\f0e5"}.fa-comments-o:before{content:"\f0e6"}.fa-flash:before,.fa-bolt:before{content:"\f0e7"}.fa-sitemap:before{content:"\f0e8"}.fa-umbrella:before{content:"\f0e9"}.fa-paste:before,.fa-clipboard:before{content:"\f0ea"}.fa-lightbulb-o:before{content:"\f0eb"}.fa-exchange:before{content:"\f0ec"}.fa-cloud-download:before{content:"\f0ed"}.fa-cloud-upload:before{content:"\f0ee"}.fa-user-md:before{content:"\f0f0"}.fa-stethoscope:before{content:"\f0f1"}.fa-suitcase:before{content:"\f0f2"}.fa-bell-o:before{content:"\f0a2"}.fa-coffee:before{content:"\f0f4"}.fa-cutlery:before{content:"\f0f5"}.fa-file-text-o:before{content:"\f0f6"}.fa-building-o:before{content:"\f0f7"}.fa-hospital-o:before{content:"\f0f8"}.fa-ambulance:before{content:"\f0f9"}.fa-medkit:before{content:"\f0fa"}.fa-fighter-jet:before{content:"\f0fb"}.fa-beer:before{content:"\f0fc"}.fa-h-square:before{content:"\f0fd"}.fa-plus-square:before{content:"\f0fe"}.fa-angle-double-left:before{content:"\f100"}.fa-angle-double-right:before{content:"\f101"}.fa-angle-double-up:before{content:"\f102"}.fa-angle-double-down:before{content:"\f103"}.fa-angle-left:before{content:"\f104"}.fa-angle-right:before{content:"\f105"}.fa-angle-up:before{content:"\f106"}.fa-angle-down:before{content:"\f107"}.fa-desktop:before{content:"\f108"}.fa-laptop:before{content:"\f109"}.fa-tablet:before{content:"\f10a"}.fa-mobile-phone:before,.fa-mobile:before{content:"\f10b"}.fa-circle-o:before{content:"\f10c"}.fa-quote-left:before{content:"\f10d"}.fa-quote-right:before{content:"\f10e"}.fa-spinner:before{content:"\f110"}.fa-circle:before{content:"\f111"}.fa-mail-reply:before,.fa-reply:before{content:"\f112"}.fa-github-alt:before{content:"\f113"}.fa-folder-o:before{content:"\f114"}.fa-folder-open-o:before{content:"\f115"}.fa-smile-o:before{content:"\f118"}.fa-frown-o:before{content:"\f119"}.fa-meh-o:before{content:"\f11a"}.fa-gamepad:before{content:"\f11b"}.fa-keyboard-o:before{content:"\f11c"}.fa-flag-o:before{content:"\f11d"}.fa-flag-checkered:before{content:"\f11e"}.fa-terminal:before{content:"\f120"}.fa-code:before{content:"\f121"}.fa-mail-reply-all:before,.fa-reply-all:before{content:"\f122"}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:"\f123"}.fa-location-arrow:before{content:"\f124"}.fa-crop:before{content:"\f125"}.fa-code-fork:before{content:"\f126"}.fa-unlink:before,.fa-chain-broken:before{content:"\f127"}.fa-question:before{content:"\f128"}.fa-info:before{content:"\f129"}.fa-exclamation:before{content:"\f12a"}.fa-superscript:before{content:"\f12b"}.fa-subscript:before{content:"\f12c"}.fa-eraser:before{content:"\f12d"}.fa-puzzle-piece:before{content:"\f12e"}.fa-microphone:before{content:"\f130"}.fa-microphone-slash:before{content:"\f131"}.fa-shield:before{content:"\f132"}.fa-calendar-o:before{content:"\f133"}.fa-fire-extinguisher:before{content:"\f134"}.fa-rocket:before{content:"\f135"}.fa-maxcdn:before{content:"\f136"}.fa-chevron-circle-left:before{content:"\f137"}.fa-chevron-circle-right:before{content:"\f138"}.fa-chevron-circle-up:before{content:"\f139"}.fa-chevron-circle-down:before{content:"\f13a"}.fa-html5:before{content:"\f13b"}.fa-css3:before{content:"\f13c"}.fa-anchor:before{content:"\f13d"}.fa-unlock-alt:before{content:"\f13e"}.fa-bullseye:before{content:"\f140"}.fa-ellipsis-h:before{content:"\f141"}.fa-ellipsis-v:before{content:"\f142"}.fa-rss-square:before{content:"\f143"}.fa-play-circle:before{content:"\f144"}.fa-ticket:before{content:"\f145"}.fa-minus-square:before{content:"\f146"}.fa-minus-square-o:before{content:"\f147"}.fa-level-up:before{content:"\f148"}.fa-level-down:before{content:"\f149"}.fa-check-square:before{content:"\f14a"}.fa-pencil-square:before{content:"\f14b"}.fa-external-link-square:before{content:"\f14c"}.fa-share-square:before{content:"\f14d"}.fa-compass:before{content:"\f14e"}.fa-toggle-down:before,.fa-caret-square-o-down:before{content:"\f150"}.fa-toggle-up:before,.fa-caret-square-o-up:before{content:"\f151"}.fa-toggle-right:before,.fa-caret-square-o-right:before{content:"\f152"}.fa-euro:before,.fa-eur:before{content:"\f153"}.fa-gbp:before{content:"\f154"}.fa-dollar:before,.fa-usd:before{content:"\f155"}.fa-rupee:before,.fa-inr:before{content:"\f156"}.fa-cny:before,.fa-rmb:before,.fa-yen:before,.fa-jpy:before{content:"\f157"}.fa-ruble:before,.fa-rouble:before,.fa-rub:before{content:"\f158"}.fa-won:before,.fa-krw:before{content:"\f159"}.fa-bitcoin:before,.fa-btc:before{content:"\f15a"}.fa-file:before{content:"\f15b"}.fa-file-text:before{content:"\f15c"}.fa-sort-alpha-asc:before{content:"\f15d"}.fa-sort-alpha-desc:before{content:"\f15e"}.fa-sort-amount-asc:before{content:"\f160"}.fa-sort-amount-desc:before{content:"\f161"}.fa-sort-numeric-asc:before{content:"\f162"}.fa-sort-numeric-desc:before{content:"\f163"}.fa-thumbs-up:before{content:"\f164"}.fa-thumbs-down:before{content:"\f165"}.fa-youtube-square:before{content:"\f166"}.fa-youtube:before{content:"\f167"}.fa-xing:before{content:"\f168"}.fa-xing-square:before{content:"\f169"}.fa-youtube-play:before{content:"\f16a"}.fa-dropbox:before{content:"\f16b"}.fa-stack-overflow:before{content:"\f16c"}.fa-instagram:before{content:"\f16d"}.fa-flickr:before{content:"\f16e"}.fa-adn:before{content:"\f170"}.fa-bitbucket:before{content:"\f171"}.fa-bitbucket-square:before{content:"\f172"}.fa-tumblr:before{content:"\f173"}.fa-tumblr-square:before{content:"\f174"}.fa-long-arrow-down:before{content:"\f175"}.fa-long-arrow-up:before{content:"\f176"}.fa-long-arrow-left:before{content:"\f177"}.fa-long-arrow-right:before{content:"\f178"}.fa-apple:before{content:"\f179"}.fa-windows:before{content:"\f17a"}.fa-android:before{content:"\f17b"}.fa-linux:before{content:"\f17c"}.fa-dribbble:before{content:"\f17d"}.fa-skype:before{content:"\f17e"}.fa-foursquare:before{content:"\f180"}.fa-trello:before{content:"\f181"}.fa-female:before{content:"\f182"}.fa-male:before{content:"\f183"}.fa-gittip:before{content:"\f184"}.fa-sun-o:before{content:"\f185"}.fa-moon-o:before{content:"\f186"}.fa-archive:before{content:"\f187"}.fa-bug:before{content:"\f188"}.fa-vk:before{content:"\f189"}.fa-weibo:before{content:"\f18a"}.fa-renren:before{content:"\f18b"}.fa-pagelines:before{content:"\f18c"}.fa-stack-exchange:before{content:"\f18d"}.fa-arrow-circle-o-right:before{content:"\f18e"}.fa-arrow-circle-o-left:before{content:"\f190"}.fa-toggle-left:before,.fa-caret-square-o-left:before{content:"\f191"}.fa-dot-circle-o:before{content:"\f192"}.fa-wheelchair:before{content:"\f193"}.fa-vimeo-square:before{content:"\f194"}.fa-turkish-lira:before,.fa-try:before{content:"\f195"}.fa-plus-square-o:before{content:"\f196"}.fa-space-shuttle:before{content:"\f197"}.fa-slack:before{content:"\f198"}.fa-envelope-square:before{content:"\f199"}.fa-wordpress:before{content:"\f19a"}.fa-openid:before{content:"\f19b"}.fa-institution:before,.fa-bank:before,.fa-university:before{content:"\f19c"}.fa-mortar-board:before,.fa-graduation-cap:before{content:"\f19d"}.fa-yahoo:before{content:"\f19e"}.fa-google:before{content:"\f1a0"}.fa-reddit:before{content:"\f1a1"}.fa-reddit-square:before{content:"\f1a2"}.fa-stumbleupon-circle:before{content:"\f1a3"}.fa-stumbleupon:before{content:"\f1a4"}.fa-delicious:before{content:"\f1a5"}.fa-digg:before{content:"\f1a6"}.fa-pied-piper:before{content:"\f1a7"}.fa-pied-piper-alt:before{content:"\f1a8"}.fa-drupal:before{content:"\f1a9"}.fa-joomla:before{content:"\f1aa"}.fa-language:before{content:"\f1ab"}.fa-fax:before{content:"\f1ac"}.fa-building:before{content:"\f1ad"}.fa-child:before{content:"\f1ae"}.fa-paw:before{content:"\f1b0"}.fa-spoon:before{content:"\f1b1"}.fa-cube:before{content:"\f1b2"}.fa-cubes:before{content:"\f1b3"}.fa-behance:before{content:"\f1b4"}.fa-behance-square:before{content:"\f1b5"}.fa-steam:before{content:"\f1b6"}.fa-steam-square:before{content:"\f1b7"}.fa-recycle:before{content:"\f1b8"}.fa-automobile:before,.fa-car:before{content:"\f1b9"}.fa-cab:before,.fa-taxi:before{content:"\f1ba"}.fa-tree:before{content:"\f1bb"}.fa-spotify:before{content:"\f1bc"}.fa-deviantart:before{content:"\f1bd"}.fa-soundcloud:before{content:"\f1be"}.fa-database:before{content:"\f1c0"}.fa-file-pdf-o:before{content:"\f1c1"}.fa-file-word-o:before{content:"\f1c2"}.fa-file-excel-o:before{content:"\f1c3"}.fa-file-powerpoint-o:before{content:"\f1c4"}.fa-file-photo-o:before,.fa-file-picture-o:before,.fa-file-image-o:before{content:"\f1c5"}.fa-file-zip-o:before,.fa-file-archive-o:before{content:"\f1c6"}.fa-file-sound-o:before,.fa-file-audio-o:before{content:"\f1c7"}.fa-file-movie-o:before,.fa-file-video-o:before{content:"\f1c8"}.fa-file-code-o:before{content:"\f1c9"}.fa-vine:before{content:"\f1ca"}.fa-codepen:before{content:"\f1cb"}.fa-jsfiddle:before{content:"\f1cc"}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-saver:before,.fa-support:before,.fa-life-ring:before{content:"\f1cd"}.fa-circle-o-notch:before{content:"\f1ce"}.fa-ra:before,.fa-rebel:before{content:"\f1d0"}.fa-ge:before,.fa-empire:before{content:"\f1d1"}.fa-git-square:before{content:"\f1d2"}.fa-git:before{content:"\f1d3"}.fa-hacker-news:before{content:"\f1d4"}.fa-tencent-weibo:before{content:"\f1d5"}.fa-qq:before{content:"\f1d6"}.fa-wechat:before,.fa-weixin:before{content:"\f1d7"}.fa-send:before,.fa-paper-plane:before{content:"\f1d8"}.fa-send-o:before,.fa-paper-plane-o:before{content:"\f1d9"}.fa-history:before{content:"\f1da"}.fa-circle-thin:before{content:"\f1db"}.fa-header:before{content:"\f1dc"}.fa-paragraph:before{content:"\f1dd"}.fa-sliders:before{content:"\f1de"}.fa-share-alt:before{content:"\f1e0"}.fa-share-alt-square:before{content:"\f1e1"}.fa-bomb:before{content:"\f1e2"}.fa-soccer-ball-o:before,.fa-futbol-o:before{content:"\f1e3"}.fa-tty:before{content:"\f1e4"}.fa-binoculars:before{content:"\f1e5"}.fa-plug:before{content:"\f1e6"}.fa-slideshare:before{content:"\f1e7"}.fa-twitch:before{content:"\f1e8"}.fa-yelp:before{content:"\f1e9"}.fa-newspaper-o:before{content:"\f1ea"}.fa-wifi:before{content:"\f1eb"}.fa-calculator:before{content:"\f1ec"}.fa-paypal:before{content:"\f1ed"}.fa-google-wallet:before{content:"\f1ee"}.fa-cc-visa:before{content:"\f1f0"}.fa-cc-mastercard:before{content:"\f1f1"}.fa-cc-discover:before{content:"\f1f2"}.fa-cc-amex:before{content:"\f1f3"}.fa-cc-paypal:before{content:"\f1f4"}.fa-cc-stripe:before{content:"\f1f5"}.fa-bell-slash:before{content:"\f1f6"}.fa-bell-slash-o:before{content:"\f1f7"}.fa-trash:before{content:"\f1f8"}.fa-copyright:before{content:"\f1f9"}.fa-at:before{content:"\f1fa"}.fa-eyedropper:before{content:"\f1fb"}.fa-paint-brush:before{content:"\f1fc"}.fa-birthday-cake:before{content:"\f1fd"}.fa-area-chart:before{content:"\f1fe"}.fa-pie-chart:before{content:"\f200"}.fa-line-chart:before{content:"\f201"}.fa-lastfm:before{content:"\f202"}.fa-lastfm-square:before{content:"\f203"}.fa-toggle-off:before{content:"\f204"}.fa-toggle-on:before{content:"\f205"}.fa-bicycle:before{content:"\f206"}.fa-bus:before{content:"\f207"}.fa-ioxhost:before{content:"\f208"}.fa-angellist:before{content:"\f209"}.fa-cc:before{content:"\f20a"}.fa-shekel:before,.fa-sheqel:before,.fa-ils:before{content:"\f20b"}.fa-meanpath:before{content:"\f20c"} \ No newline at end of file + */@font-face{font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v=4.3.0');src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.3.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff2?v=4.3.0') format('woff2'),url('../fonts/fontawesome-webfont.woff?v=4.3.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.3.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.3.0#fontawesomeregular') format('svg');font-weight:normal;font-style:normal}.fa{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;transform:translate(0, 0)}.fa-lg{font-size:1.33333333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571429em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14285714em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14285714em;width:2.14285714em;top:.14285714em;text-align:center}.fa-li.fa-lg{left:-1.85714286em}.fa-border{padding:.2em .25em .15em;border:solid .08em #eee;border-radius:.1em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left{margin-right:.3em}.fa.pull-right{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s infinite linear;animation:fa-spin 2s infinite linear}.fa-pulse{-webkit-animation:fa-spin 1s infinite steps(8);animation:fa-spin 1s infinite steps(8)}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1);-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2);-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=3);-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1);-webkit-transform:scale(-1, 1);-ms-transform:scale(-1, 1);transform:scale(-1, 1)}.fa-flip-vertical{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1);-webkit-transform:scale(1, -1);-ms-transform:scale(1, -1);transform:scale(1, -1)}:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270,:root .fa-flip-horizontal,:root .fa-flip-vertical{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:"\f000"}.fa-music:before{content:"\f001"}.fa-search:before{content:"\f002"}.fa-envelope-o:before{content:"\f003"}.fa-heart:before{content:"\f004"}.fa-star:before{content:"\f005"}.fa-star-o:before{content:"\f006"}.fa-user:before{content:"\f007"}.fa-film:before{content:"\f008"}.fa-th-large:before{content:"\f009"}.fa-th:before{content:"\f00a"}.fa-th-list:before{content:"\f00b"}.fa-check:before{content:"\f00c"}.fa-remove:before,.fa-close:before,.fa-times:before{content:"\f00d"}.fa-search-plus:before{content:"\f00e"}.fa-search-minus:before{content:"\f010"}.fa-power-off:before{content:"\f011"}.fa-signal:before{content:"\f012"}.fa-gear:before,.fa-cog:before{content:"\f013"}.fa-trash-o:before{content:"\f014"}.fa-home:before{content:"\f015"}.fa-file-o:before{content:"\f016"}.fa-clock-o:before{content:"\f017"}.fa-road:before{content:"\f018"}.fa-download:before{content:"\f019"}.fa-arrow-circle-o-down:before{content:"\f01a"}.fa-arrow-circle-o-up:before{content:"\f01b"}.fa-inbox:before{content:"\f01c"}.fa-play-circle-o:before{content:"\f01d"}.fa-rotate-right:before,.fa-repeat:before{content:"\f01e"}.fa-refresh:before{content:"\f021"}.fa-list-alt:before{content:"\f022"}.fa-lock:before{content:"\f023"}.fa-flag:before{content:"\f024"}.fa-headphones:before{content:"\f025"}.fa-volume-off:before{content:"\f026"}.fa-volume-down:before{content:"\f027"}.fa-volume-up:before{content:"\f028"}.fa-qrcode:before{content:"\f029"}.fa-barcode:before{content:"\f02a"}.fa-tag:before{content:"\f02b"}.fa-tags:before{content:"\f02c"}.fa-book:before{content:"\f02d"}.fa-bookmark:before{content:"\f02e"}.fa-print:before{content:"\f02f"}.fa-camera:before{content:"\f030"}.fa-font:before{content:"\f031"}.fa-bold:before{content:"\f032"}.fa-italic:before{content:"\f033"}.fa-text-height:before{content:"\f034"}.fa-text-width:before{content:"\f035"}.fa-align-left:before{content:"\f036"}.fa-align-center:before{content:"\f037"}.fa-align-right:before{content:"\f038"}.fa-align-justify:before{content:"\f039"}.fa-list:before{content:"\f03a"}.fa-dedent:before,.fa-outdent:before{content:"\f03b"}.fa-indent:before{content:"\f03c"}.fa-video-camera:before{content:"\f03d"}.fa-photo:before,.fa-image:before,.fa-picture-o:before{content:"\f03e"}.fa-pencil:before{content:"\f040"}.fa-map-marker:before{content:"\f041"}.fa-adjust:before{content:"\f042"}.fa-tint:before{content:"\f043"}.fa-edit:before,.fa-pencil-square-o:before{content:"\f044"}.fa-share-square-o:before{content:"\f045"}.fa-check-square-o:before{content:"\f046"}.fa-arrows:before{content:"\f047"}.fa-step-backward:before{content:"\f048"}.fa-fast-backward:before{content:"\f049"}.fa-backward:before{content:"\f04a"}.fa-play:before{content:"\f04b"}.fa-pause:before{content:"\f04c"}.fa-stop:before{content:"\f04d"}.fa-forward:before{content:"\f04e"}.fa-fast-forward:before{content:"\f050"}.fa-step-forward:before{content:"\f051"}.fa-eject:before{content:"\f052"}.fa-chevron-left:before{content:"\f053"}.fa-chevron-right:before{content:"\f054"}.fa-plus-circle:before{content:"\f055"}.fa-minus-circle:before{content:"\f056"}.fa-times-circle:before{content:"\f057"}.fa-check-circle:before{content:"\f058"}.fa-question-circle:before{content:"\f059"}.fa-info-circle:before{content:"\f05a"}.fa-crosshairs:before{content:"\f05b"}.fa-times-circle-o:before{content:"\f05c"}.fa-check-circle-o:before{content:"\f05d"}.fa-ban:before{content:"\f05e"}.fa-arrow-left:before{content:"\f060"}.fa-arrow-right:before{content:"\f061"}.fa-arrow-up:before{content:"\f062"}.fa-arrow-down:before{content:"\f063"}.fa-mail-forward:before,.fa-share:before{content:"\f064"}.fa-expand:before{content:"\f065"}.fa-compress:before{content:"\f066"}.fa-plus:before{content:"\f067"}.fa-minus:before{content:"\f068"}.fa-asterisk:before{content:"\f069"}.fa-exclamation-circle:before{content:"\f06a"}.fa-gift:before{content:"\f06b"}.fa-leaf:before{content:"\f06c"}.fa-fire:before{content:"\f06d"}.fa-eye:before{content:"\f06e"}.fa-eye-slash:before{content:"\f070"}.fa-warning:before,.fa-exclamation-triangle:before{content:"\f071"}.fa-plane:before{content:"\f072"}.fa-calendar:before{content:"\f073"}.fa-random:before{content:"\f074"}.fa-comment:before{content:"\f075"}.fa-magnet:before{content:"\f076"}.fa-chevron-up:before{content:"\f077"}.fa-chevron-down:before{content:"\f078"}.fa-retweet:before{content:"\f079"}.fa-shopping-cart:before{content:"\f07a"}.fa-folder:before{content:"\f07b"}.fa-folder-open:before{content:"\f07c"}.fa-arrows-v:before{content:"\f07d"}.fa-arrows-h:before{content:"\f07e"}.fa-bar-chart-o:before,.fa-bar-chart:before{content:"\f080"}.fa-twitter-square:before{content:"\f081"}.fa-facebook-square:before{content:"\f082"}.fa-camera-retro:before{content:"\f083"}.fa-key:before{content:"\f084"}.fa-gears:before,.fa-cogs:before{content:"\f085"}.fa-comments:before{content:"\f086"}.fa-thumbs-o-up:before{content:"\f087"}.fa-thumbs-o-down:before{content:"\f088"}.fa-star-half:before{content:"\f089"}.fa-heart-o:before{content:"\f08a"}.fa-sign-out:before{content:"\f08b"}.fa-linkedin-square:before{content:"\f08c"}.fa-thumb-tack:before{content:"\f08d"}.fa-external-link:before{content:"\f08e"}.fa-sign-in:before{content:"\f090"}.fa-trophy:before{content:"\f091"}.fa-github-square:before{content:"\f092"}.fa-upload:before{content:"\f093"}.fa-lemon-o:before{content:"\f094"}.fa-phone:before{content:"\f095"}.fa-square-o:before{content:"\f096"}.fa-bookmark-o:before{content:"\f097"}.fa-phone-square:before{content:"\f098"}.fa-twitter:before{content:"\f099"}.fa-facebook-f:before,.fa-facebook:before{content:"\f09a"}.fa-github:before{content:"\f09b"}.fa-unlock:before{content:"\f09c"}.fa-credit-card:before{content:"\f09d"}.fa-rss:before{content:"\f09e"}.fa-hdd-o:before{content:"\f0a0"}.fa-bullhorn:before{content:"\f0a1"}.fa-bell:before{content:"\f0f3"}.fa-certificate:before{content:"\f0a3"}.fa-hand-o-right:before{content:"\f0a4"}.fa-hand-o-left:before{content:"\f0a5"}.fa-hand-o-up:before{content:"\f0a6"}.fa-hand-o-down:before{content:"\f0a7"}.fa-arrow-circle-left:before{content:"\f0a8"}.fa-arrow-circle-right:before{content:"\f0a9"}.fa-arrow-circle-up:before{content:"\f0aa"}.fa-arrow-circle-down:before{content:"\f0ab"}.fa-globe:before{content:"\f0ac"}.fa-wrench:before{content:"\f0ad"}.fa-tasks:before{content:"\f0ae"}.fa-filter:before{content:"\f0b0"}.fa-briefcase:before{content:"\f0b1"}.fa-arrows-alt:before{content:"\f0b2"}.fa-group:before,.fa-users:before{content:"\f0c0"}.fa-chain:before,.fa-link:before{content:"\f0c1"}.fa-cloud:before{content:"\f0c2"}.fa-flask:before{content:"\f0c3"}.fa-cut:before,.fa-scissors:before{content:"\f0c4"}.fa-copy:before,.fa-files-o:before{content:"\f0c5"}.fa-paperclip:before{content:"\f0c6"}.fa-save:before,.fa-floppy-o:before{content:"\f0c7"}.fa-square:before{content:"\f0c8"}.fa-navicon:before,.fa-reorder:before,.fa-bars:before{content:"\f0c9"}.fa-list-ul:before{content:"\f0ca"}.fa-list-ol:before{content:"\f0cb"}.fa-strikethrough:before{content:"\f0cc"}.fa-underline:before{content:"\f0cd"}.fa-table:before{content:"\f0ce"}.fa-magic:before{content:"\f0d0"}.fa-truck:before{content:"\f0d1"}.fa-pinterest:before{content:"\f0d2"}.fa-pinterest-square:before{content:"\f0d3"}.fa-google-plus-square:before{content:"\f0d4"}.fa-google-plus:before{content:"\f0d5"}.fa-money:before{content:"\f0d6"}.fa-caret-down:before{content:"\f0d7"}.fa-caret-up:before{content:"\f0d8"}.fa-caret-left:before{content:"\f0d9"}.fa-caret-right:before{content:"\f0da"}.fa-columns:before{content:"\f0db"}.fa-unsorted:before,.fa-sort:before{content:"\f0dc"}.fa-sort-down:before,.fa-sort-desc:before{content:"\f0dd"}.fa-sort-up:before,.fa-sort-asc:before{content:"\f0de"}.fa-envelope:before{content:"\f0e0"}.fa-linkedin:before{content:"\f0e1"}.fa-rotate-left:before,.fa-undo:before{content:"\f0e2"}.fa-legal:before,.fa-gavel:before{content:"\f0e3"}.fa-dashboard:before,.fa-tachometer:before{content:"\f0e4"}.fa-comment-o:before{content:"\f0e5"}.fa-comments-o:before{content:"\f0e6"}.fa-flash:before,.fa-bolt:before{content:"\f0e7"}.fa-sitemap:before{content:"\f0e8"}.fa-umbrella:before{content:"\f0e9"}.fa-paste:before,.fa-clipboard:before{content:"\f0ea"}.fa-lightbulb-o:before{content:"\f0eb"}.fa-exchange:before{content:"\f0ec"}.fa-cloud-download:before{content:"\f0ed"}.fa-cloud-upload:before{content:"\f0ee"}.fa-user-md:before{content:"\f0f0"}.fa-stethoscope:before{content:"\f0f1"}.fa-suitcase:before{content:"\f0f2"}.fa-bell-o:before{content:"\f0a2"}.fa-coffee:before{content:"\f0f4"}.fa-cutlery:before{content:"\f0f5"}.fa-file-text-o:before{content:"\f0f6"}.fa-building-o:before{content:"\f0f7"}.fa-hospital-o:before{content:"\f0f8"}.fa-ambulance:before{content:"\f0f9"}.fa-medkit:before{content:"\f0fa"}.fa-fighter-jet:before{content:"\f0fb"}.fa-beer:before{content:"\f0fc"}.fa-h-square:before{content:"\f0fd"}.fa-plus-square:before{content:"\f0fe"}.fa-angle-double-left:before{content:"\f100"}.fa-angle-double-right:before{content:"\f101"}.fa-angle-double-up:before{content:"\f102"}.fa-angle-double-down:before{content:"\f103"}.fa-angle-left:before{content:"\f104"}.fa-angle-right:before{content:"\f105"}.fa-angle-up:before{content:"\f106"}.fa-angle-down:before{content:"\f107"}.fa-desktop:before{content:"\f108"}.fa-laptop:before{content:"\f109"}.fa-tablet:before{content:"\f10a"}.fa-mobile-phone:before,.fa-mobile:before{content:"\f10b"}.fa-circle-o:before{content:"\f10c"}.fa-quote-left:before{content:"\f10d"}.fa-quote-right:before{content:"\f10e"}.fa-spinner:before{content:"\f110"}.fa-circle:before{content:"\f111"}.fa-mail-reply:before,.fa-reply:before{content:"\f112"}.fa-github-alt:before{content:"\f113"}.fa-folder-o:before{content:"\f114"}.fa-folder-open-o:before{content:"\f115"}.fa-smile-o:before{content:"\f118"}.fa-frown-o:before{content:"\f119"}.fa-meh-o:before{content:"\f11a"}.fa-gamepad:before{content:"\f11b"}.fa-keyboard-o:before{content:"\f11c"}.fa-flag-o:before{content:"\f11d"}.fa-flag-checkered:before{content:"\f11e"}.fa-terminal:before{content:"\f120"}.fa-code:before{content:"\f121"}.fa-mail-reply-all:before,.fa-reply-all:before{content:"\f122"}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:"\f123"}.fa-location-arrow:before{content:"\f124"}.fa-crop:before{content:"\f125"}.fa-code-fork:before{content:"\f126"}.fa-unlink:before,.fa-chain-broken:before{content:"\f127"}.fa-question:before{content:"\f128"}.fa-info:before{content:"\f129"}.fa-exclamation:before{content:"\f12a"}.fa-superscript:before{content:"\f12b"}.fa-subscript:before{content:"\f12c"}.fa-eraser:before{content:"\f12d"}.fa-puzzle-piece:before{content:"\f12e"}.fa-microphone:before{content:"\f130"}.fa-microphone-slash:before{content:"\f131"}.fa-shield:before{content:"\f132"}.fa-calendar-o:before{content:"\f133"}.fa-fire-extinguisher:before{content:"\f134"}.fa-rocket:before{content:"\f135"}.fa-maxcdn:before{content:"\f136"}.fa-chevron-circle-left:before{content:"\f137"}.fa-chevron-circle-right:before{content:"\f138"}.fa-chevron-circle-up:before{content:"\f139"}.fa-chevron-circle-down:before{content:"\f13a"}.fa-html5:before{content:"\f13b"}.fa-css3:before{content:"\f13c"}.fa-anchor:before{content:"\f13d"}.fa-unlock-alt:before{content:"\f13e"}.fa-bullseye:before{content:"\f140"}.fa-ellipsis-h:before{content:"\f141"}.fa-ellipsis-v:before{content:"\f142"}.fa-rss-square:before{content:"\f143"}.fa-play-circle:before{content:"\f144"}.fa-ticket:before{content:"\f145"}.fa-minus-square:before{content:"\f146"}.fa-minus-square-o:before{content:"\f147"}.fa-level-up:before{content:"\f148"}.fa-level-down:before{content:"\f149"}.fa-check-square:before{content:"\f14a"}.fa-pencil-square:before{content:"\f14b"}.fa-external-link-square:before{content:"\f14c"}.fa-share-square:before{content:"\f14d"}.fa-compass:before{content:"\f14e"}.fa-toggle-down:before,.fa-caret-square-o-down:before{content:"\f150"}.fa-toggle-up:before,.fa-caret-square-o-up:before{content:"\f151"}.fa-toggle-right:before,.fa-caret-square-o-right:before{content:"\f152"}.fa-euro:before,.fa-eur:before{content:"\f153"}.fa-gbp:before{content:"\f154"}.fa-dollar:before,.fa-usd:before{content:"\f155"}.fa-rupee:before,.fa-inr:before{content:"\f156"}.fa-cny:before,.fa-rmb:before,.fa-yen:before,.fa-jpy:before{content:"\f157"}.fa-ruble:before,.fa-rouble:before,.fa-rub:before{content:"\f158"}.fa-won:before,.fa-krw:before{content:"\f159"}.fa-bitcoin:before,.fa-btc:before{content:"\f15a"}.fa-file:before{content:"\f15b"}.fa-file-text:before{content:"\f15c"}.fa-sort-alpha-asc:before{content:"\f15d"}.fa-sort-alpha-desc:before{content:"\f15e"}.fa-sort-amount-asc:before{content:"\f160"}.fa-sort-amount-desc:before{content:"\f161"}.fa-sort-numeric-asc:before{content:"\f162"}.fa-sort-numeric-desc:before{content:"\f163"}.fa-thumbs-up:before{content:"\f164"}.fa-thumbs-down:before{content:"\f165"}.fa-youtube-square:before{content:"\f166"}.fa-youtube:before{content:"\f167"}.fa-xing:before{content:"\f168"}.fa-xing-square:before{content:"\f169"}.fa-youtube-play:before{content:"\f16a"}.fa-dropbox:before{content:"\f16b"}.fa-stack-overflow:before{content:"\f16c"}.fa-instagram:before{content:"\f16d"}.fa-flickr:before{content:"\f16e"}.fa-adn:before{content:"\f170"}.fa-bitbucket:before{content:"\f171"}.fa-bitbucket-square:before{content:"\f172"}.fa-tumblr:before{content:"\f173"}.fa-tumblr-square:before{content:"\f174"}.fa-long-arrow-down:before{content:"\f175"}.fa-long-arrow-up:before{content:"\f176"}.fa-long-arrow-left:before{content:"\f177"}.fa-long-arrow-right:before{content:"\f178"}.fa-apple:before{content:"\f179"}.fa-windows:before{content:"\f17a"}.fa-android:before{content:"\f17b"}.fa-linux:before{content:"\f17c"}.fa-dribbble:before{content:"\f17d"}.fa-skype:before{content:"\f17e"}.fa-foursquare:before{content:"\f180"}.fa-trello:before{content:"\f181"}.fa-female:before{content:"\f182"}.fa-male:before{content:"\f183"}.fa-gittip:before,.fa-gratipay:before{content:"\f184"}.fa-sun-o:before{content:"\f185"}.fa-moon-o:before{content:"\f186"}.fa-archive:before{content:"\f187"}.fa-bug:before{content:"\f188"}.fa-vk:before{content:"\f189"}.fa-weibo:before{content:"\f18a"}.fa-renren:before{content:"\f18b"}.fa-pagelines:before{content:"\f18c"}.fa-stack-exchange:before{content:"\f18d"}.fa-arrow-circle-o-right:before{content:"\f18e"}.fa-arrow-circle-o-left:before{content:"\f190"}.fa-toggle-left:before,.fa-caret-square-o-left:before{content:"\f191"}.fa-dot-circle-o:before{content:"\f192"}.fa-wheelchair:before{content:"\f193"}.fa-vimeo-square:before{content:"\f194"}.fa-turkish-lira:before,.fa-try:before{content:"\f195"}.fa-plus-square-o:before{content:"\f196"}.fa-space-shuttle:before{content:"\f197"}.fa-slack:before{content:"\f198"}.fa-envelope-square:before{content:"\f199"}.fa-wordpress:before{content:"\f19a"}.fa-openid:before{content:"\f19b"}.fa-institution:before,.fa-bank:before,.fa-university:before{content:"\f19c"}.fa-mortar-board:before,.fa-graduation-cap:before{content:"\f19d"}.fa-yahoo:before{content:"\f19e"}.fa-google:before{content:"\f1a0"}.fa-reddit:before{content:"\f1a1"}.fa-reddit-square:before{content:"\f1a2"}.fa-stumbleupon-circle:before{content:"\f1a3"}.fa-stumbleupon:before{content:"\f1a4"}.fa-delicious:before{content:"\f1a5"}.fa-digg:before{content:"\f1a6"}.fa-pied-piper:before{content:"\f1a7"}.fa-pied-piper-alt:before{content:"\f1a8"}.fa-drupal:before{content:"\f1a9"}.fa-joomla:before{content:"\f1aa"}.fa-language:before{content:"\f1ab"}.fa-fax:before{content:"\f1ac"}.fa-building:before{content:"\f1ad"}.fa-child:before{content:"\f1ae"}.fa-paw:before{content:"\f1b0"}.fa-spoon:before{content:"\f1b1"}.fa-cube:before{content:"\f1b2"}.fa-cubes:before{content:"\f1b3"}.fa-behance:before{content:"\f1b4"}.fa-behance-square:before{content:"\f1b5"}.fa-steam:before{content:"\f1b6"}.fa-steam-square:before{content:"\f1b7"}.fa-recycle:before{content:"\f1b8"}.fa-automobile:before,.fa-car:before{content:"\f1b9"}.fa-cab:before,.fa-taxi:before{content:"\f1ba"}.fa-tree:before{content:"\f1bb"}.fa-spotify:before{content:"\f1bc"}.fa-deviantart:before{content:"\f1bd"}.fa-soundcloud:before{content:"\f1be"}.fa-database:before{content:"\f1c0"}.fa-file-pdf-o:before{content:"\f1c1"}.fa-file-word-o:before{content:"\f1c2"}.fa-file-excel-o:before{content:"\f1c3"}.fa-file-powerpoint-o:before{content:"\f1c4"}.fa-file-photo-o:before,.fa-file-picture-o:before,.fa-file-image-o:before{content:"\f1c5"}.fa-file-zip-o:before,.fa-file-archive-o:before{content:"\f1c6"}.fa-file-sound-o:before,.fa-file-audio-o:before{content:"\f1c7"}.fa-file-movie-o:before,.fa-file-video-o:before{content:"\f1c8"}.fa-file-code-o:before{content:"\f1c9"}.fa-vine:before{content:"\f1ca"}.fa-codepen:before{content:"\f1cb"}.fa-jsfiddle:before{content:"\f1cc"}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-saver:before,.fa-support:before,.fa-life-ring:before{content:"\f1cd"}.fa-circle-o-notch:before{content:"\f1ce"}.fa-ra:before,.fa-rebel:before{content:"\f1d0"}.fa-ge:before,.fa-empire:before{content:"\f1d1"}.fa-git-square:before{content:"\f1d2"}.fa-git:before{content:"\f1d3"}.fa-hacker-news:before{content:"\f1d4"}.fa-tencent-weibo:before{content:"\f1d5"}.fa-qq:before{content:"\f1d6"}.fa-wechat:before,.fa-weixin:before{content:"\f1d7"}.fa-send:before,.fa-paper-plane:before{content:"\f1d8"}.fa-send-o:before,.fa-paper-plane-o:before{content:"\f1d9"}.fa-history:before{content:"\f1da"}.fa-genderless:before,.fa-circle-thin:before{content:"\f1db"}.fa-header:before{content:"\f1dc"}.fa-paragraph:before{content:"\f1dd"}.fa-sliders:before{content:"\f1de"}.fa-share-alt:before{content:"\f1e0"}.fa-share-alt-square:before{content:"\f1e1"}.fa-bomb:before{content:"\f1e2"}.fa-soccer-ball-o:before,.fa-futbol-o:before{content:"\f1e3"}.fa-tty:before{content:"\f1e4"}.fa-binoculars:before{content:"\f1e5"}.fa-plug:before{content:"\f1e6"}.fa-slideshare:before{content:"\f1e7"}.fa-twitch:before{content:"\f1e8"}.fa-yelp:before{content:"\f1e9"}.fa-newspaper-o:before{content:"\f1ea"}.fa-wifi:before{content:"\f1eb"}.fa-calculator:before{content:"\f1ec"}.fa-paypal:before{content:"\f1ed"}.fa-google-wallet:before{content:"\f1ee"}.fa-cc-visa:before{content:"\f1f0"}.fa-cc-mastercard:before{content:"\f1f1"}.fa-cc-discover:before{content:"\f1f2"}.fa-cc-amex:before{content:"\f1f3"}.fa-cc-paypal:before{content:"\f1f4"}.fa-cc-stripe:before{content:"\f1f5"}.fa-bell-slash:before{content:"\f1f6"}.fa-bell-slash-o:before{content:"\f1f7"}.fa-trash:before{content:"\f1f8"}.fa-copyright:before{content:"\f1f9"}.fa-at:before{content:"\f1fa"}.fa-eyedropper:before{content:"\f1fb"}.fa-paint-brush:before{content:"\f1fc"}.fa-birthday-cake:before{content:"\f1fd"}.fa-area-chart:before{content:"\f1fe"}.fa-pie-chart:before{content:"\f200"}.fa-line-chart:before{content:"\f201"}.fa-lastfm:before{content:"\f202"}.fa-lastfm-square:before{content:"\f203"}.fa-toggle-off:before{content:"\f204"}.fa-toggle-on:before{content:"\f205"}.fa-bicycle:before{content:"\f206"}.fa-bus:before{content:"\f207"}.fa-ioxhost:before{content:"\f208"}.fa-angellist:before{content:"\f209"}.fa-cc:before{content:"\f20a"}.fa-shekel:before,.fa-sheqel:before,.fa-ils:before{content:"\f20b"}.fa-meanpath:before{content:"\f20c"}.fa-buysellads:before{content:"\f20d"}.fa-connectdevelop:before{content:"\f20e"}.fa-dashcube:before{content:"\f210"}.fa-forumbee:before{content:"\f211"}.fa-leanpub:before{content:"\f212"}.fa-sellsy:before{content:"\f213"}.fa-shirtsinbulk:before{content:"\f214"}.fa-simplybuilt:before{content:"\f215"}.fa-skyatlas:before{content:"\f216"}.fa-cart-plus:before{content:"\f217"}.fa-cart-arrow-down:before{content:"\f218"}.fa-diamond:before{content:"\f219"}.fa-ship:before{content:"\f21a"}.fa-user-secret:before{content:"\f21b"}.fa-motorcycle:before{content:"\f21c"}.fa-street-view:before{content:"\f21d"}.fa-heartbeat:before{content:"\f21e"}.fa-venus:before{content:"\f221"}.fa-mars:before{content:"\f222"}.fa-mercury:before{content:"\f223"}.fa-transgender:before{content:"\f224"}.fa-transgender-alt:before{content:"\f225"}.fa-venus-double:before{content:"\f226"}.fa-mars-double:before{content:"\f227"}.fa-venus-mars:before{content:"\f228"}.fa-mars-stroke:before{content:"\f229"}.fa-mars-stroke-v:before{content:"\f22a"}.fa-mars-stroke-h:before{content:"\f22b"}.fa-neuter:before{content:"\f22c"}.fa-facebook-official:before{content:"\f230"}.fa-pinterest-p:before{content:"\f231"}.fa-whatsapp:before{content:"\f232"}.fa-server:before{content:"\f233"}.fa-user-plus:before{content:"\f234"}.fa-user-times:before{content:"\f235"}.fa-hotel:before,.fa-bed:before{content:"\f236"}.fa-viacoin:before{content:"\f237"}.fa-train:before{content:"\f238"}.fa-subway:before{content:"\f239"}.fa-medium:before{content:"\f23a"} \ No newline at end of file diff --git a/assets/css/style.css b/assets/css/style.css index e94844a..c3c62fd 100644 --- a/assets/css/style.css +++ b/assets/css/style.css @@ -7,6 +7,7 @@ * * Designed and built with all the love in the world by @hmfaysal */ + @import url(http://weloveiconfonts.com/api/?family=brandico|entypo); /* ------------------------ */ /* GENERAL TYPOGRAPHY RULES */ /* ------------------------ */ @@ -531,7 +532,7 @@ html { padding-top: 12px; margin-top: 12px; font-size: 18px; - font-family: 'Roboto' sans-serif; + font-family: 'Inconsolata' sans-serif; } #main { position: relative; @@ -548,7 +549,7 @@ html { .blog-description { display: none; } - .home-template .row {margin: 0 -5px; z-index: 1} /* fixes overflow on homepage on small screens (caused by stacked -15px from bootstrap) */ + .home-template .row {margin: 0 -5px;} /* fixes overflow on homepage on small screens (caused by stacked -15px from bootstrap) */ } /* ----------- */ /* POST STYLES */ @@ -1844,7 +1845,7 @@ img.mfp-img { } tt,code,kbd,samp,pre { - font-family: 'source-code-pro',monospace; + font-family: 'Inconsolata',monospace; } p code,li code { diff --git a/assets/font/fontawesome-webfont.svg b/assets/font/fontawesome-webfont.svg deleted file mode 100644 index 2edb4ec..0000000 --- a/assets/font/fontawesome-webfont.svg +++ /dev/null @@ -1,399 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/assets/font/fontawesome-webfontd41d.eot b/assets/font/fontawesome-webfontd41d.eot deleted file mode 100644 index 0662cb9..0000000 Binary files a/assets/font/fontawesome-webfontd41d.eot and /dev/null differ diff --git a/assets/font/fontawesome-webfontf77b.eot b/assets/font/fontawesome-webfontf77b.eot deleted file mode 100644 index 0662cb9..0000000 Binary files a/assets/font/fontawesome-webfontf77b.eot and /dev/null differ diff --git a/assets/font/fontawesome-webfontf77b.ttf b/assets/font/fontawesome-webfontf77b.ttf deleted file mode 100644 index d365924..0000000 Binary files a/assets/font/fontawesome-webfontf77b.ttf and /dev/null differ diff --git a/assets/font/fontawesome-webfontf77b.woff b/assets/font/fontawesome-webfontf77b.woff deleted file mode 100644 index b9bd17e..0000000 Binary files a/assets/font/fontawesome-webfontf77b.woff and /dev/null differ diff --git a/assets/fonts/FontAwesome.otf b/assets/fonts/FontAwesome.otf index 81c9ad9..f7936cc 100644 Binary files a/assets/fonts/FontAwesome.otf and b/assets/fonts/FontAwesome.otf differ diff --git a/assets/fonts/fontawesome-webfont.eot b/assets/fonts/fontawesome-webfont.eot index 84677bc..33b2bb8 100644 Binary files a/assets/fonts/fontawesome-webfont.eot and b/assets/fonts/fontawesome-webfont.eot differ diff --git a/assets/fonts/fontawesome-webfont.svg b/assets/fonts/fontawesome-webfont.svg index d907b25..1ee89d4 100644 --- a/assets/fonts/fontawesome-webfont.svg +++ b/assets/fonts/fontawesome-webfont.svg @@ -1,6 +1,6 @@ - + @@ -147,14 +147,14 @@ - + - + @@ -275,7 +275,7 @@ - + @@ -411,7 +411,7 @@ - + @@ -438,7 +438,7 @@ - + @@ -513,8 +513,53 @@ - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/assets/fonts/fontawesome-webfont.ttf b/assets/fonts/fontawesome-webfont.ttf index 96a3639..ed9372f 100644 Binary files a/assets/fonts/fontawesome-webfont.ttf and b/assets/fonts/fontawesome-webfont.ttf differ diff --git a/assets/fonts/fontawesome-webfont.woff b/assets/fonts/fontawesome-webfont.woff index 628b6a5..8b280b9 100644 Binary files a/assets/fonts/fontawesome-webfont.woff and b/assets/fonts/fontawesome-webfont.woff differ diff --git a/assets/fonts/fontawesome-webfont.woff2 b/assets/fonts/fontawesome-webfont.woff2 new file mode 100644 index 0000000..3311d58 Binary files /dev/null and b/assets/fonts/fontawesome-webfont.woff2 differ diff --git a/assets/fonts/themify.eot b/assets/fonts/themify.eot new file mode 100644 index 0000000..9ec298b Binary files /dev/null and b/assets/fonts/themify.eot differ diff --git a/assets/fonts/themify.svg b/assets/fonts/themify.svg new file mode 100644 index 0000000..3d53854 --- /dev/null +++ b/assets/fonts/themify.svg @@ -0,0 +1,362 @@ + + + +Generated by IcoMoon + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/assets/fonts/themify.ttf b/assets/fonts/themify.ttf new file mode 100644 index 0000000..5d627e7 Binary files /dev/null and b/assets/fonts/themify.ttf differ diff --git a/assets/fonts/themify.woff b/assets/fonts/themify.woff new file mode 100644 index 0000000..847ebd1 Binary files /dev/null and b/assets/fonts/themify.woff differ diff --git a/assets/js/animatedheader.js b/assets/js/animatedheader.js new file mode 100644 index 0000000..cb199cc --- /dev/null +++ b/assets/js/animatedheader.js @@ -0,0 +1,34 @@ +var cbpAnimatedHeader = (function() { + + var docElem = document.documentElement, + header = document.querySelector( '.cbp-af-header' ), + didScroll = false, + changeHeaderOn = 300; + + function init() { + window.addEventListener( 'scroll', function( event ) { + if( !didScroll ) { + didScroll = true; + setTimeout( scrollPage, 250 ); + } + }, false ); + } + + function scrollPage() { + var sy = scrollY(); + if ( sy >= changeHeaderOn ) { + classie.add( header, 'cbp-af-header-shrink' ); + } + else { + classie.remove( header, 'cbp-af-header-shrink' ); + } + didScroll = false; + } + + function scrollY() { + return window.pageYOffset || docElem.scrollTop; + } + + init(); + +})(); diff --git a/assets/js/script.js b/assets/js/script.js index f693ce7..ba83964 100644 --- a/assets/js/script.js +++ b/assets/js/script.js @@ -17,26 +17,8 @@ // Init the posts postInit(); - // Waypoints - waypointsInit(); - - }); - -// Init waypoints for header and footer animations -function waypointsInit() { - $('#masthead').waypoint(function(direction) { - $(this).addClass('animation-on'); - }); - - $('#main').waypoint(function(direction) { - $('#masthead').toggleClass('animation-on'); + }); - - $('#footer').waypoint(function(direction) { - $(this).toggleClass('animation-on'); - } , { offset: 'bottom-in-view' }); -} - // Init bootstrap tooltip function tooltipInit() { $('[data-toggle]').tooltip(); @@ -55,4 +37,3 @@ function postInit() { } }(jQuery)); - diff --git a/assets/less/core.less b/assets/less/core.less index 01d1910..f814f1e 100644 --- a/assets/less/core.less +++ b/assets/less/core.less @@ -3,9 +3,11 @@ .@{fa-css-prefix} { display: inline-block; - font: normal normal normal 14px/1 FontAwesome; // shortening font declaration + font: normal normal normal @fa-font-size-base/1 FontAwesome; // shortening font declaration font-size: inherit; // can't have font-size inherit on line above, so need to override text-rendering: auto; // optimizelegibility throws things off #1094 -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; + transform: translate(0, 0); // ensures no half-pixel rendering in firefox + } diff --git a/assets/less/font-awesome.less b/assets/less/font-awesome.less index 195fd46..db97cba 100644 --- a/assets/less/font-awesome.less +++ b/assets/less/font-awesome.less @@ -1,8 +1,7 @@ /*! - * Font Awesome 4.2.0 by @davegandy - http://fontawesome.io - @fontawesome + * Font Awesome 4.3.0 by @davegandy - http://fontawesome.io - @fontawesome * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) */ - @import "variables.less"; @import "mixins.less"; @import "path.less"; @@ -11,7 +10,7 @@ @import "fixed-width.less"; @import "list.less"; @import "bordered-pulled.less"; -@import "spinning.less"; +@import "animated.less"; @import "rotated-flipped.less"; @import "stacked.less"; @import "icons.less"; diff --git a/assets/less/icons.less b/assets/less/icons.less index b5c26c7..c265de5 100644 --- a/assets/less/icons.less +++ b/assets/less/icons.less @@ -158,6 +158,7 @@ .@{fa-css-prefix}-bookmark-o:before { content: @fa-var-bookmark-o; } .@{fa-css-prefix}-phone-square:before { content: @fa-var-phone-square; } .@{fa-css-prefix}-twitter:before { content: @fa-var-twitter; } +.@{fa-css-prefix}-facebook-f:before, .@{fa-css-prefix}-facebook:before { content: @fa-var-facebook; } .@{fa-css-prefix}-github:before { content: @fa-var-github; } .@{fa-css-prefix}-unlock:before { content: @fa-var-unlock; } @@ -397,7 +398,8 @@ .@{fa-css-prefix}-trello:before { content: @fa-var-trello; } .@{fa-css-prefix}-female:before { content: @fa-var-female; } .@{fa-css-prefix}-male:before { content: @fa-var-male; } -.@{fa-css-prefix}-gittip:before { content: @fa-var-gittip; } +.@{fa-css-prefix}-gittip:before, +.@{fa-css-prefix}-gratipay:before { content: @fa-var-gratipay; } .@{fa-css-prefix}-sun-o:before { content: @fa-var-sun-o; } .@{fa-css-prefix}-moon-o:before { content: @fa-var-moon-o; } .@{fa-css-prefix}-archive:before { content: @fa-var-archive; } @@ -500,6 +502,7 @@ .@{fa-css-prefix}-send-o:before, .@{fa-css-prefix}-paper-plane-o:before { content: @fa-var-paper-plane-o; } .@{fa-css-prefix}-history:before { content: @fa-var-history; } +.@{fa-css-prefix}-genderless:before, .@{fa-css-prefix}-circle-thin:before { content: @fa-var-circle-thin; } .@{fa-css-prefix}-header:before { content: @fa-var-header; } .@{fa-css-prefix}-paragraph:before { content: @fa-var-paragraph; } @@ -550,3 +553,44 @@ .@{fa-css-prefix}-sheqel:before, .@{fa-css-prefix}-ils:before { content: @fa-var-ils; } .@{fa-css-prefix}-meanpath:before { content: @fa-var-meanpath; } +.@{fa-css-prefix}-buysellads:before { content: @fa-var-buysellads; } +.@{fa-css-prefix}-connectdevelop:before { content: @fa-var-connectdevelop; } +.@{fa-css-prefix}-dashcube:before { content: @fa-var-dashcube; } +.@{fa-css-prefix}-forumbee:before { content: @fa-var-forumbee; } +.@{fa-css-prefix}-leanpub:before { content: @fa-var-leanpub; } +.@{fa-css-prefix}-sellsy:before { content: @fa-var-sellsy; } +.@{fa-css-prefix}-shirtsinbulk:before { content: @fa-var-shirtsinbulk; } +.@{fa-css-prefix}-simplybuilt:before { content: @fa-var-simplybuilt; } +.@{fa-css-prefix}-skyatlas:before { content: @fa-var-skyatlas; } +.@{fa-css-prefix}-cart-plus:before { content: @fa-var-cart-plus; } +.@{fa-css-prefix}-cart-arrow-down:before { content: @fa-var-cart-arrow-down; } +.@{fa-css-prefix}-diamond:before { content: @fa-var-diamond; } +.@{fa-css-prefix}-ship:before { content: @fa-var-ship; } +.@{fa-css-prefix}-user-secret:before { content: @fa-var-user-secret; } +.@{fa-css-prefix}-motorcycle:before { content: @fa-var-motorcycle; } +.@{fa-css-prefix}-street-view:before { content: @fa-var-street-view; } +.@{fa-css-prefix}-heartbeat:before { content: @fa-var-heartbeat; } +.@{fa-css-prefix}-venus:before { content: @fa-var-venus; } +.@{fa-css-prefix}-mars:before { content: @fa-var-mars; } +.@{fa-css-prefix}-mercury:before { content: @fa-var-mercury; } +.@{fa-css-prefix}-transgender:before { content: @fa-var-transgender; } +.@{fa-css-prefix}-transgender-alt:before { content: @fa-var-transgender-alt; } +.@{fa-css-prefix}-venus-double:before { content: @fa-var-venus-double; } +.@{fa-css-prefix}-mars-double:before { content: @fa-var-mars-double; } +.@{fa-css-prefix}-venus-mars:before { content: @fa-var-venus-mars; } +.@{fa-css-prefix}-mars-stroke:before { content: @fa-var-mars-stroke; } +.@{fa-css-prefix}-mars-stroke-v:before { content: @fa-var-mars-stroke-v; } +.@{fa-css-prefix}-mars-stroke-h:before { content: @fa-var-mars-stroke-h; } +.@{fa-css-prefix}-neuter:before { content: @fa-var-neuter; } +.@{fa-css-prefix}-facebook-official:before { content: @fa-var-facebook-official; } +.@{fa-css-prefix}-pinterest-p:before { content: @fa-var-pinterest-p; } +.@{fa-css-prefix}-whatsapp:before { content: @fa-var-whatsapp; } +.@{fa-css-prefix}-server:before { content: @fa-var-server; } +.@{fa-css-prefix}-user-plus:before { content: @fa-var-user-plus; } +.@{fa-css-prefix}-user-times:before { content: @fa-var-user-times; } +.@{fa-css-prefix}-hotel:before, +.@{fa-css-prefix}-bed:before { content: @fa-var-bed; } +.@{fa-css-prefix}-viacoin:before { content: @fa-var-viacoin; } +.@{fa-css-prefix}-train:before { content: @fa-var-train; } +.@{fa-css-prefix}-subway:before { content: @fa-var-subway; } +.@{fa-css-prefix}-medium:before { content: @fa-var-medium; } diff --git a/assets/less/mixins.less b/assets/less/mixins.less index b7bfadc..c97f460 100644 --- a/assets/less/mixins.less +++ b/assets/less/mixins.less @@ -3,11 +3,13 @@ .fa-icon() { display: inline-block; - font: normal normal normal 14px/1 FontAwesome; // shortening font declaration + font: normal normal normal @fa-font-size-base/1 FontAwesome; // shortening font declaration font-size: inherit; // can't have font-size inherit on line above, so need to override text-rendering: auto; // optimizelegibility throws things off #1094 -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; + transform: translate(0, 0); // ensures no half-pixel rendering in firefox + } .fa-icon-rotate(@degrees, @rotation) { diff --git a/assets/less/path.less b/assets/less/path.less index c5a6912..9211e66 100644 --- a/assets/less/path.less +++ b/assets/less/path.less @@ -5,6 +5,7 @@ font-family: 'FontAwesome'; src: url('@{fa-font-path}/fontawesome-webfont.eot?v=@{fa-version}'); src: url('@{fa-font-path}/fontawesome-webfont.eot?#iefix&v=@{fa-version}') format('embedded-opentype'), + url('@{fa-font-path}/fontawesome-webfont.woff2?v=@{fa-version}') format('woff2'), url('@{fa-font-path}/fontawesome-webfont.woff?v=@{fa-version}') format('woff'), url('@{fa-font-path}/fontawesome-webfont.ttf?v=@{fa-version}') format('truetype'), url('@{fa-font-path}/fontawesome-webfont.svg?v=@{fa-version}#fontawesomeregular') format('svg'); diff --git a/assets/less/variables.less b/assets/less/variables.less index ccf939d..3f9bdc2 100644 --- a/assets/less/variables.less +++ b/assets/less/variables.less @@ -1,10 +1,10 @@ // Variables // -------------------------- - @fa-font-path: "../fonts"; -//@fa-font-path: "//netdna.bootstrapcdn.com/font-awesome/4.2.0/fonts"; // for referencing Bootstrap CDN font files directly +@fa-font-size-base: 14px; +//@fa-font-path: "//netdna.bootstrapcdn.com/font-awesome/4.3.0/fonts"; // for referencing Bootstrap CDN font files directly @fa-css-prefix: fa; -@fa-version: "4.2.0"; +@fa-version: "4.3.0"; @fa-border-color: #eee; @fa-inverse: #fff; @fa-li-width: (30em / 14); @@ -56,6 +56,7 @@ @fa-var-bar-chart-o: "\f080"; @fa-var-barcode: "\f02a"; @fa-var-bars: "\f0c9"; +@fa-var-bed: "\f236"; @fa-var-beer: "\f0fc"; @fa-var-behance: "\f1b4"; @fa-var-behance-square: "\f1b5"; @@ -83,6 +84,7 @@ @fa-var-bullhorn: "\f0a1"; @fa-var-bullseye: "\f140"; @fa-var-bus: "\f207"; +@fa-var-buysellads: "\f20d"; @fa-var-cab: "\f1ba"; @fa-var-calculator: "\f1ec"; @fa-var-calendar: "\f073"; @@ -98,6 +100,8 @@ @fa-var-caret-square-o-right: "\f152"; @fa-var-caret-square-o-up: "\f151"; @fa-var-caret-up: "\f0d8"; +@fa-var-cart-arrow-down: "\f218"; +@fa-var-cart-plus: "\f217"; @fa-var-cc: "\f20a"; @fa-var-cc-amex: "\f1f3"; @fa-var-cc-discover: "\f1f2"; @@ -146,6 +150,7 @@ @fa-var-comments-o: "\f0e6"; @fa-var-compass: "\f14e"; @fa-var-compress: "\f066"; +@fa-var-connectdevelop: "\f20e"; @fa-var-copy: "\f0c5"; @fa-var-copyright: "\f1f9"; @fa-var-credit-card: "\f09d"; @@ -157,11 +162,13 @@ @fa-var-cut: "\f0c4"; @fa-var-cutlery: "\f0f5"; @fa-var-dashboard: "\f0e4"; +@fa-var-dashcube: "\f210"; @fa-var-database: "\f1c0"; @fa-var-dedent: "\f03b"; @fa-var-delicious: "\f1a5"; @fa-var-desktop: "\f108"; @fa-var-deviantart: "\f1bd"; +@fa-var-diamond: "\f219"; @fa-var-digg: "\f1a6"; @fa-var-dollar: "\f155"; @fa-var-dot-circle-o: "\f192"; @@ -191,6 +198,8 @@ @fa-var-eye-slash: "\f070"; @fa-var-eyedropper: "\f1fb"; @fa-var-facebook: "\f09a"; +@fa-var-facebook-f: "\f09a"; +@fa-var-facebook-official: "\f230"; @fa-var-facebook-square: "\f082"; @fa-var-fast-backward: "\f049"; @fa-var-fast-forward: "\f050"; @@ -232,6 +241,7 @@ @fa-var-folder-open: "\f07c"; @fa-var-folder-open-o: "\f115"; @fa-var-font: "\f031"; +@fa-var-forumbee: "\f211"; @fa-var-forward: "\f04e"; @fa-var-foursquare: "\f180"; @fa-var-frown-o: "\f119"; @@ -242,6 +252,7 @@ @fa-var-ge: "\f1d1"; @fa-var-gear: "\f013"; @fa-var-gears: "\f085"; +@fa-var-genderless: "\f1db"; @fa-var-gift: "\f06b"; @fa-var-git: "\f1d3"; @fa-var-git-square: "\f1d2"; @@ -256,6 +267,7 @@ @fa-var-google-plus-square: "\f0d4"; @fa-var-google-wallet: "\f1ee"; @fa-var-graduation-cap: "\f19d"; +@fa-var-gratipay: "\f184"; @fa-var-group: "\f0c0"; @fa-var-h-square: "\f0fd"; @fa-var-hacker-news: "\f1d4"; @@ -268,9 +280,11 @@ @fa-var-headphones: "\f025"; @fa-var-heart: "\f004"; @fa-var-heart-o: "\f08a"; +@fa-var-heartbeat: "\f21e"; @fa-var-history: "\f1da"; @fa-var-home: "\f015"; @fa-var-hospital-o: "\f0f8"; +@fa-var-hotel: "\f236"; @fa-var-html5: "\f13b"; @fa-var-ils: "\f20b"; @fa-var-image: "\f03e"; @@ -294,6 +308,7 @@ @fa-var-lastfm: "\f202"; @fa-var-lastfm-square: "\f203"; @fa-var-leaf: "\f06c"; +@fa-var-leanpub: "\f212"; @fa-var-legal: "\f0e3"; @fa-var-lemon-o: "\f094"; @fa-var-level-down: "\f149"; @@ -325,10 +340,17 @@ @fa-var-mail-reply-all: "\f122"; @fa-var-male: "\f183"; @fa-var-map-marker: "\f041"; +@fa-var-mars: "\f222"; +@fa-var-mars-double: "\f227"; +@fa-var-mars-stroke: "\f229"; +@fa-var-mars-stroke-h: "\f22b"; +@fa-var-mars-stroke-v: "\f22a"; @fa-var-maxcdn: "\f136"; @fa-var-meanpath: "\f20c"; +@fa-var-medium: "\f23a"; @fa-var-medkit: "\f0fa"; @fa-var-meh-o: "\f11a"; +@fa-var-mercury: "\f223"; @fa-var-microphone: "\f130"; @fa-var-microphone-slash: "\f131"; @fa-var-minus: "\f068"; @@ -340,8 +362,10 @@ @fa-var-money: "\f0d6"; @fa-var-moon-o: "\f186"; @fa-var-mortar-board: "\f19d"; +@fa-var-motorcycle: "\f21c"; @fa-var-music: "\f001"; @fa-var-navicon: "\f0c9"; +@fa-var-neuter: "\f22c"; @fa-var-newspaper-o: "\f1ea"; @fa-var-openid: "\f19b"; @fa-var-outdent: "\f03b"; @@ -366,6 +390,7 @@ @fa-var-pied-piper: "\f1a7"; @fa-var-pied-piper-alt: "\f1a8"; @fa-var-pinterest: "\f0d2"; +@fa-var-pinterest-p: "\f231"; @fa-var-pinterest-square: "\f0d3"; @fa-var-plane: "\f072"; @fa-var-play: "\f04b"; @@ -415,8 +440,10 @@ @fa-var-search: "\f002"; @fa-var-search-minus: "\f010"; @fa-var-search-plus: "\f00e"; +@fa-var-sellsy: "\f213"; @fa-var-send: "\f1d8"; @fa-var-send-o: "\f1d9"; +@fa-var-server: "\f233"; @fa-var-share: "\f064"; @fa-var-share-alt: "\f1e0"; @fa-var-share-alt-square: "\f1e1"; @@ -425,11 +452,15 @@ @fa-var-shekel: "\f20b"; @fa-var-sheqel: "\f20b"; @fa-var-shield: "\f132"; +@fa-var-ship: "\f21a"; +@fa-var-shirtsinbulk: "\f214"; @fa-var-shopping-cart: "\f07a"; @fa-var-sign-in: "\f090"; @fa-var-sign-out: "\f08b"; @fa-var-signal: "\f012"; +@fa-var-simplybuilt: "\f215"; @fa-var-sitemap: "\f0e8"; +@fa-var-skyatlas: "\f216"; @fa-var-skype: "\f17e"; @fa-var-slack: "\f198"; @fa-var-sliders: "\f1de"; @@ -468,10 +499,12 @@ @fa-var-step-forward: "\f051"; @fa-var-stethoscope: "\f0f1"; @fa-var-stop: "\f04d"; +@fa-var-street-view: "\f21d"; @fa-var-strikethrough: "\f0cc"; @fa-var-stumbleupon: "\f1a4"; @fa-var-stumbleupon-circle: "\f1a3"; @fa-var-subscript: "\f12c"; +@fa-var-subway: "\f239"; @fa-var-suitcase: "\f0f2"; @fa-var-sun-o: "\f185"; @fa-var-superscript: "\f12b"; @@ -506,6 +539,9 @@ @fa-var-toggle-on: "\f205"; @fa-var-toggle-right: "\f152"; @fa-var-toggle-up: "\f151"; +@fa-var-train: "\f238"; +@fa-var-transgender: "\f224"; +@fa-var-transgender-alt: "\f225"; @fa-var-trash: "\f1f8"; @fa-var-trash-o: "\f014"; @fa-var-tree: "\f1bb"; @@ -532,7 +568,14 @@ @fa-var-usd: "\f155"; @fa-var-user: "\f007"; @fa-var-user-md: "\f0f0"; +@fa-var-user-plus: "\f234"; +@fa-var-user-secret: "\f21b"; +@fa-var-user-times: "\f235"; @fa-var-users: "\f0c0"; +@fa-var-venus: "\f221"; +@fa-var-venus-double: "\f226"; +@fa-var-venus-mars: "\f228"; +@fa-var-viacoin: "\f237"; @fa-var-video-camera: "\f03d"; @fa-var-vimeo-square: "\f194"; @fa-var-vine: "\f1ca"; @@ -544,6 +587,7 @@ @fa-var-wechat: "\f1d7"; @fa-var-weibo: "\f18a"; @fa-var-weixin: "\f1d7"; +@fa-var-whatsapp: "\f232"; @fa-var-wheelchair: "\f193"; @fa-var-wifi: "\f1eb"; @fa-var-windows: "\f17a"; @@ -558,4 +602,3 @@ @fa-var-youtube: "\f167"; @fa-var-youtube-play: "\f16a"; @fa-var-youtube-square: "\f166"; - diff --git a/assets/other/get_goc_sites.sh b/assets/other/get_goc_sites.sh new file mode 100755 index 0000000..d9734e5 --- /dev/null +++ b/assets/other/get_goc_sites.sh @@ -0,0 +1,15 @@ +#!/bin/bash +# Get sites from the goc +# See https://wiki.egi.eu/wiki/GOCDB/PI/Technical_Documentation#GOCDB_Programmatic_Interface +# we use xml2json to convert the xml to json. +# See https://github.com/Inist-CNRS/node-xml2json-command +# sudo npm install -g xml2json-command +wget --no-check-certificate -O result.xml 'https://goc.egi.eu/gocdbpi/public/?method=get_site_list&roc=AfricaArabia' +xml2json < result.xml > _data/goc_sites.json + +# We can do funky things here like loop over the list of services in the site. +wget --no-check-certificate -O services.xml 'https://goc.egi.eu/gocdbpi/public/?method=get_service_endpoint&roc=AfricaArabia' +xml2json < result.xml > _data/site_services.json + +wget --no-check-certificate -O services.xml 'https://goc.egi.eu/gocdbpi/public/?method=get_service_types' +xml2json < services.xml > _data/all_services.json diff --git a/assets/scss/_core.scss b/assets/scss/_core.scss index ca46d37..5a2db9d 100644 --- a/assets/scss/_core.scss +++ b/assets/scss/_core.scss @@ -3,9 +3,11 @@ .#{$fa-css-prefix} { display: inline-block; - font: normal normal normal 14px/1 FontAwesome; // shortening font declaration + font: normal normal normal #{$fa-font-size-base}/1 FontAwesome; // shortening font declaration font-size: inherit; // can't have font-size inherit on line above, so need to override text-rendering: auto; // optimizelegibility throws things off #1094 -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; + transform: translate(0, 0); // ensures no half-pixel rendering in firefox + } diff --git a/assets/scss/_icons.scss b/assets/scss/_icons.scss index 8dc2939..fbcfe81 100644 --- a/assets/scss/_icons.scss +++ b/assets/scss/_icons.scss @@ -158,6 +158,7 @@ .#{$fa-css-prefix}-bookmark-o:before { content: $fa-var-bookmark-o; } .#{$fa-css-prefix}-phone-square:before { content: $fa-var-phone-square; } .#{$fa-css-prefix}-twitter:before { content: $fa-var-twitter; } +.#{$fa-css-prefix}-facebook-f:before, .#{$fa-css-prefix}-facebook:before { content: $fa-var-facebook; } .#{$fa-css-prefix}-github:before { content: $fa-var-github; } .#{$fa-css-prefix}-unlock:before { content: $fa-var-unlock; } @@ -397,7 +398,8 @@ .#{$fa-css-prefix}-trello:before { content: $fa-var-trello; } .#{$fa-css-prefix}-female:before { content: $fa-var-female; } .#{$fa-css-prefix}-male:before { content: $fa-var-male; } -.#{$fa-css-prefix}-gittip:before { content: $fa-var-gittip; } +.#{$fa-css-prefix}-gittip:before, +.#{$fa-css-prefix}-gratipay:before { content: $fa-var-gratipay; } .#{$fa-css-prefix}-sun-o:before { content: $fa-var-sun-o; } .#{$fa-css-prefix}-moon-o:before { content: $fa-var-moon-o; } .#{$fa-css-prefix}-archive:before { content: $fa-var-archive; } @@ -500,6 +502,7 @@ .#{$fa-css-prefix}-send-o:before, .#{$fa-css-prefix}-paper-plane-o:before { content: $fa-var-paper-plane-o; } .#{$fa-css-prefix}-history:before { content: $fa-var-history; } +.#{$fa-css-prefix}-genderless:before, .#{$fa-css-prefix}-circle-thin:before { content: $fa-var-circle-thin; } .#{$fa-css-prefix}-header:before { content: $fa-var-header; } .#{$fa-css-prefix}-paragraph:before { content: $fa-var-paragraph; } @@ -550,3 +553,44 @@ .#{$fa-css-prefix}-sheqel:before, .#{$fa-css-prefix}-ils:before { content: $fa-var-ils; } .#{$fa-css-prefix}-meanpath:before { content: $fa-var-meanpath; } +.#{$fa-css-prefix}-buysellads:before { content: $fa-var-buysellads; } +.#{$fa-css-prefix}-connectdevelop:before { content: $fa-var-connectdevelop; } +.#{$fa-css-prefix}-dashcube:before { content: $fa-var-dashcube; } +.#{$fa-css-prefix}-forumbee:before { content: $fa-var-forumbee; } +.#{$fa-css-prefix}-leanpub:before { content: $fa-var-leanpub; } +.#{$fa-css-prefix}-sellsy:before { content: $fa-var-sellsy; } +.#{$fa-css-prefix}-shirtsinbulk:before { content: $fa-var-shirtsinbulk; } +.#{$fa-css-prefix}-simplybuilt:before { content: $fa-var-simplybuilt; } +.#{$fa-css-prefix}-skyatlas:before { content: $fa-var-skyatlas; } +.#{$fa-css-prefix}-cart-plus:before { content: $fa-var-cart-plus; } +.#{$fa-css-prefix}-cart-arrow-down:before { content: $fa-var-cart-arrow-down; } +.#{$fa-css-prefix}-diamond:before { content: $fa-var-diamond; } +.#{$fa-css-prefix}-ship:before { content: $fa-var-ship; } +.#{$fa-css-prefix}-user-secret:before { content: $fa-var-user-secret; } +.#{$fa-css-prefix}-motorcycle:before { content: $fa-var-motorcycle; } +.#{$fa-css-prefix}-street-view:before { content: $fa-var-street-view; } +.#{$fa-css-prefix}-heartbeat:before { content: $fa-var-heartbeat; } +.#{$fa-css-prefix}-venus:before { content: $fa-var-venus; } +.#{$fa-css-prefix}-mars:before { content: $fa-var-mars; } +.#{$fa-css-prefix}-mercury:before { content: $fa-var-mercury; } +.#{$fa-css-prefix}-transgender:before { content: $fa-var-transgender; } +.#{$fa-css-prefix}-transgender-alt:before { content: $fa-var-transgender-alt; } +.#{$fa-css-prefix}-venus-double:before { content: $fa-var-venus-double; } +.#{$fa-css-prefix}-mars-double:before { content: $fa-var-mars-double; } +.#{$fa-css-prefix}-venus-mars:before { content: $fa-var-venus-mars; } +.#{$fa-css-prefix}-mars-stroke:before { content: $fa-var-mars-stroke; } +.#{$fa-css-prefix}-mars-stroke-v:before { content: $fa-var-mars-stroke-v; } +.#{$fa-css-prefix}-mars-stroke-h:before { content: $fa-var-mars-stroke-h; } +.#{$fa-css-prefix}-neuter:before { content: $fa-var-neuter; } +.#{$fa-css-prefix}-facebook-official:before { content: $fa-var-facebook-official; } +.#{$fa-css-prefix}-pinterest-p:before { content: $fa-var-pinterest-p; } +.#{$fa-css-prefix}-whatsapp:before { content: $fa-var-whatsapp; } +.#{$fa-css-prefix}-server:before { content: $fa-var-server; } +.#{$fa-css-prefix}-user-plus:before { content: $fa-var-user-plus; } +.#{$fa-css-prefix}-user-times:before { content: $fa-var-user-times; } +.#{$fa-css-prefix}-hotel:before, +.#{$fa-css-prefix}-bed:before { content: $fa-var-bed; } +.#{$fa-css-prefix}-viacoin:before { content: $fa-var-viacoin; } +.#{$fa-css-prefix}-train:before { content: $fa-var-train; } +.#{$fa-css-prefix}-subway:before { content: $fa-var-subway; } +.#{$fa-css-prefix}-medium:before { content: $fa-var-medium; } diff --git a/assets/scss/_mixins.scss b/assets/scss/_mixins.scss index a139dfb..6b7f160 100644 --- a/assets/scss/_mixins.scss +++ b/assets/scss/_mixins.scss @@ -3,11 +3,13 @@ @mixin fa-icon() { display: inline-block; - font: normal normal normal 14px/1 FontAwesome; // shortening font declaration + font: normal normal normal #{$fa-font-size-base}/1 FontAwesome; // shortening font declaration font-size: inherit; // can't have font-size inherit on line above, so need to override text-rendering: auto; // optimizelegibility throws things off #1094 -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; + transform: translate(0, 0); // ensures no half-pixel rendering in firefox + } @mixin fa-icon-rotate($degrees, $rotation) { diff --git a/assets/scss/_path.scss b/assets/scss/_path.scss index fd21c35..bb457c2 100644 --- a/assets/scss/_path.scss +++ b/assets/scss/_path.scss @@ -5,10 +5,11 @@ font-family: 'FontAwesome'; src: url('#{$fa-font-path}/fontawesome-webfont.eot?v=#{$fa-version}'); src: url('#{$fa-font-path}/fontawesome-webfont.eot?#iefix&v=#{$fa-version}') format('embedded-opentype'), + url('#{$fa-font-path}/fontawesome-webfont.woff2?v=#{$fa-version}') format('woff2'), url('#{$fa-font-path}/fontawesome-webfont.woff?v=#{$fa-version}') format('woff'), url('#{$fa-font-path}/fontawesome-webfont.ttf?v=#{$fa-version}') format('truetype'), url('#{$fa-font-path}/fontawesome-webfont.svg?v=#{$fa-version}#fontawesomeregular') format('svg'); - //src: url('#{$fa-font-path}/FontAwesome.otf') format('opentype'); // used when developing fonts +// src: url('#{$fa-font-path}/FontAwesome.otf') format('opentype'); // used when developing fonts font-weight: normal; font-style: normal; } diff --git a/assets/scss/_variables.scss b/assets/scss/_variables.scss index 669c307..9b7210e 100644 --- a/assets/scss/_variables.scss +++ b/assets/scss/_variables.scss @@ -2,9 +2,10 @@ // -------------------------- $fa-font-path: "../fonts" !default; -//$fa-font-path: "//netdna.bootstrapcdn.com/font-awesome/4.2.0/fonts" !default; // for referencing Bootstrap CDN font files directly +$fa-font-size-base: 14px !default; +//$fa-font-path: "//netdna.bootstrapcdn.com/font-awesome/4.3.0/fonts" !default; // for referencing Bootstrap CDN font files directly $fa-css-prefix: fa !default; -$fa-version: "4.2.0" !default; +$fa-version: "4.3.0" !default; $fa-border-color: #eee !default; $fa-inverse: #fff !default; $fa-li-width: (30em / 14) !default; @@ -56,6 +57,7 @@ $fa-var-bar-chart: "\f080"; $fa-var-bar-chart-o: "\f080"; $fa-var-barcode: "\f02a"; $fa-var-bars: "\f0c9"; +$fa-var-bed: "\f236"; $fa-var-beer: "\f0fc"; $fa-var-behance: "\f1b4"; $fa-var-behance-square: "\f1b5"; @@ -83,6 +85,7 @@ $fa-var-building-o: "\f0f7"; $fa-var-bullhorn: "\f0a1"; $fa-var-bullseye: "\f140"; $fa-var-bus: "\f207"; +$fa-var-buysellads: "\f20d"; $fa-var-cab: "\f1ba"; $fa-var-calculator: "\f1ec"; $fa-var-calendar: "\f073"; @@ -98,6 +101,8 @@ $fa-var-caret-square-o-left: "\f191"; $fa-var-caret-square-o-right: "\f152"; $fa-var-caret-square-o-up: "\f151"; $fa-var-caret-up: "\f0d8"; +$fa-var-cart-arrow-down: "\f218"; +$fa-var-cart-plus: "\f217"; $fa-var-cc: "\f20a"; $fa-var-cc-amex: "\f1f3"; $fa-var-cc-discover: "\f1f2"; @@ -146,6 +151,7 @@ $fa-var-comments: "\f086"; $fa-var-comments-o: "\f0e6"; $fa-var-compass: "\f14e"; $fa-var-compress: "\f066"; +$fa-var-connectdevelop: "\f20e"; $fa-var-copy: "\f0c5"; $fa-var-copyright: "\f1f9"; $fa-var-credit-card: "\f09d"; @@ -157,11 +163,13 @@ $fa-var-cubes: "\f1b3"; $fa-var-cut: "\f0c4"; $fa-var-cutlery: "\f0f5"; $fa-var-dashboard: "\f0e4"; +$fa-var-dashcube: "\f210"; $fa-var-database: "\f1c0"; $fa-var-dedent: "\f03b"; $fa-var-delicious: "\f1a5"; $fa-var-desktop: "\f108"; $fa-var-deviantart: "\f1bd"; +$fa-var-diamond: "\f219"; $fa-var-digg: "\f1a6"; $fa-var-dollar: "\f155"; $fa-var-dot-circle-o: "\f192"; @@ -191,6 +199,8 @@ $fa-var-eye: "\f06e"; $fa-var-eye-slash: "\f070"; $fa-var-eyedropper: "\f1fb"; $fa-var-facebook: "\f09a"; +$fa-var-facebook-f: "\f09a"; +$fa-var-facebook-official: "\f230"; $fa-var-facebook-square: "\f082"; $fa-var-fast-backward: "\f049"; $fa-var-fast-forward: "\f050"; @@ -232,6 +242,7 @@ $fa-var-folder-o: "\f114"; $fa-var-folder-open: "\f07c"; $fa-var-folder-open-o: "\f115"; $fa-var-font: "\f031"; +$fa-var-forumbee: "\f211"; $fa-var-forward: "\f04e"; $fa-var-foursquare: "\f180"; $fa-var-frown-o: "\f119"; @@ -242,6 +253,7 @@ $fa-var-gbp: "\f154"; $fa-var-ge: "\f1d1"; $fa-var-gear: "\f013"; $fa-var-gears: "\f085"; +$fa-var-genderless: "\f1db"; $fa-var-gift: "\f06b"; $fa-var-git: "\f1d3"; $fa-var-git-square: "\f1d2"; @@ -256,6 +268,7 @@ $fa-var-google-plus: "\f0d5"; $fa-var-google-plus-square: "\f0d4"; $fa-var-google-wallet: "\f1ee"; $fa-var-graduation-cap: "\f19d"; +$fa-var-gratipay: "\f184"; $fa-var-group: "\f0c0"; $fa-var-h-square: "\f0fd"; $fa-var-hacker-news: "\f1d4"; @@ -268,9 +281,11 @@ $fa-var-header: "\f1dc"; $fa-var-headphones: "\f025"; $fa-var-heart: "\f004"; $fa-var-heart-o: "\f08a"; +$fa-var-heartbeat: "\f21e"; $fa-var-history: "\f1da"; $fa-var-home: "\f015"; $fa-var-hospital-o: "\f0f8"; +$fa-var-hotel: "\f236"; $fa-var-html5: "\f13b"; $fa-var-ils: "\f20b"; $fa-var-image: "\f03e"; @@ -294,6 +309,7 @@ $fa-var-laptop: "\f109"; $fa-var-lastfm: "\f202"; $fa-var-lastfm-square: "\f203"; $fa-var-leaf: "\f06c"; +$fa-var-leanpub: "\f212"; $fa-var-legal: "\f0e3"; $fa-var-lemon-o: "\f094"; $fa-var-level-down: "\f149"; @@ -325,10 +341,17 @@ $fa-var-mail-reply: "\f112"; $fa-var-mail-reply-all: "\f122"; $fa-var-male: "\f183"; $fa-var-map-marker: "\f041"; +$fa-var-mars: "\f222"; +$fa-var-mars-double: "\f227"; +$fa-var-mars-stroke: "\f229"; +$fa-var-mars-stroke-h: "\f22b"; +$fa-var-mars-stroke-v: "\f22a"; $fa-var-maxcdn: "\f136"; $fa-var-meanpath: "\f20c"; +$fa-var-medium: "\f23a"; $fa-var-medkit: "\f0fa"; $fa-var-meh-o: "\f11a"; +$fa-var-mercury: "\f223"; $fa-var-microphone: "\f130"; $fa-var-microphone-slash: "\f131"; $fa-var-minus: "\f068"; @@ -340,8 +363,10 @@ $fa-var-mobile-phone: "\f10b"; $fa-var-money: "\f0d6"; $fa-var-moon-o: "\f186"; $fa-var-mortar-board: "\f19d"; +$fa-var-motorcycle: "\f21c"; $fa-var-music: "\f001"; $fa-var-navicon: "\f0c9"; +$fa-var-neuter: "\f22c"; $fa-var-newspaper-o: "\f1ea"; $fa-var-openid: "\f19b"; $fa-var-outdent: "\f03b"; @@ -366,6 +391,7 @@ $fa-var-pie-chart: "\f200"; $fa-var-pied-piper: "\f1a7"; $fa-var-pied-piper-alt: "\f1a8"; $fa-var-pinterest: "\f0d2"; +$fa-var-pinterest-p: "\f231"; $fa-var-pinterest-square: "\f0d3"; $fa-var-plane: "\f072"; $fa-var-play: "\f04b"; @@ -415,8 +441,10 @@ $fa-var-scissors: "\f0c4"; $fa-var-search: "\f002"; $fa-var-search-minus: "\f010"; $fa-var-search-plus: "\f00e"; +$fa-var-sellsy: "\f213"; $fa-var-send: "\f1d8"; $fa-var-send-o: "\f1d9"; +$fa-var-server: "\f233"; $fa-var-share: "\f064"; $fa-var-share-alt: "\f1e0"; $fa-var-share-alt-square: "\f1e1"; @@ -425,11 +453,15 @@ $fa-var-share-square-o: "\f045"; $fa-var-shekel: "\f20b"; $fa-var-sheqel: "\f20b"; $fa-var-shield: "\f132"; +$fa-var-ship: "\f21a"; +$fa-var-shirtsinbulk: "\f214"; $fa-var-shopping-cart: "\f07a"; $fa-var-sign-in: "\f090"; $fa-var-sign-out: "\f08b"; $fa-var-signal: "\f012"; +$fa-var-simplybuilt: "\f215"; $fa-var-sitemap: "\f0e8"; +$fa-var-skyatlas: "\f216"; $fa-var-skype: "\f17e"; $fa-var-slack: "\f198"; $fa-var-sliders: "\f1de"; @@ -468,10 +500,12 @@ $fa-var-step-backward: "\f048"; $fa-var-step-forward: "\f051"; $fa-var-stethoscope: "\f0f1"; $fa-var-stop: "\f04d"; +$fa-var-street-view: "\f21d"; $fa-var-strikethrough: "\f0cc"; $fa-var-stumbleupon: "\f1a4"; $fa-var-stumbleupon-circle: "\f1a3"; $fa-var-subscript: "\f12c"; +$fa-var-subway: "\f239"; $fa-var-suitcase: "\f0f2"; $fa-var-sun-o: "\f185"; $fa-var-superscript: "\f12b"; @@ -506,6 +540,9 @@ $fa-var-toggle-off: "\f204"; $fa-var-toggle-on: "\f205"; $fa-var-toggle-right: "\f152"; $fa-var-toggle-up: "\f151"; +$fa-var-train: "\f238"; +$fa-var-transgender: "\f224"; +$fa-var-transgender-alt: "\f225"; $fa-var-trash: "\f1f8"; $fa-var-trash-o: "\f014"; $fa-var-tree: "\f1bb"; @@ -532,7 +569,14 @@ $fa-var-upload: "\f093"; $fa-var-usd: "\f155"; $fa-var-user: "\f007"; $fa-var-user-md: "\f0f0"; +$fa-var-user-plus: "\f234"; +$fa-var-user-secret: "\f21b"; +$fa-var-user-times: "\f235"; $fa-var-users: "\f0c0"; +$fa-var-venus: "\f221"; +$fa-var-venus-double: "\f226"; +$fa-var-venus-mars: "\f228"; +$fa-var-viacoin: "\f237"; $fa-var-video-camera: "\f03d"; $fa-var-vimeo-square: "\f194"; $fa-var-vine: "\f1ca"; @@ -544,6 +588,7 @@ $fa-var-warning: "\f071"; $fa-var-wechat: "\f1d7"; $fa-var-weibo: "\f18a"; $fa-var-weixin: "\f1d7"; +$fa-var-whatsapp: "\f232"; $fa-var-wheelchair: "\f193"; $fa-var-wifi: "\f1eb"; $fa-var-windows: "\f17a"; diff --git a/assets/scss/font-awesome.scss b/assets/scss/font-awesome.scss index f300c09..388ac6b 100644 --- a/assets/scss/font-awesome.scss +++ b/assets/scss/font-awesome.scss @@ -1,5 +1,5 @@ /*! - * Font Awesome 4.2.0 by @davegandy - http://fontawesome.io - @fontawesome + * Font Awesome 4.3.0 by @davegandy - http://fontawesome.io - @fontawesome * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) */ @@ -11,7 +11,7 @@ @import "fixed-width"; @import "list"; @import "bordered-pulled"; -@import "spinning"; +@import "animated"; @import "rotated-flipped"; @import "stacked"; @import "icons"; diff --git a/campaigns.md b/campaigns.md index 1945658..aa05d5b 100644 --- a/campaigns.md +++ b/campaigns.md @@ -18,8 +18,9 @@ image: While this is just another way of doing what we've always been doing, it gives some more visibility to important ROC-wide tasks and allows clearer delegation of tasks. Also, it will allow us to report better to supporting projects such as well as relying parties like EGI.eu. Campaigns are documented on the [Github wiki pages](https://github.com/AAROC/DevOps/wiki/Ops-Campaigns) of the [AAROC](https://www.github.com/AAROC) [DevOps repo](https://github.com/AAROC/DevOps). # Operations Campaigns - + {% assign sortedcampaigns = site.data.campaigns | sort:"priority" | reverse %} + @@ -31,16 +32,17 @@ While this is just another way of doing what we've always been doing, it gives s {% for campaign in sortedcampaigns %} + {% if campaign.wiki != null %} {% else if campaign.page != null %} {% else %} -{% endif %} + {% endif %} - + {% endfor %}
    {{ campaign.name }} {{ campaign.name }} {{ campaign.name }}{{ campaign.leader }} {{ campaign.state.name }} {{ campaign.start }} - {{ campaign.end }}
    diff --git a/cas.md b/cas.md new file mode 100644 index 0000000..9239d94 --- /dev/null +++ b/cas.md @@ -0,0 +1,27 @@ +--- +layout: page +permalink: /CertificateAuthorities/ +title: Certificate Authories +description: All your identity are belong to us +codrops: false + +image: + feature: hex0.jpg +--- + +{% for row in (0..3) %} +{% assign offset = row | times: 3 %} +
    +{% for CA in site.data.cas limit:3 offset: offset %} +
    +
    + ... +
    + {{ CA.name }} +

    Go

    +
    +
    +
    + {% endfor %} +
    +{% endfor %} diff --git a/code-rade.md b/code-rade.md new file mode 100644 index 0000000..48907d3 --- /dev/null +++ b/code-rade.md @@ -0,0 +1,6 @@ +--- +layout: redirect +sitemap: false +permalink: /code-rade/ +redirect_to: /CODE-RADE/ +--- diff --git a/coreservices.md b/coreservices.md new file mode 100644 index 0000000..55e5abe --- /dev/null +++ b/coreservices.md @@ -0,0 +1,22 @@ +--- +permalink: /coreservices/ +layout: page +codrops: false +gridlayout: true +title: "Core Services" +image: + feature: coreservices.jpg +--- +

    Keeping it all humming along

    + + diff --git a/cvmfs.md b/cvmfs.md new file mode 100644 index 0000000..ce9ce0e --- /dev/null +++ b/cvmfs.md @@ -0,0 +1,119 @@ +--- +layout: page +permalink: /cvmfs/ +title: Application Repository +headline: How to get the shiny +tags: [cvmfs, howto] +image: + feature: cvmfs-blocks.jpg + attribution: 'CERN Virtual Machine Filesystem block diagram http://cernvm.cern.ch/portal/filesystem' +--- +Here you can find how to mount the [CVMFS](http://cernvm.cern.ch/portal/filesystem) repositories which deliver our applications to you. Think of CVMFS as a filesystem that you can mount - except a really fast and +efficient one ! + + + +- [Repository information](#repository-information) +- [Quickstart Guide](#quickstart-guide) + - [Prerequisites](#prerequisites) + - [Mounting the repo - private mounts](#mounting-the-repo-private-mounts) + - [Using our modules](#using-our-modules) +- [Information for site managers](#information-for-site-managers) + - [Mounting the repo - HPC clusters](#mounting-the-repo-hpc-clusters) + - [Feedback and suggestions](#feedback-and-suggestions) +- [Footnotes](#footnotes) + + +# Repository information + +We currently provide two repositories, which contain *all* of the applications[^communityreposlater] - + +
    + + + + + + +{% for repo in site.data.cvmfs %} + + + +{% endfor %} +
    Repo NameDescriptionURL
    {{ repo.name }}{{ repo.description}}{{repo.url}}
    +
    + +# Quickstart Guide + +If you want to skip ahead to the fun bits, start here. This is a quick summary of the information in [the CVMFS Technical Report](https://ecsft.cern.ch/dist/cvmfs/cvmfstech-2.1-6.pdf) on how to mount repositories. + +## Prerequisites + + 1. **We only support Linux - specifically CentOS or Debian.**[^MacOSX] + 1. You need to have the CERN repos in your configuration : + Install the [CVMFS Release](https://cernvm.cern.ch/portal/downloads) package for your system. + 1. Install the client : + 1. `yum install cvmfs cvmfs-config-default` (RedHat derivatives) + 1. `dpkg -i cvmfs.deb cvmfs-config-default.deb` (Debian and Ubuntu) + 1. [Download the repo keys](https://github.com/AAROC/DevOps/tree/dev/Ansible/roles/cvmfs/files/etc/cvmfs/keys)[^RepoKeys] + +## Mounting the repo - private mounts + +Mounting the repositories can be done either in "local" or "system" mode. + + * **System-level** : A mountpoint is defined by the system administrator and is managed by autofs, usually `/cvmfs/` + * **Local mounts** : A user can make private mounts of a repository by issueing `cvmfs2 -o config=myparams.conf apprepo.sagrid.ac.za ` + * In this case, the minimum content of the `params.conf` file should be something like : +{% highlight bash %} +CVMFS_CACHE_BASE=/home/user/mycache +CVMFS_CLAIM_OWNERSHIP=yes +CVMFS_RELOAD_SOCKETS=/home/user/mycache +CVMFS_SERVER_URL=http://apprepo.sagrid.ac.za/cvmfs/apprepo.sagrid.ac.za +CVMFS_HTTP_PROXY=DIRECT +{% endhighlight %} + +The repository will be intelligently cached locally, by simply attempting to access files in it : +{% highlight bash %} +ls /cvmfs/devrepo.sagrid.ac.za/generic/u1404/x86_64/ +atlas cmake fftw3 gmp hdf5 mpc numpy python scipy +boost fftw gcc gsl lapack mpfr openmpi quantum-espresso zlib +{% endhighlight %} + +## Using our modules + +We will soon provide bash modules in order to set your environment correctly to use the applications in CVMFS[^ExpectedAugust]. + +# Information for site managers + + Site managers can apply the CVMFS configuration by executing the `cvmfs.yml` playbook in the [AAROC DevOps Repository](https://github.com/AAROC/DevOps) + + Manual configuration is also possible. See the client configuration section of the CVMFS technical report. + +## Mounting the repo - HPC clusters + +CMVFS is usually controlled by autofs, so if you have autofs on your site, simply add the CVMFS mountpoint to `cvmfs.master` : + +{% highlight bash %} ++auto.master +/cvmfs /etc/auto.cvmfs +{% endhighlight %} + + You can mount the repository on each of the worker nodes indepdendently, or on a local cache, then export it to the worker nodes via NFS. + + + +## Feedback and suggestions + +
    +
    + If you want to report an error please open an issue
    +
    If you have feedback or suggestions, please start a topic on the forum
    +
    + + +# Footnotes + +[^MacOSX]: If you really want to Mac, check the full technical report on how to do that. +[^communityreposlater]: We can and will happily host community repositories of tested applications later. +[^ExpectedAugust]: We expect this to be finished in mid-August 2015 +[^RepoKeys]: The repository keys are necessary to be able to connect to the CVMFS server. We keep ours in github at the moment, in the Ansible role which configures the clients. They are not yet distributed along with cvmf-release package. Someday soon... diff --git a/favicon-16x16.png b/favicon-16x16.png new file mode 100644 index 0000000..b5a4804 --- /dev/null +++ b/favicon-16x16.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:f6bd883ad589088617f2e990d6e310c3e2079a26e4ddcb4e9ff9f12e1b5439a2 +size 1336 diff --git a/favicon-32x32.png b/favicon-32x32.png new file mode 100644 index 0000000..267e40b --- /dev/null +++ b/favicon-32x32.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:bb87e929c689ff216551c954206377c5faa04cbab224826d10bcd4abf9368310 +size 2142 diff --git a/favicon-96x96.png b/favicon-96x96.png new file mode 100644 index 0000000..90d8c6b --- /dev/null +++ b/favicon-96x96.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:44c66fa0fb48304bbb8885d4a0beb468b583c56738b6fce75aafbf8b757d3fab +size 8963 diff --git a/favicon.ico b/favicon.ico index b19df98..2e1e855 100644 Binary files a/favicon.ico and b/favicon.ico differ diff --git a/images/1979369093_55ba84a606_o.jpg b/images/1979369093_55ba84a606_o.jpg new file mode 100644 index 0000000..17d7c46 Binary files /dev/null and b/images/1979369093_55ba84a606_o.jpg differ diff --git a/images/220110409213151001_4957481_ver1.0_640_480.JPG b/images/220110409213151001_4957481_ver1.0_640_480.JPG new file mode 100644 index 0000000..3067a14 Binary files /dev/null and b/images/220110409213151001_4957481_ver1.0_640_480.JPG differ diff --git a/images/AC2_logo.gif b/images/AC2_logo.gif new file mode 100644 index 0000000..c0e4cb1 Binary files /dev/null and b/images/AC2_logo.gif differ diff --git a/images/AnsibleBootCampCSIR.jpg b/images/AnsibleBootCampCSIR.jpg new file mode 100644 index 0000000..3d768d2 Binary files /dev/null and b/images/AnsibleBootCampCSIR.jpg differ diff --git a/images/CUSOq4xUwAAZCJn.jpg b/images/CUSOq4xUwAAZCJn.jpg new file mode 100644 index 0000000..f3bef7b Binary files /dev/null and b/images/CUSOq4xUwAAZCJn.jpg differ diff --git a/images/CVE-2015-3246.jpg b/images/CVE-2015-3246.jpg new file mode 100644 index 0000000..c082096 Binary files /dev/null and b/images/CVE-2015-3246.jpg differ diff --git a/images/Flag_of_Algeria.svg b/images/Flag_of_Algeria.svg new file mode 100644 index 0000000..6ec77a9 --- /dev/null +++ b/images/Flag_of_Algeria.svg @@ -0,0 +1,24 @@ + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/images/Flag_of_EGI.svg b/images/Flag_of_EGI.svg new file mode 100644 index 0000000..6545acf --- /dev/null +++ b/images/Flag_of_EGI.svg @@ -0,0 +1,1075 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/images/Flag_of_Egypt.svg b/images/Flag_of_Egypt.svg new file mode 100644 index 0000000..d036274 --- /dev/null +++ b/images/Flag_of_Egypt.svg @@ -0,0 +1,79 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/images/Flag_of_Kenya.svg b/images/Flag_of_Kenya.svg new file mode 100644 index 0000000..f5f7912 --- /dev/null +++ b/images/Flag_of_Kenya.svg @@ -0,0 +1,25 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/images/Flag_of_Morocco.svg b/images/Flag_of_Morocco.svg new file mode 100644 index 0000000..b035b0a --- /dev/null +++ b/images/Flag_of_Morocco.svg @@ -0,0 +1,67 @@ + + + + + + image/svg+xml + + + + + + + + + + diff --git a/images/Flag_of_Senegal.svg b/images/Flag_of_Senegal.svg new file mode 100644 index 0000000..0483098 --- /dev/null +++ b/images/Flag_of_Senegal.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/images/Flag_of_South_Africa.svg b/images/Flag_of_South_Africa.svg new file mode 100644 index 0000000..e3485c3 --- /dev/null +++ b/images/Flag_of_South_Africa.svg @@ -0,0 +1,18 @@ + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/images/Flag_of_Tanzania.svg b/images/Flag_of_Tanzania.svg new file mode 100644 index 0000000..96ca113 --- /dev/null +++ b/images/Flag_of_Tanzania.svg @@ -0,0 +1,7 @@ + + + + + + + \ No newline at end of file diff --git a/images/Flag_of_Tunisia.svg b/images/Flag_of_Tunisia.svg new file mode 100644 index 0000000..a32d401 --- /dev/null +++ b/images/Flag_of_Tunisia.svg @@ -0,0 +1,10 @@ + + + + + + + + + + \ No newline at end of file diff --git a/images/JenkinsBuildTriggersScreenshot.png b/images/JenkinsBuildTriggersScreenshot.png new file mode 100644 index 0000000..93f42e3 Binary files /dev/null and b/images/JenkinsBuildTriggersScreenshot.png differ diff --git a/images/Jr0F2ay.jpg b/images/Jr0F2ay.jpg new file mode 100644 index 0000000..9e3ef3b Binary files /dev/null and b/images/Jr0F2ay.jpg differ diff --git a/images/ORCIDworks-bruce-becker-04-2016.png b/images/ORCIDworks-bruce-becker-04-2016.png new file mode 100644 index 0000000..512a538 Binary files /dev/null and b/images/ORCIDworks-bruce-becker-04-2016.png differ diff --git a/images/RASR Architecture Components.svg b/images/RASR Architecture Components.svg new file mode 100644 index 0000000..e05e2d5 --- /dev/null +++ b/images/RASR Architecture Components.svg @@ -0,0 +1,184 @@ + + + + + + + + Public + Website + + + + + + + + + + rails application + + + + + + + Future Gateway + API Server + + + + + + + shibboleth + AuthN + + + + + + + grid + sites + + + + + + + cloud sites + + + + + + + HPC sites + + + + + + + CODE-RADE + + + + + + + Open Access + Data repository + + + + + + + EGI AppDB + + + + + + + Identity + Federations + + + + + + + eToken + Server + + + + + + + GridEngine/ + jSAGA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + metadata + service + + + + + + + Identity + Provider + + + + + + + Github + ORCID + Google + etc + + + + + + + + + + + + + + + + External services + + + Internal components + + + + diff --git a/images/Sci-GaIA-kpi.jpg b/images/Sci-GaIA-kpi.jpg new file mode 100644 index 0000000..a0efbd7 Binary files /dev/null and b/images/Sci-GaIA-kpi.jpg differ diff --git a/images/Sci-GaIAlogo.png b/images/Sci-GaIAlogo.png new file mode 100644 index 0000000..719df67 Binary files /dev/null and b/images/Sci-GaIAlogo.png differ diff --git a/images/SplitShire-068.jpg b/images/SplitShire-068.jpg new file mode 100644 index 0000000..f75cc3d Binary files /dev/null and b/images/SplitShire-068.jpg differ diff --git a/images/Trello.svg b/images/Trello.svg new file mode 100644 index 0000000..df0b250 --- /dev/null +++ b/images/Trello.svg @@ -0,0 +1,4 @@ + + + + \ No newline at end of file diff --git a/images/alicejobs.png b/images/alicejobs.png new file mode 100644 index 0000000..f36d5f5 Binary files /dev/null and b/images/alicejobs.png differ diff --git a/images/ansible_circleA_black_small.svg b/images/ansible_circleA_black_small.svg new file mode 100644 index 0000000..f340bab --- /dev/null +++ b/images/ansible_circleA_black_small.svg @@ -0,0 +1,64 @@ + + + + + +Created by potrace 1.11, written by Peter Selinger 2001-2013 + + + image/svg+xml + + + + + + + + + diff --git a/images/atari_breakout_free_play.jpg b/images/atari_breakout_free_play.jpg new file mode 100644 index 0000000..634dccc Binary files /dev/null and b/images/atari_breakout_free_play.jpg differ diff --git a/images/aup-post-header.jpg b/images/aup-post-header.jpg new file mode 100644 index 0000000..dc93d26 Binary files /dev/null and b/images/aup-post-header.jpg differ diff --git a/images/bad-idea.jpg b/images/bad-idea.jpg new file mode 100644 index 0000000..d79bbcb Binary files /dev/null and b/images/bad-idea.jpg differ diff --git a/images/banner-3rd-workshop.jpg b/images/banner-3rd-workshop.jpg new file mode 100644 index 0000000..73423cc Binary files /dev/null and b/images/banner-3rd-workshop.jpg differ diff --git a/images/bottleneck.jpg b/images/bottleneck.jpg new file mode 100644 index 0000000..d86c121 Binary files /dev/null and b/images/bottleneck.jpg differ diff --git a/images/build-failing.svg b/images/build-failing.svg new file mode 100644 index 0000000..1b6610d --- /dev/null +++ b/images/build-failing.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + build + build + failing + failing + + diff --git a/images/build-passing.svg b/images/build-passing.svg new file mode 100644 index 0000000..04e6e76 --- /dev/null +++ b/images/build-passing.svg @@ -0,0 +1,17 @@ + + + + + + + + + + + + build + build + passing + passing + + diff --git a/images/burn.jpg b/images/burn.jpg new file mode 100644 index 0000000..480c829 Binary files /dev/null and b/images/burn.jpg differ diff --git a/images/cb174b18a69d470e8fee59a90d5698ba.jpg b/images/cb174b18a69d470e8fee59a90d5698ba.jpg new file mode 100644 index 0000000..2dae072 Binary files /dev/null and b/images/cb174b18a69d470e8fee59a90d5698ba.jpg differ diff --git a/images/clink.jpg b/images/clink.jpg new file mode 100644 index 0000000..5bd6d60 Binary files /dev/null and b/images/clink.jpg differ diff --git a/images/code-rade-jenkins-magic.png b/images/code-rade-jenkins-magic.png new file mode 100644 index 0000000..3a35ab2 Binary files /dev/null and b/images/code-rade-jenkins-magic.png differ diff --git a/images/code-rade-logo.png b/images/code-rade-logo.png new file mode 100644 index 0000000..4061b05 Binary files /dev/null and b/images/code-rade-logo.png differ diff --git a/images/code-rade-waffle-screenshot-2015-09-14.png b/images/code-rade-waffle-screenshot-2015-09-14.png new file mode 100644 index 0000000..66cde11 Binary files /dev/null and b/images/code-rade-waffle-screenshot-2015-09-14.png differ diff --git a/images/code-rade-workflow-1.dia b/images/code-rade-workflow-1.dia new file mode 100644 index 0000000..d259be6 Binary files /dev/null and b/images/code-rade-workflow-1.dia differ diff --git a/images/code-rade-workflow-1.png b/images/code-rade-workflow-1.png new file mode 100644 index 0000000..08e4c79 Binary files /dev/null and b/images/code-rade-workflow-1.png differ diff --git a/images/code-rade-workflow-1.svg b/images/code-rade-workflow-1.svg new file mode 100644 index 0000000..29a38e4 --- /dev/null +++ b/images/code-rade-workflow-1.svg @@ -0,0 +1,177 @@ + + + + + + + + + git commit + or pull request + + + + + + + triggers + jenkins + build + + + + + + + + + + + code compiles + on build slave + (aginst declared + depdencencies) + + + + + + + + + + + Build + Promoted + (1) + + + + + + + + + + + Build + Promoted + (2) + + + + + + + code executes + independently + on build slave + + + + + + + + + inform the team of + what's going on + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Build + Promoted + (2) + + + + + + + + + + + + + + + + + + + ??? + + + ??? + + diff --git a/images/code-rade.png b/images/code-rade.png new file mode 100644 index 0000000..1288878 Binary files /dev/null and b/images/code-rade.png differ diff --git a/images/container.png b/images/container.png new file mode 100644 index 0000000..7517429 Binary files /dev/null and b/images/container.png differ diff --git a/images/coreservices.jpg b/images/coreservices.jpg new file mode 100644 index 0000000..2029332 Binary files /dev/null and b/images/coreservices.jpg differ diff --git a/images/cvmfs-blocks.jpg b/images/cvmfs-blocks.jpg new file mode 100644 index 0000000..2d81c8e Binary files /dev/null and b/images/cvmfs-blocks.jpg differ diff --git a/images/discourse-logo.png b/images/discourse-logo.png new file mode 100644 index 0000000..d8bd627 Binary files /dev/null and b/images/discourse-logo.png differ diff --git a/images/docker.svg b/images/docker.svg new file mode 100755 index 0000000..d3edf5b --- /dev/null +++ b/images/docker.svg @@ -0,0 +1,61 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/images/e-research-summer-hackfest-2016-group-photo-1st-edition.jpg b/images/e-research-summer-hackfest-2016-group-photo-1st-edition.jpg new file mode 100644 index 0000000..3298174 Binary files /dev/null and b/images/e-research-summer-hackfest-2016-group-photo-1st-edition.jpg differ diff --git a/images/filter.jpg b/images/filter.jpg new file mode 100644 index 0000000..e2c52b0 Binary files /dev/null and b/images/filter.jpg differ diff --git a/images/firefox.jpg b/images/firefox.jpg new file mode 100644 index 0000000..6019267 Binary files /dev/null and b/images/firefox.jpg differ diff --git a/images/fluid.jpg b/images/fluid.jpg new file mode 100644 index 0000000..a90a581 Binary files /dev/null and b/images/fluid.jpg differ diff --git a/images/gear-lever.jpg b/images/gear-lever.jpg new file mode 100644 index 0000000..4a64a34 Binary files /dev/null and b/images/gear-lever.jpg differ diff --git a/images/github-repo-in-jenkins-project-screenshot.png b/images/github-repo-in-jenkins-project-screenshot.png new file mode 100644 index 0000000..f427ec2 Binary files /dev/null and b/images/github-repo-in-jenkins-project-screenshot.png differ diff --git a/images/githubapidown-10-2015.png b/images/githubapidown-10-2015.png new file mode 100644 index 0000000..080acf0 Binary files /dev/null and b/images/githubapidown-10-2015.png differ diff --git a/images/graph.png b/images/graph.png new file mode 100644 index 0000000..2dfb7a1 Binary files /dev/null and b/images/graph.png differ diff --git a/images/he__s_dead_jim_by_pepper_fox.jpg b/images/he__s_dead_jim_by_pepper_fox.jpg new file mode 100644 index 0000000..1abdb20 Binary files /dev/null and b/images/he__s_dead_jim_by_pepper_fox.jpg differ diff --git a/images/hex0.jpg b/images/hex0.jpg new file mode 100644 index 0000000..3f3d843 Binary files /dev/null and b/images/hex0.jpg differ diff --git a/images/home-image1.png b/images/home-image1.png new file mode 100644 index 0000000..b3d4738 Binary files /dev/null and b/images/home-image1.png differ diff --git a/images/icri-fringe-event.jpg b/images/icri-fringe-event.jpg new file mode 100644 index 0000000..ecce9c9 Binary files /dev/null and b/images/icri-fringe-event.jpg differ diff --git a/images/image-ansible.png b/images/image-ansible.png deleted file mode 100644 index 5e0bca5..0000000 Binary files a/images/image-ansible.png and /dev/null differ diff --git a/images/jenkins-source-control-option-screenshot.png b/images/jenkins-source-control-option-screenshot.png new file mode 100644 index 0000000..91b6099 Binary files /dev/null and b/images/jenkins-source-control-option-screenshot.png differ diff --git a/images/learning.jpg b/images/learning.jpg new file mode 100644 index 0000000..5d3c85d Binary files /dev/null and b/images/learning.jpg differ diff --git a/images/logo-chain-reds-transp.png b/images/logo-chain-reds-transp.png new file mode 100644 index 0000000..6003a01 Binary files /dev/null and b/images/logo-chain-reds-transp.png differ diff --git a/images/logo_final_medium.png b/images/logo_final_medium.png new file mode 100644 index 0000000..c538953 Binary files /dev/null and b/images/logo_final_medium.png differ diff --git a/images/maxresdefault.jpg b/images/maxresdefault.jpg new file mode 100644 index 0000000..29ff3b7 Binary files /dev/null and b/images/maxresdefault.jpg differ diff --git a/images/oka_1979_mss_naturala.jpg b/images/oka_1979_mss_naturala.jpg new file mode 100644 index 0000000..e1a5b8c Binary files /dev/null and b/images/oka_1979_mss_naturala.jpg differ diff --git a/images/oops-jenkins.png b/images/oops-jenkins.png new file mode 100644 index 0000000..bfd4445 Binary files /dev/null and b/images/oops-jenkins.png differ diff --git a/images/openssl_cve_2015_1793.png b/images/openssl_cve_2015_1793.png new file mode 100644 index 0000000..46f9dea Binary files /dev/null and b/images/openssl_cve_2015_1793.png differ diff --git a/images/operations-portal.png b/images/operations-portal.png new file mode 100644 index 0000000..0feeac6 Binary files /dev/null and b/images/operations-portal.png differ diff --git a/images/operations-portal.webm b/images/operations-portal.webm new file mode 100644 index 0000000..36927f9 Binary files /dev/null and b/images/operations-portal.webm differ diff --git a/images/ops-portal.png b/images/ops-portal.png new file mode 100644 index 0000000..cd051ca Binary files /dev/null and b/images/ops-portal.png differ diff --git a/images/orcid_128x128.png b/images/orcid_128x128.png new file mode 100644 index 0000000..d73bdcb Binary files /dev/null and b/images/orcid_128x128.png differ diff --git a/images/orcid_16x16.png b/images/orcid_16x16.png new file mode 100644 index 0000000..ef10914 Binary files /dev/null and b/images/orcid_16x16.png differ diff --git a/images/passing.svg b/images/passing.svg new file mode 100644 index 0000000..738e29e --- /dev/null +++ b/images/passing.svg @@ -0,0 +1 @@ +buildbuildpassingpassing \ No newline at end of file diff --git a/images/patience-yoda.jpg b/images/patience-yoda.jpg new file mode 100644 index 0000000..a5c62c6 Binary files /dev/null and b/images/patience-yoda.jpg differ diff --git a/images/perfSONAR-header.gif b/images/perfSONAR-header.gif new file mode 100644 index 0000000..3a9337a Binary files /dev/null and b/images/perfSONAR-header.gif differ diff --git a/images/perfsonar-services-sa.jpg b/images/perfsonar-services-sa.jpg new file mode 100644 index 0000000..08fee12 Binary files /dev/null and b/images/perfsonar-services-sa.jpg differ diff --git a/images/perun-logo-transparent.png b/images/perun-logo-transparent.png new file mode 100644 index 0000000..df7aa15 Binary files /dev/null and b/images/perun-logo-transparent.png differ diff --git a/images/photo-1453814279372-783dc5b638ae.jpeg b/images/photo-1453814279372-783dc5b638ae.jpeg new file mode 100644 index 0000000..5623edc Binary files /dev/null and b/images/photo-1453814279372-783dc5b638ae.jpeg differ diff --git a/images/python-build-26-snapshot.png b/images/python-build-26-snapshot.png new file mode 100644 index 0000000..255a3df Binary files /dev/null and b/images/python-build-26-snapshot.png differ diff --git a/images/r7Z09Ht.gif b/images/r7Z09Ht.gif new file mode 100644 index 0000000..6be7490 Binary files /dev/null and b/images/r7Z09Ht.gif differ diff --git a/images/rasr_logo.png b/images/rasr_logo.png new file mode 100644 index 0000000..eae346b Binary files /dev/null and b/images/rasr_logo.png differ diff --git a/images/sciencepattern.png b/images/sciencepattern.png new file mode 100644 index 0000000..891dcfe Binary files /dev/null and b/images/sciencepattern.png differ diff --git a/images/security.jpg b/images/security.jpg new file mode 100644 index 0000000..ad728e2 Binary files /dev/null and b/images/security.jpg differ diff --git a/images/separate.jpg b/images/separate.jpg new file mode 100644 index 0000000..d47e52c Binary files /dev/null and b/images/separate.jpg differ diff --git a/images/servicedied.jpg b/images/servicedied.jpg new file mode 100644 index 0000000..b70305e Binary files /dev/null and b/images/servicedied.jpg differ diff --git a/images/services.jpg b/images/services.jpg new file mode 100644 index 0000000..35da95e Binary files /dev/null and b/images/services.jpg differ diff --git a/images/shibboleth.png b/images/shibboleth.png new file mode 100644 index 0000000..07986db Binary files /dev/null and b/images/shibboleth.png differ diff --git a/images/soon10.jpg b/images/soon10.jpg new file mode 100644 index 0000000..4caba5b Binary files /dev/null and b/images/soon10.jpg differ diff --git a/images/soon11.jpg b/images/soon11.jpg new file mode 100644 index 0000000..dbf5336 Binary files /dev/null and b/images/soon11.jpg differ diff --git a/images/soon12.jpg b/images/soon12.jpg new file mode 100644 index 0000000..216586b Binary files /dev/null and b/images/soon12.jpg differ diff --git a/images/tumblr_mw87ofGfHW1sfie3io1_1280.jpg b/images/tumblr_mw87ofGfHW1sfie3io1_1280.jpg new file mode 100644 index 0000000..f399059 Binary files /dev/null and b/images/tumblr_mw87ofGfHW1sfie3io1_1280.jpg differ diff --git a/images/tumblr_mxah7dcExT1sfie3io1_1280.jpg b/images/tumblr_mxah7dcExT1sfie3io1_1280.jpg new file mode 100644 index 0000000..dab9c0a Binary files /dev/null and b/images/tumblr_mxah7dcExT1sfie3io1_1280.jpg differ diff --git a/images/tumblr_nfps6yStNE1sfie3io1_1280.jpg b/images/tumblr_nfps6yStNE1sfie3io1_1280.jpg new file mode 100644 index 0000000..ac5f519 Binary files /dev/null and b/images/tumblr_nfps6yStNE1sfie3io1_1280.jpg differ diff --git a/images/tumblr_oihkemAUKP1sfie3io1_1280.jpg b/images/tumblr_oihkemAUKP1sfie3io1_1280.jpg new file mode 100644 index 0000000..8dc67a4 Binary files /dev/null and b/images/tumblr_oihkemAUKP1sfie3io1_1280.jpg differ diff --git a/ms-icon-144x144.png b/ms-icon-144x144.png new file mode 100644 index 0000000..bd88790 Binary files /dev/null and b/ms-icon-144x144.png differ diff --git a/ms-icon-150x150.png b/ms-icon-150x150.png new file mode 100644 index 0000000..f5ae189 Binary files /dev/null and b/ms-icon-150x150.png differ diff --git a/ms-icon-310x310.png b/ms-icon-310x310.png new file mode 100644 index 0000000..deffd6c Binary files /dev/null and b/ms-icon-310x310.png differ diff --git a/ms-icon-70x70.png b/ms-icon-70x70.png new file mode 100644 index 0000000..7cfedf3 Binary files /dev/null and b/ms-icon-70x70.png differ diff --git a/projects.md b/projects.md index d6da349..92f12d6 100644 --- a/projects.md +++ b/projects.md @@ -28,7 +28,7 @@ We are always on the look out for collaborators, so if one of these projects hit diff --git a/science.md b/science.md index d088d85..7933b9f 100644 --- a/science.md +++ b/science.md @@ -30,6 +30,7 @@ As infrastructure providers, we're here to make sure there's enough power to get {% include Middleware.html %}
    +In order to execute applications and store data on the grid, you'll need a *context*. This is provided through an *identity* provider and an *authorisation*.
    Coming soon. diff --git a/security.md b/security.md new file mode 100644 index 0000000..7b12bb8 --- /dev/null +++ b/security.md @@ -0,0 +1,48 @@ +--- +layout: page +permalink: /security/index.html +title: We have got your back. +headline: Security view, tools and updates from the CSIRT to you. +tags: [security, page] +image: + feature: security.jpg + attribution: '"Security" by https://www.flickr.com/photos/cezaryborysiuk/ https://www.flickr.com/photos/cezaryborysiuk/4510261399/' +--- + +

    It's dangerous out there

    +
    +
    +

    +InfoSec : Everyone's business

    +

    +We work in a distributed environment that is highly interconnected and largely automted. Maintining information security across the services is the responsibility of not just the core system administrators, but all the communities which use the infrastructure. While we rely on the EGI CSIRT to provide analysis and alerts of security threats, as well as a level of security monitoring, prevention is better than cure. +

    +

    +Operational Security Services

    +

    Some links may require a personal certificate in your browser and priveliged roles

    + +

    Suspect shenanigans ? Don't be hasty Report an Incident and follow procedure. +

    +
    +
    +

    Recent security-related announcements and posts

    +{% for post in site.categories.security limit: 3 %} +

    {{ post.title }}

    +Written on {{ post.date | date_to_string }}, tagged with +{% for tag in post.tags %} {{ tag }} +{% endfor %} +{% endfor %} +
    + More + +
    +
    + +# Lighten up + +Hey, bad days happen to everyone, especially when information security is involved. If you get hacked or cracked or are just having a regular bad day, why not take a glance at Security Reactions and take solace in the fact that at least you're not alone. diff --git a/sitrep.md b/sitrep.md index 0e2b8b8..5fbabfa 100644 --- a/sitrep.md +++ b/sitrep.md @@ -1,6 +1,6 @@ --- layout: page -permalink: /SitRep/ +permalink: /sitrep title: So, how are we doing today ? info: "Attention on deck" tags: [sitrep] diff --git a/voms.md b/voms.md new file mode 100644 index 0000000..cf9ce88 --- /dev/null +++ b/voms.md @@ -0,0 +1,56 @@ +--- +layout: page +permalink: /voms/ +title: VOMS +image: + feature: Marvin-Gaye-Featured-Image.jpg +--- + +VOMS : Virtual Organisation Membership Service + +# TL;DR + +A VOMS adds permissions to your identity, allowing you to use services on the grid. + +Quickstart : + + - [x] Register in VO with your personal certificate + - [x] Copy personal certificate to $HOME/.globus/user[cert,key].pem + - [x] Create a proxy : voms-proxy-init --voms (e.g. sagrid) +{% highlight bash %} +voms-proxy-init --voms sagrid +Your identity: /C=IT/O=INFN/OU=Personal Certificate/L=ZA-MERAKA/CN=Bruce Becker +Creating temporary proxy ................................................... Done +Contacting voms.sagrid.ac.za:15001 [/C=IT/O=INFN/OU=Host/L=ZA-UFS/CN=voms.sagrid.ac.za] "sagrid" Done +Creating proxy .................................. Done +Your proxy is valid until Tue Dec 15 05:46:27 2015 +{% endhighlight %} + - [x] Check that the proxy is still valid : voms-proxy-info --all +{% highlight bash %} +subject : /C=IT/O=INFN/OU=Personal Certificate/L=ZA-MERAKA/CN=Bruce Becker/CN=proxy +issuer : /C=IT/O=INFN/OU=Personal Certificate/L=ZA-MERAKA/CN=Bruce Becker +identity : /C=IT/O=INFN/OU=Personal Certificate/L=ZA-MERAKA/CN=Bruce Becker +type : proxy +strength : 1024 bits +path : /tmp/x509up_u500 +timeleft : 11:56:53 +key usage : Digital Signature, Key Encipherment, Data Encipherment +=== VO sagrid extension information === +VO : sagrid +subject : /C=IT/O=INFN/OU=Personal Certificate/L=ZA-MERAKA/CN=Bruce Becker +issuer : /C=IT/O=INFN/OU=Host/L=ZA-UFS/CN=voms.sagrid.ac.za +attribute : /sagrid/Role=NULL/Capability=NULL +timeleft : 11:56:53 +uri : voms.sagrid.ac.za:15001 +{% endhighlight %} + + +# Virtual Organisations + +In order to register to a Virtual Organisation, you need a personal certificate from a [trusted Certificate Authority]( {{ site_url }}/CertificateAuthorities ). There are several VO's supported - see a full list at the EGI Operations Portal + +# Attributes + +Attributes define what permissions you have. These are added to a proxy of your personal certificate by the VOMS. + +# Proxies diff --git a/za-meraka.md b/za-meraka.md new file mode 100644 index 0000000..e2bc066 --- /dev/null +++ b/za-meraka.md @@ -0,0 +1,10 @@ +--- +layout: page +url: za-meraka +title: The CSIR Meraka site +--- + +# ZA-MERAKA + +Core operations and stuff. +it's rad