GSOC 2014/Student Application arcolife

• Name: Archit Sharma
• FAS Account: Arcolife
• Fedora userpage: https://fedoraproject.org/wiki/User:Arcolife

Contact Information

• Email Address: arc[DOT]sh[DOT]ams[AT]gmail[DOT]com
• Blog URL: http://blog.arcolife.in
• Freenode IRC Nick: arcolife

Why do you want to work with the Fedora Project?

Because Fedora was my entry point into the Open Source Culture (my college seniors introduced me to all of it) and I wish to contribute back!

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

• I have held workshops at my college, giving hands-on experience to participants with installation and basic usage.
• I was a summer student in CERN Labs, Geneva and worked on their Open Sourced Framework.
• I also keep making timely contributions on Github. (https://github.com/arcolife)

Did you participate with the past GSoC programs, if so which years, which organizations?

No.

Will you continue contributing/ supporting the Fedora project after the GSoC 2014 program, if yes, which team(s), you are interested with?

Yes. Fedora Packaging and Fedora Ambassadors

Why should we choose you over other applicants?

Because I'm efficient at improvising according the given task at hand. Because when I work on a project, I completely devote my time to the sole purpose of successful completion of the tasks (don't have a solid proof, but you could check my github streak and commits) and I have experience of Agile Software Development methodology.

Proposal for Google Summer of Code 2014

Name: Archit Sharma

Email Address: arc[DOT]sh[DOT]ams[AT]gmail[DOT]com

Freenode IRC Nick: arcolife

Twitter: @arcolife

Location (City, Country and/or Time Zone): New Delhi, India (UTC + 5:30)

Proposal Title: FedoraProject ­ Afterthought: A dependency for automation/deployment tools.

Motivation for Proposal / Goal

This idea was proposed due to the need felt for a system where disjoint teams are able to collaborate on a project without needing to worry about the configuration details of development/deployment servers. Also, there was one particular event (wiki/Fedora_Project) that happened in August 2008 (a security intrusion), when several Fedora servers were compromised, one of which was used for signing Fedora update packages. Although precautionary measures were taken, one of the original problem probably revolved around the integrity issues with the methods in existence.

The proposed idea makes automating tasks for the purpose of System Administration, much easier, by passing commands as URI parameters, and  executing customized tasks on the server. Afterthought fetches the latest   routines, and then executes the commands received over URI. At the same time, it takes care of integrity testing / authorization protocols, thought PGP/GPG and other authentication techniques. In a nutshell, its a DNS for automation tools and is a dependency for automation tools and not just another deployment tool.

Use Cases

