GSOC 2017/Student Application rinzler

Contact Information

Name: Anurag Malyala
Email: anuragmalyala9001@gmail.com
Alternate Contact : Facebook Messenger

The Project

389 Directory Server is an enterprise class LDAP server, used in businesses globally to authenticate and identify people. The system can setup and build new directory servers and instances. This is done by providing command line tools.
The main goal is to develop administrative tools for management and configuration of the server. The tools are provided using Python plugins and the goal is to set up dsadm and dsconf, and for the dsconf to be able to alter the plugins.

Benefits

For the community

• The tools developed during the project will make Extend the python tools dsconf to support enabling / disabling / configuration of modules in Directory Server to replace our legacy tools.
• The plugins in dsconf will be available to the command line tools for use in setting up and administering the DS.

As a student

• Learning how to integrate and use existing python frameworks and servers.
• Learning techniques to unit test command line and python tools.
• Learning how to work with a geographically distributed team.
• Learning the engineering principles expected of a project with high quality demands.

Project Timeline and Workflow

Timeline

Dates	Details	Deliverable
May 4 – May 30	Setup the DS server, get the 389 source code to work and testing it out. Learning about the source and the server as much as possible through interaction with the mentors. Discussing the possible modules and plugins to be added/modified	The DS Server and test environment will be up and running Goals and possible modules established
May 30 – June 26	Writing the first module discussed during the previous period. Making the changes reflect in the plugins and testing it.	The first module is ready for further testing by the organization and then deployment.
June 26	END OF PHASE 1 Reviewing the previous work and establishing what do next.
June 30 – July 28	Start on the second module/Plugin as discussed in previous period Testing it and making it reflect in the plugins. If possible, start to look at and review the work of others in the team.	The second module is ready for further testing by the mentors and then deployment.
July 28 – August 29	Submission of final work, adding all the work done to dsconf and trying it out. writing a report on the experience. Handing over any unfinished or any work about which I’m not a 100% sure about and informing the mentors about what’s left or needs to be mended	All the work is submitted to the mentors for review. All unfinished work noted and the mentors Writing a report on the experience.

Workflow

The goal is to work in iterative patches rather than one bit patch.
This allows for more flexibility in deciding what to do next and makes the review process easier. Apart from this it also makes tracking bugs/broken files much easier as they’ll be a part of one small patch rather than a big patch that’ll take a long time to debug. This “as you go” approach makes the whole process more involved between the mentors and student for better communication and understanding of the requirements.

About Me

I'm a 2nd year undergrad student studying Computer Engineering at Delhi Technological University, New Delhi India.
This'll be my first time (GSoC 2017) contributing code towards open source. I haven't been involved much with Fedora but after interacting with the community I plan to stay involved for some time now.
My interest in the field and curiosity are my main motivations towards working and learning as much as I can about everything computer science. I tend to work in small shifts of about 1-1:30 hours with a 15-20 minute break after it to check on other things and give a thought to the work I've done, i.e. thinking is there any way to make it simpler/ easier to read and use or is there a better way of doing it. After which I try the code out and if its all good, I get to the next task in hand. I do this for about 6-7 hours for major projects and 4-5 for minor ones.
So why Computers?
From a very early age I've been tinkering with computers, be it, its hardware or it's software. And for a long time it was mostly breaking it and then learning to fix it. This curiosity and passion lead me to pursue this course first in high school and the at university.
Till now I haven't been that active in the coding side of Open Source, just some testing and discussing features in the chats or the community forums. But I've been involved in the Open Source community since 8th grade. I came to know about it through software like Blender and Gimp. And now plan to start contributing to the community using the knowledge and skill I've acquired at university.

Why Fedora

Having used Linux for quite some time now and experimenting with many distributions, I found fedora to be the most stable and hard to break and also the most user friendly to someone who's had a little experience with Linux. It’s got a wide user base and is actively developed with frequent releases and updates. Having just done courses on operating systems I wanted to try what I’ve learnt out by contributing to an organization that’s got an active and easy to reach development team of friendly people as I’ve learnt from talking to them in the IRCs and the mailing lists.
This openness and the organizations history in open source made me pick Fedora over others.
GSoC gave me the perfect opportunity to get my feet wet in open source where the code I may end up writing code which may be used, tweaked, shared among thousands or even millions of users around the world. After GSoC has ended, I plan to stay involved with the project and Fedora. I'd like to try out new fields and propose ideas to the community to get views on it and if they get a positive response try getting it to work. At the same time, continuing to be involved in the 389-DS project

Why The 389-Directory Server Project

Being comfortable using python for making small apps and day-to-day scripts for college work I wanted to expand my knowledge and capabilities of it. Having just completed a course on database systems I wanted to see how some of its concepts are implemented in the real world. The 389- directory server seemed to have the perfect balance between what I know, what I want to know and what interests me. Through this I’d like to know more about how such systems work, how they’re used by the users and organizations and most importantly learn as much as I can during the process.
As I stated in the benefits and many other places before, as a student there's a lot to learn and I'm ready to do so. Things of technical and non technical nature both.

Why me

Being someone who picks up new skills pretty fast (going from hello world to "I wonder if I can make it do something it's totally not designed to do" in almost no time), I'll be learning A LOT throughout the summer, things way beyond the scope of project it self, things like "How real world software is made?", "How it's tested?", "who are the people behind things that we take for granted?". Just like the 389-DS, the authentication services it provides, we stumble upon its usage/implementation somewhere on the internet pretty much every time we go online. And all of this being open source, by contributing to it I'll be involving myself into " being a part of something grand " and that excites me and motivates me to do my best and beyond if selected for it.

Prior commitments and Plans during the summer

I have no plans during the summer apart from GSoC.
I’ll have my end term evaluations in early May and that’s about it.
If any plans are to come up, the mentors and other concerned parties will be informed well in advance of the same. If any travel plans are to come up I won’t be traveling to any place without internet access or access to my laptop for working. Most likely time for travel/other plans if any: early June or early July for about a week at most.