Blonko!

While installing Alfresco, it is advised to run Openoffice on the server in headless mode, so Alfresco can use the running Openoffice instance to read, analyse and convert certain types of documents. Most documents only tell you to “apt-get install xvfb openoffice.org”; which isn’t complete. This works on Debian Etch:

First of all, as any guide tells you, install xvfb and OpenOffice:

apt-get install openoffice.org xvfb

The need for Openoffice is clear, as this is the package we are looking for. The xvfb package is the “X Virtual FrameBuffer”, a method to run a X-session completely in memory, by using a framebuffer (this emulates the screen, and a X-server is run inside this virtual screen). This package also gives us the “xvfb-run” command we will need later to start a X-session on this framebuffer, and run a openoffice inside of this framebuffer.

But, when we will start the Xvfb, some errors will pop up.

First of all, we need fonts. The X server will not start if it can’t find some basic fonts, starting with the most basic font “fixed”. The solution is simple, we just install the packages which contain the fonts:

apt-get install xfonts-base xfonts-75dpi xfonts-100dpi

Accept the needed dependencies, and we will can move on… Now, Xvfb will start (run ‘Xvfb :99′, it should give some warnings and some notes, but it should not fail to start. Use Ctrl-C to stop it again).

When running OpenOffice in the Xvfb the server will complain it needs ‘xauth’. This little utility is part of xbase-clients. Lets install it:

apt-get install xbase-clients

After accepting the dependencies; all is done for the X environment. It still complains about a policy file, but it isn’t required (if you want to fix this, install ‘xserver-xorg-core’ and its dependancies).

If you want to run Openoffice headless, this should now work with the following command:

xvfb-run -a /usr/lib/openoffice/program/soffice -headless -nologo -norestore -nofirststartwizard

The following is specific to an alfresco setup, and involves running Openoffice listening at a TCP connection:

We will change the startup options of OpenOffice, and add the values for the TCP-listener. You can use startup options to OpenOffice through the command line, but I changed it in the Setup file, so we don’t have to worry about this when restarting the service by hand. To do this, edit the file located at /usr/lib/openoffice/share/registry/data/org/openoffice/Setup.xcu, and add the following section (I added it just below the “oor:name”-node start for “Office”):

        <prop oor:name="ooSetupConnectionURL">
         <value>socket,host=localhost,port=8100;urp;StarOffice.ServiceManager</value>
        </prop>

Now, I tested the config, and started the xvfb-run, and then Alfresco.

And there was much rejoicing.

This is a quick-n-dirty, poor-mans solution to a migration from TextPattern to Radiant CMS. It doesn’t work perfect, it is some manual work, but it did the trick for me, and that’s all I needed. Observe:

First of all, get your data from the textpattern database, and import it in the Radiant CMS database. I used a simple mysqldump command for this, and loaded it back.

db-server $ mysqldump database textpattern > dumpfile.mysql
...(copy)...
devel-server $ mysql -u root site_development < dumpfile.mysql

A small note: I quickly loaded the dump in my editor and converted all the fieldnames to lower case before loading it back in the radiant database. You might want to do this also.

Lazy as I am, I quickly altered the table name to be plural, so Rails/Radiant wouldn't complain:

mysql> rename table textpattern to textpatterns;

Then I fired up Textmate and made this little script:

class Textpattern < ActiveRecord:Base; end 
 
u = User.find :first
 
Textpattern.find(:all, :conditions => {:section => 'article'}).each do |textpattern|
  p = Page.new({
    "virtual"=>false, 
    "class_name"=>'Page', 
    "slug"=>textpattern.url_title.downcase.strip.gsub(/\s+/,'-'), 
    "updated_at"=>textpattern.lastmod, 
    "title"=>textpattern.title, 
    "created_by"=>u, 
    "breadcrumb"=>textpattern.title, 
    "lock_version"=>0, 
    "enable_comments"=>0, 
    "updated_by"=>u, 
    "comments_count"=>0, 
    "published_at"=>textpattern.posted, 
    "status_id"=>100, 
    "position"=>1, 
    "layout_id"=>nil, 
    "parent_id"=>87, 
    "created_at"=>textpattern.lastmod}) do |newpage|
      newpage.parts.create({"name"=>"body", "filter_id"=>"Textile", "content"=>textpattern.body})  
      newpage.parts.create({"name"=>"summary", "filter_id"=>"Textile", "content"=>textpattern.excerpt}) 
  end
  p.save!
end

The first line will add a model for the Textpattern table we added, so we can use the ActiveRecord magic to access this table. The second line will load the first user it can find (I only had one, so no problems there).

From then on, we just get all the Textpatterns articles we want (a specific section in this case), and with each of these, I create a new page in radiant, and add pageparts to them, with good defaults.

Once done (and bugfixed), I simply copy-pasted this in a script/console session in my radiant-project. Done.

The defaults were stolen from a page I quickly created and published in Radiant, under the correct section. You need to pay attention to the “parent_id” for the Page-creation (get it from the database, or from the url when hovering it in the admin section), and the “name” for the PagePart creation sections.

Last work is to drop the added table from your database.

As I told you, quick-n-dirty, and nothing I’m really proud of, but I needed it fast, and I’ve published it here as it might help other people.

While working some more on a symfony project, I wanted to migrate the setup on the testing servers to my laptop, so I could continue working when I wasn’t at the office.

The project used a SQLite database, as the data stored is minimal (some hostnames and logins). On the testing servers, we had no problems using and working with these, and all needed parts happily talked to the datafiles. Alas, when running it on my Macbook Pro running Leopard, I got some errors from symfony, complaining the datafile was encrypted or no real sqlite datafile.

A quick check gave no real indication of the problem; the datafile appeared to be correct and worked using the CLI tools:

bernard:tmp bernard$ sqlite3 project.sqlite
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .tables
ftp_hosts_and_logins       sf_guard_remember_key
ftp_path                   sf_guard_user
sf_guard_group             sf_guard_user_group
sf_guard_group_permission  sf_guard_user_permission
sf_guard_permission
sqlite>

I even dumped the data to a text-file, and re-imported it using the cli-tools. Nothing helped, symfony (well, php) could not read the file. After a while, the problem was found. On Leopard, all the SQLite version 3 tools are included on the system, but in the PHP which is shipped with Leopard, the linked in library is version 2.

This would be no problem, but it seems Leopard ships without the SQLite version 2 cli tools, so there was no obvious way to convert this datafile to version 2 (or I should use the tools on the testing server, but then I had no way of using it from within my shell, which was no option).

This is just plain stupid. All libraries and tools are version 3, but the the linked library for PHP is version 2. Talk about forgetting something. As propel can’t work with PDO (another db layer in php), I either had to replace my PHP on Leopard with a custom-made one, or try to install the sqlite 2 tools. Neither seemed a good idea, I hate to replace my defaults with custom stuff.

It resulted in converting the SQLite database to MySQL and changing my symfony project to use the MySQL.