• Task automation commands using Natural Language Processing capabilities, for easy interaction.
• OpenStack based development/deployment automation and routine execution for sandboxing/Contextualization through Browser.
• A system administrator can use automated tasks to perform periodic backups, monitor the system, run custom scripts, and more. Fedora comes with several automated tasks utilities: cron, at, and batch. Arguments could be passed to such utilities over the internet as well.
• The documentation for configuring Anacron Jobs at ( http://docs.fedoraproject.org/en-US/Fedora/17/html/System_Administrators_Guide/ch­Automating_System_Tasks.html#s2­configuring­anacron­jobs ) ..mentions several parameters   that   could   be   passed   through   variables like   SHELL,   PATH and   so  on, which could be including in a URI.

Expected Results

• An interactive tool for the *nix systems, with a nice interface.
• Features integration with Cron and Anacron (daemons that can be used to schedule the execution of recurring tasks) ..for its first release.
• Queued   tasks, Lazy loaded, but organized and sure to execute. 
• Features one-­time / recurring job  execution parameters.
• Lesser bugs / deprecated   configs   faced: Self­-aware system. Seamlessly extends possibilities w.r.t. present automation tools.
• Diversify collaborations – Teams in perhaps different time­-zones/locations, could work together
• Personalize: configuring a routines customized to particular profiles / credentials. 

Workflow

  By operation, one can simply consider it as a dynamic, lazy­-loaded shell­ script.   As of now, It would: • Take an URI as argument • Fetch the data of the URI • Strip/parse the formatted data (with instruction sets) • Execute the commands/job   In order to use Afterthought, a user has a base procedure prepared and passed to afterthought, something like:

1.  $ afterthought http://zomg.app/install

2.  $ afterthought https://lewildgithub.app/username/puses/to/ci

3.  $ afterthought https://thoughtpolice.tld/openshift/deploy?user=id&code=github.com/foo/bar

4.  $ afterthought https://thoughtpolice.tld/user/?profile=setup­irc­bouncer­on­my­raspberry­pidora

5.  $ afterthought https://thoughtpolice.tld/user/?profile=run­httpd­server­on­a­docker­image­of­fedora

OR

• maybe, in a Dockerfile (Refer: http://docs.docker.io/en/latest/reference/builder/#cmd)

CMD ["afterthought", "http://thoughthacker.tld/rule­the­world#plan­TBD­but­this­image­ships­today"]

The main network communication flow is as follows:   1. Client sends a request, in a container.

2. Afterthought Server receives the request and checks the authenticity.

3. Afterthought Server replies accordingly.

4. Client waits for request submission confirmation.

5. Afterthought Server (which has already queried the appropriate deployment server and keeps the  registry updated ) instantaneously sends the client an acknowledgement.

6. Deployment server receives and processes the request and takes an action.

7. Changes   on   the   deployment   server   are   reflected   somewhere   through   the   command-­line   /   browser,  as appropriate.

Implementation Details

  Technologies Writing each component using some of the options from the following:­

• Rust || C/C++ || Go
• Node.js::FlatIron/Express
• Python::Flask/Pyramids
• Ruby::Rails/Camping

Components   1. A web server that:

• Handles the API requests and encrypted communications (PGP/MD5 hash check)
• Forwards the request to the main application running on *nix systems.
• Employs algorithms to handle routine execution, efficient query processing (I/O cost + CPU cost + communication cost)
• Adds Firewall and SELinux configs, as per the Fedora Security Guide.

2. Interfaces:

• Configuration scripts which work based on systemctl/gconf philosophy.
• A Gecko based JSON ­container
• An API that helps with communicating through a web server.. (refer the options in technologies section).

3. Data Requests: - Docker like registry:

• To keep a list of trusted / non-trusted source, tasks and to store logs for handling privilege escalation matters.
• For storing registry preferences, like: configurations, routines, recurring/onetime, sources, and so on..
• Extending the routines, layer-­wise, so as to integration different automation task tools.

- A   base   container   for   handling   requests   in   JSON,   which   contains   the   parameters for interaction with the main server of afterthought. 4. Packaging: .rpm and .deb packages for installing afterthought script on *nix clients. 5. Security:

• Pretty Good Privacy (PGP) integration for securing server communications,   using   GnuPG. PGP supports message authentication and integrity checking.
• Calculate md5 hash of the file received, to verify integrity of transfer.

 

Tentative Timeline (Detailed Plan for May – September'14)

  - April 21 ­ May 23 (Community Bonding Period)

• Read documentations, explore existing solutions and refine the proposal.
• Generate a detailed sketch and further refine involved modules.
• Talk with mentor. Feedback on the plan.
• Implement samples in various tools, benchmark them and look for the most efficient implementation.
• Explore better request authentication/authorization options.
• Explore network communication protocol options.

- May 24­ June 20 (Coding ­ Phase 1)

Implement the following components:

• Web server
• API
• Server integration with the *nix system

Command line script to interact with the web server.

- June 21 ­ July 17 (Coding ­ Phase 2) The registry (mentioned in the components section of the proposal):

• Implement schema for keeping lists of trusted and  non-trusted sources.
• Implement structures for handling different tasks
• Implement conditions to handle Privilege escalation.

Algorithms to handle routine execution and query processing.

- July 18 ­ July 31 (Coding ­ Phase 3)

• Slow down, since have to give backlogs (7th of the 8 semesters Bachelors program; due to absence from college for pursuing an internship with CERN during 7th semester.)

Meanwhile, Implement MD5 checker and integrate GnuPGP.

- August 1 ­ August 14 (UI , Bug fixing)

• Client-side interactive scripts that work based on systemctl/gconf philosophy.
• Browser Integration
• Encourage community to try out the software, and do some modifications to make it easy   to use and attractive. Fix bugs.

- August 15 ­ August 26 (The last stop)

• Write code documentation, comments and techbase/user­-base articles.

 

Do you have other obligations from late May to early August (school, work, etc.)?

I assure that I will give around 40 hours per week for my work with no other obligations, except for my college exams for a week in mid­July, that have crept into the schedule, due to a 2 months absence from college for a previous internship at CERN, in my previous semester.

Who am I?

I am a Computer Science Undergraduate student from India (Batch of 2014). Essentially, I think of myself as an open-­source evangelist, who:

• has been a regular Linux user since past 3 years. Presently using Fedora & Ubuntu.
• mostly speaks Python on backend, but may speak Java, C/C++ as well, and Rust in this case.
• recently got addicted to Github. (https://github.com/arcolife)

1. Portfolio at http://work.arcolife.in

2. User:Arcolife on Fedora Project  

• I've recently interned at RedHat and CERN, and got to meet people who are leadig developers/promoters of FOSS   tools and techniques in India and abroad. While having   a conversation with my mentor Soumya Deb, he encouraged me to apply for Summer of Code this year. Thence, I was inspired to participate in GSoC'14 and have decided to implement the above mentioned idea.

 

• On the community part, I have been a helping hand at PyCon India 2012. I am a part of the local college LUG,   ALiAS, and have helped spread the open culture philosophy   among   students, by organizing workshops that promote the use of Fedora and other Open Sourced Software. While doing so, I also promote the use of Agile Software Development Methodology.

  > Lastly, if any part my proposal is not clear, I will be happy to clarify it.