The Samba team is once again participating in the Summer of Code this year. This year we have 4 students working on various projects related to Samba.
This year I am mentoring Dhananjay Sathe, who is improving the GTK+ frontends for Samba. In particular, he is making it possible to manage shares and users of a remote Samba or Windows machine.
Dhananjay is also blogging about his progress.
As I have done in previous years, I am again participating in the Google Summer of Code as mentor for the Samba project.
Last year I Andrew and I co-mentored three students with mixed results. In the end we had to drop one of our students but the other two did well. I’ve only taken on one student this year for various reasons.
The amount of time required to mentor a student varies wildly depending on the student and is hard to predict based on their application. Some students seem to require quite a lot of mentoring while others are self-motivated and self-learning. This has not just been my experience, I’ve heard similar stories from fellow mentors on other projects.
Last summer Ricardo worked on SWAT for Samba 4 and he is still actively working on the project, even after the Summer of Code has finished. I hope to find the time to package SWAT in time for Debian Squeeze. At the moment SWAT just supports managing shares but Ricardo is working on user management.
In 2009 Calin worked on the GTK+ frontends for Samba, in particular changing them to be Python-based rather than C-based. This year his work is going to be continued by Sergio, hopefully with the some user-ready tools as the end result.
Currently Playing: Gazpacho - 117
These past few days in the US were a bit of a rollercoaster. Some random observations:
For this years (the fifth?) Summer of Code, I participated once again as a mentor for the Samba and OpenChange projects.
Samba was assigned four slots this year: one was a CIFSFS project mentored by Steve French and the other three were Python projects related to Samba 4, co-mentored by Andrew and me. Our students did very well this year, although we unfortunately had to drop one after the mid-term evaluations due to lack of effort. Nonetheless, we’re very happy with the results of the other two projects:
Calin Crisan (France) converted the rest of the applications in SambaGtk to Python, and worked on a GTK+ user manager for Samba and Windows. With his improvements, it is now possible to edit registries, manage users, inspect the endpoint mapper, plan tasks and manage services on a remote Windows machine using a GTK+ application on a Linux workstation.
Ricardo Velhote (Portugal) designed and implemented a new version of SWAT - the Samba Web Administration Tool. Unlike the old SWAT, his implementation is more than just a simple web-based editor for smb.conf. As we were expecting at the start of the Summer of Code, not all of the functionality could be implemented properly in a couple of months, not while getting the design and infrastructure right. With a basic version working, we now hope the remaining subsystems can be contributed with help from the community.
I’m planning to merge Calin’s improvements to Samba-Gtk into the mainline in the next month or so. SWAT is a standalone application and will continue to live as a separate project, while being a part of the Samba ecosystem. Congratulations, Calin and Ricardo!
Google’s Summer of Code was again a pleasure to participate in! I’m quite pleased with the overall results and have enjoyed working on the CUPS tree. Mike, main author of CUPS, has merged my Kerberos branch into trunk a couple of days ago. It should be part of the upcoming 1.3 series. My aim is to stick around and maybe work on SPNEGO/NTLMSSP support.
As of recently I have started working part-time for SerNet. I’ll be working on random Samba bits for them, all free software. The first thing I’m working on is backporting the excellent libndr (one of the core parts of DCE/RPC) subsystem from Samba 4 to Samba 3.
The university year has also started, so my activity in free software will probably decrease a bit in a few days.
I’ve finished the last few bits of my Summer of Code project. Client and server side authentication to CUPS using Kerberos work now, and that includes both the administration tools and IPP.
It’s been fun working on CUPS and now that I’m a bit more familiar with the code, I’d like to have a stab at implementing SPNEGO and NTLMSSP support as well. This should be much easier now, as I have already done the required work to support WWW-Authenticate: Negotiate, one of the prerequisites for both Kerberos and SPNEGO.
Rolf Kvinge also seems to have been successful, Mono now has a self-hosting Visual Basic.NET compiler. I’m looking forward to trying it out, once I can get my hands on a binary to compile it with…
For the second time I will be participating in the Google Summer of Code. My project this year is Kerberos integration in CUPS.
Currently Playing: Counting Crows - Goodnight Elizabeth
It’s almost 2 AM here, in other words, 17:00 PM in California - just a few more minutes before the list of SoC applicants will apparently be published. Hopefully one of my applications will be accepted; the quality of applications appears to be better overall than last year, so it’ll be tough…
Currently Playing: Stevie Ray Vaughn - Crossfire
Google has posted a summary of the results of the Summer of Code on the Company Blog. There’s also a link in there to a cool map with all the participants and mentors.
So, just a few more minutes until the deadline of the Google Summer of Code, 2005! I got pretty much all that I wanted in there done, except for the ldb_map module, which is still a bit dodgy.
Participating was a nice and interesting experience! The other participants that were working on Samba for SoC have produced some great code and it looks like they’re going to stick around. Especially Brads’ work on DSSYNC looks promising. I can certainly recommend anyone to participate if Google is repeating SoC again sometime in the future!
Looking back, I guess it could’ve been interesting to work on a different project then Samba such as mono (I do actually actively follow mono development, I just don’t contribute at the moment), althought what I did now was probably more productive and allowed me to spend some time on other sides of Samba than I am usually involved in as well.
I just committed the file STATUS file to the tree:
—- Samba3 -> Samba4 Upgrade —- (C) 2005 Jelmer Vernooij <jelmer@samba.org> Published under the GNU GPL
Sponsored by the Google Summer of Code program (http://code.google.com/summerofcode.html) Mentored by Andrew Bartlett <abartlet@samba.org> Thanks!
Source files: source/lib/ldb/modules/ldb_map.c source/lib/ldb/modules/ldb_map.h source/lib/samba3/group.c source/lib/samba3/idmap.c source/lib/samba3/policy.c source/lib/samba3/registry.c source/lib/samba3/samba3.c source/lib/samba3/secrets.c source/lib/samba3/share_info.c source/lib/samba3/smbpasswd.c source/lib/samba3/tdbsam.c source/lib/samba3/winsdb.c source/lib/samba3/samba3.h source/scripting/libjs/upgrade.js source/scripting/ejs/smbcalls_param.c source/scripting/ejs/smbcalls_samba3.c source/param/generic.c source/param/generic.h testdata/samba3/verify testprogs/ejs/samba3sam source/setup/upgrade source/scripting/bin/samba3dump source/dsdb/samdb/ldb_modules/samba3sam.c source/script/tests/test_s3upgrade.sh swat/install/samba3.esp
Looking more closely at one of the other approaches I could’ve taken for migrating from Samba3. We will probably end up supporting this method later on anyway, once we expand the vampire code. I do think the path I’ve taken for SoC is the right one though - it allows the upgrade with the least hassle and user input.
This approach could be splitted up into the various parts:
Advantages of this approach:
Disadvantages:
The one-way upgrade from Samba3 to Samba4 is now partially working! There are both a web-frontend and a console utility that can do an upgrade, given a libdir (usually /var/lib/samba) and a configuration file (usually in /etc/samba/smb.conf).
Last night, I rewrote most of the conversion code to be in EJS rather then in C. One of the positive things about this is that I can use embedded LDIF inside of the JavaScript code and that I can build on the existing Samba4 provisioning code (which is in EJS as well). Writing EJS wrappers for my existing C code was easier then I had thought.
One of the other things I did today is add a fallback mechanism for ldb_map where it can store the data that could not be mapped. There are now two types of records in ldb_map: those that are partially mapped (mapped, but might have one or two attributes stored in the fallback database) and those that are completely stored in the fallback database.
Below are some screenshots of the upgrade procedure in SWAT: /blog/uploads/screenshots/upgr1.png /blog/uploads/screenshots/upgr2.png /blog/uploads/screenshots/upgr3.png
The sam.ldif and winbind.ldif generation code now works as well. I’ll be working on generating the new smb.conf next.
One of the things that worries me is the fact that I can generate so few of the Samba4 ‘user’ and ‘group’ attributes. Probably need to borrow some code from the current provisioning script to fix that up.
I’m wondering whether I should do some of the upgrade using EJS, so it can be integrated into SWAT easily…
ldb_map and the samba3sam ldb module that is based on it work nicely now and appear to be memory-leak free. I have so far been testing with a TDB backend loaded with an LDIF from Samba3. Tomorrow will be the big day, testing against an OpenLDAP server.
Since the LDAP schema for Samba3 contains information that the Samba4 SAM database doesn’t store and vice versa, it will be interesting to find out whether the current mapping will be sufficient. If it is not, I might have to fall back to storing the Samba4 attributes I can’t store in the Samba3 LDAP database in a seperate database instead.
Another thing I did today is clean up the parameter list in Samba4 - I removed all unused parameters. This should hopefully make it easier to do the Samba3->Samba4 smb.conf conversion code.
TODO is down to:
Today was a productive day. I just got the LDIF output for samba3dump working for wins.ldif and the various registry hives. TODO is down to:
I hope to get the first three done tomorrow.
