I am sad (but feel my duty) to inform the world that we will not be providing a Drupal 8 package in Debian.
I filed an Intent To Package bug a very long time ago, intending to ship it with Jessie; Drupal 8 was so deep a change that it took their community overly long to achieve and stabilize. Still, Drupal 8 was released over a year ago today.
I started working on debianizing the package shortly afterwards. There is also some online evidence – As my call for help sent through this same blog.
But... Reality bites.
When I started testing my precious package... It broke in horrible ways. Uncomprehensible PHP errors (and I have to add here, I am a PHP newbie and am reluctant to learn better a language that strikes me as so inconsistent, so ugly), which we spent some time tackling... Of course, configuration changes are more than expected...
But, just as we Debianers learnt some important lessons after the way-too-long Sarge freeze (ten years ago, many among you won't remember those frustrating days), Drupal learnt as well. They changed their release strategy — Instead of describing it, those interested can read it at its source.
What it meant for me, sadly, is that this process does not align with the Debian maintenance model. This means: The Drupal API stays mostly-stable between 8.0.x, 8.1.x, 8.2.x, etc. However, Drupal will incorporate new versions of their bundled libraries. I understood the new versions would be incorporated at minor-level branches, but if I read correctly some of my errors, some dependencies change even at patch-level updates.
And... Well, if you update a PHP library, and the invoking PHP code (that is, Drupal) relies in this new version... Sadly, it makes it unmaintainable for Debian.
So, long story short: I have decided to drop Drupal8 support in Debian. Of course, if somebody wants to pick up the pieces, the Git repository is still there (although I do plan on erasing it in a couple of weeks, as it means useless waste of project resources otherwise), and you could probably even target unstable+backports in a weird way (as it's software that, given our constraints, shouldn't enter testing, at least during a freeze).
So... Sigh, a tear is dropped for every lost hour of work, and my depeest regrets to David and Enrique who put their work as well to make D8 happen in Debian. I will soon be closing the ITP and... Forgetting about the whole issue? ☹
What About Drupal 8?
Now... With all the hype set in the future, it might seem striking that throughout this article I only talked about Drupal 7. This is because Debian seeks to ship only production ready software: as of this writing, Drupal 8 is still in beta. Not too long ago, we still saw internal reorganizations of its directory structure.
Once Drupal 8 is released, of course, we will take care to package it. And although Drupal 8 will not be a part of Debian 8, it will be offered through the Backports archive, following all of Debian's security and stability requirements.
Time passes, and I have to take care of following what I promise. Drupal 8 was released on November 18, so I must get my act together and put it in shape for Debian!
So, prompted by a mail by a fellow Debian Developer, I pushed today to Alioth the (very little) work I have so far done to this effect; every DD can now step in and help (and I guess DMs and other non-formally-affiliated contributors, but I frankly haven't really read how you can be a part of collab-maint).
So, what has been done? What needs to be done?
Although the code bases are massively different, I took the (un?)wise step to base off the Drupal7 packaging, and start solving Lintian problems and installation woes. So far, I have an install that looks sane (but has not yet been tested), but has lots of Lintian warnings and errors. The errors are mostly of missing sources, as Drupal8 inlines many unrelated projects (fortunately documented and frozen to known-good versions) in it; there are two possible courses of action:
- Prefered way: Find which already made Debian package provides each of them, remove from the binary package, declare dependency.
- Pragmatic way: As the compatibility must sometimes be to a specific version level, just provide the needed sources in debian/missing-sources
We can, of course, first go pragmatic and later start reviewing what can be safely depended upon. But for this, we need people with better PHP experience than me (which is not much to talk about). This cleanup will correspond with cleaning up the extra license file Lintian warnings, as there is one for each such project — Of course, documenting each such license in debian/copyright is also a must.
Anyway, there is quite a bit of work to do. And later, we have to check that things work reliably. And also, quite probably, adapt any bits of dh-make-drupal to work with v8 as well as v7 (and I am not sure if I already deprecated v6, quite probably I have).
So... If you are interested in working on this, please contact me directly. If we get more than a handful, building a proper packaging team might be in place, otherwise we can just go on working as part of collab-maint.
I am very short on time, so any extra hands will be most helpful!
Two days ago, Drupal announced version 7.32 was available. This version fixes a particularly nasty bug, allowing a SQL injection at any stage of interaction (that means, previous to the authentication taking place).
As soon as I could, I prepared and uploaded Debian packages for this — So if you run a Debian-provided Drupal installation, update now. The updated versions are:
- sid / jessie (unstable / testing)
- wheezy (stable)
- squeeze-backports (oldstable)
And, as expected, I'm already getting several attacks on my sites. Good thing that will help you anyway: Even though it won't prevent the attack from happening, if you use suhosin, several of the attacks will be prevented. Yes, sadly suhosin has not been in a stable Debian release since Wheezy, but still... :-|
Partial logs. This looks like a shellcode being injected as a file created via the menu_router mechanism (shellcode snipped):
- Oct 16 15:22:21 lafa suhosin: ALERT - configured request variable
- total name length limit exceeded - dropped variable 'name[0; INSERT INTO
- `menu_router` (`path`, `load_functions`, `to_arg_functions`, `description`,
- `access_callback`, `access_arguments`) VALUES ('deheky', '', '', 'deheky',
- );;# ]' (attacker '126.96.36.199', file '/usr/share/drupal7/index.php')
While the previous one is clearly targetting this particular bug, I'm not sure about this next one: It is just checking for some injection viability before telling me its real intentions:
- Oct 17 10:26:04 lafa suhosin: ALERT - configured request variable
- name length limit exceeded - dropped variable
- (attacker '188.8.131.52', file '/usr/share/drupal7/index.php')
So... looking at my logs from the last two days, Suhosin has not let any such attack reach Drupal (or I have been h4x0red and the logs have all been cleaned — Cannot dismiss that possibility :-) )
Anyway... We shall see many such attempts in the next weeks :-|
[update] Yes, I'm not the only one reporting this attack in the wild. Zion Security explains the same attempt I logged: It attempts to inject PHP code so it can be easily executed remotely (and game over for the admin!)
For the more curious, Tamer Zoubi explains the nature and exploitation of this bug.
Ok, so the day has come: Today begins the much awaited Drupal Camp Mexico City, yay!
For those that cannot make it to Mexico City, I
understand understood1 we would have live streaming of at least one of the rooms, but anyway, talks will be recorded, and will be put online later on.
As for the talks schedule, here you have it. Yes, today my workmate and I will be giving a simple introduction to having a useful basic Drupal install. Today is the tutorials / workshops / BoF / hackathon day, and Thursday and Friday will be the more traditional talks days. Several of the talks on Thursday are grouped under the SymfonyDay track and will refer to the framework that serves as a base for Drupal 8.
Anyway, for the Tweetheads among the readers of this post, I understand information will flow under the #DrupalCampMX tag.
- 1. I cannot find the link to the information, but it might appear later on... /mehopes
We are organizing a DrupalCamp in Mexico City!
As a Drupal user, I have so far attended two DrupalCamps (one in Guadalajara, Mexico, and one in Guatemala, Guatemala). They are –as Free Software conferences usually are– great, informal settings where many like-minded users and developers meet and exchange all kinds of contacts, information, and have a good time.
Torre de Ingeniería
This year, I am a (minor) part of the organizing team. DrupalCamp will be held in Torre de Ingeniería, UNAM — Just by Facultad de Ingeniería, where I teach. A modern, beautiful building in Ciudad Universitaria.
So, who is this for? You can go look at the accepted sessions, you will find there is a lot of ground. Starting from the very introduction to how Drupal is structured and some tips on how to work with it (delivered by yours truly), through workflows for specific needs, to strong development-oriented talks. The talks are structured along four tracks: "Training", "Theming", "Development", "Business" and "SymfonyDay".
Drupal is a fast-evolving Free Software project. Most users are currently using versions 6 and 7, which are as different between each other as day and night... But the upcoming Drupal 8 brings even greater changes. One of the most interesting changes I can see is that Drupal will now be based on a full MVC framework, Symfony. One of the days of our DrupalCamp will be devoted to Symfony (dubbed the Symfony Day).
...And... Again, just look at the list of talks. You will find a great amount of speakers interested in coming here. Not just from Mexico City. Not just from Mexico. Not just from Latin America. I must say I am personally impressed.
Of course, as with any volunteer-run conferences: We are still looking for sponsors. We believe being a DrupalCamp sponsor will greatly increase your brand visibility in the community you want to work with. There are still a lot of expenses to cover to make this into all that we want. And surely, you want to be a part of this great project. There are many sponsor levels — Surely you can be part of it!
I like Drupal. It's a very, very flexible CMS that evolved into a full-fledged Web development framework. Mind you, it's written in PHP, and that makes it a nightmare to develop for (in ~6 years I have used it for all of my important websites I have only got around to develop a set of related modules for it once).
PHP programming sucks and makes my eyes and fingers bleed, but happily there are people who disagree with me — And they tend to write code. All the better!
Minor upgrades with Drupal are quite easy to handle. Not as easy as I'd like (i.e. whenever I upgrade the core system or a module, I have to log in as
root^W admin^WUser #1 to ~15 different sites and run http://someurl/update.php — It very seldom causes any pain.
The updates that have to be run via this URL are usually on the database's structures, so I understand they have to be started (and watched) by a human. And yes, I know I could do that with Drush, the Drupal shell, but it is not very friendly to Debian-packaged Drupal... But easy enoguh.
But major updates are a royal pain, and they usually amount to quite a bit. First, disable all of the modules and revert to a known-safe theme. Ok, it makes sense. Second, check whether the modules exist for the newer version (as they won't work — Drupal changes enough between major versions that not only it's API-incompatible, I'd classify it as API-unrecognizable). Ok, all set? Now for the live migration itself... It has to be triggered from the browser.
So yes, I am now staring at a window making clever AJAX status updates. I am sitting at 46 of 199, but following the lovely ways of programmers, it's impossible to forsee whether update #47 will just be an UPDATE foo SET bar=0 WHERE bar IS NULL or a full-scale conversion between unspeakable serialized binary structures while rearranging the whole database structure.
And yes, while the meter progresses I stand in fear that update #n+1 will bomb giving me an ugly red error. I must keep the magic AJAX running, or the update might be botched.
And, of course, the update has sat at #69 all while I wrote the last two paragraphs. Sometimes the updates can progress after an interruption... And it seems I have no choice but to interrupt it.
/me crosses fingers...
[update] Wow... I am happy I got bored of looking at the meter and decided to write this blog post: After several minutes, and just as I was about to launch a second update session (130 updates to go), the meter advanced! I'm now sitting watching it at #75. Will it ever reach 199?
[update] And so it had to be... At around 115, I now got:
*sigh* The update process was aborted prematurely while running update #7000 in biblio.module...
I met my friend Josef Daberning, who did his Austrian Social Service working with Drupal at the Casa de los Tres Mundos NGO, in Granada, Nicaragua, at the Central American Free Software Encounter, last May. He told me that, when going back to Austria, he would spend some days in Mexico, and wanted to give a workshop on Drupal.
The course has just started, and will take place today and tomorrow — You can follow the live stream at http://www.iiec.unam.mx:18000/drupal.ogg — The videos will be uploaded soon as well, I will post them on this same node.
This node will be used for whatever is needed to make public for people following the talk. As of right now, you can download his presentation — http://gwolf.org/files/gira-drupal.odp and http://gwolf.org/files/gira-drupal.pdf
- If you are following the stream and want to say something, connect via IRC to OFTC (irc.debian.org) and join the #edusol channel.
- The videos for the talks will be made available soon, licensed under CC-BY 3.0 (generic)
- If you want to come, you are more than welcome. There is still space! We are in Ciudad Universitaria, South of Mexico City. Instituto de Investigaciones Económicas - UNAM. We are starting the second session (16:00-10:00), tomorrow we have a third and final session (10:00-14:00).
- Of course,it is all over by now. I will be processing the videos and uploading them to Archive.org's Open Source Movies archive. The three videos (for the three sessions) are available!