Drupal 7 - Creation of Content Disappeared - Problems of Point and Click

I have been exploring Drupal 7,  particularly in trying to control access to creation of content followed by moderation by the appropriate editor. Even though I may be convinced that the level of control sought is unnecessary; but since it should be doable, might as well make it available.

I added the Workbench Access and Workbench Moderation modules. After I had suitably configured everything along with LDAP authentication, I found that the content just could not be created. I repeated the process, without LDAP, and still the same result.

I created a new content type and it worked the way it was intended. I just could not figure out what was going wrong with existing content types.

In a moment of "inspiration", I decided to examine the Navigation menu. As the Workbench user interface includes a tab for creation of content, I had excluded the "Add content" and subsidiary content creation entries from the Navigation menu. The new content type I created had the entry in the sub-menu enabled. Since the parent "Add content" was not in the menu, the child entries were not visible.

I enabled the existing content types in the Navigation menu and the content could indeed be created by the correct users.

Finally - after going around in circles for over a day! In retrospect, that wasn't too bad.

OpenLdap, Fedora 17 and Modifying Schema

Continuing my experiments with OpenLDAP, I needed to add mail attribute, which requires inetorgperson.schema. As I had not included it in the beginning, I wanted to modify  the schema. It should not be hard but I couldn't find a simple answer.

The discussion  "how-to-add-a-new-schema-to-openldap-2-4-11" gave a hint. Ldif files were needed and Fedora distribution includes them. So, I tried the the command
$ sudo ldapadd  -Y EXTERNAL -H ldapi:///  -f /etc/openldap/schema/inetorgperson.ldif

And it worked. However, since migration tools use the objectClass account which is inconsistent with inetOrgPerson, it turned out to be easier to recreate the ldap database.

OpenLDAP, Slapd, Fedora 17 and Authentication

Once the LDAP database is ready following the steps in the previous post, we can use authconfig-gtk to configure authentication via ldap. On Fedora, for using LDAP passwords either TLS/SSL or LDAPS is required.

The changes in Fedora 17 make getting started much easier. OpenLDAP creates a directory /etc/openldap/certs and creates an empty database of certificates (using /usr/libexec/openldap/create-certdb.sh)

During the installation, openldap-servers  runs /usr/libexec/openldap/generate-server-cert.sh which creates a dummy certificate for the local host and adds it to the certificates database in /etc/openldap/certs.

There is a small inconsistency, which should be resolved soon or it could have been caused by a file from earlier versions which is not replaced by the upgrade.

The files /etc/openldap/ldap.conf and /etc/sssd/sssd.conf use /etc/openldap/cacerts as the directory for the certificates. I needed to manually change that to /etc/openldap/certs.

When I was having problems with certificates, including ldaps in SLAPD_URLS in /etc/sysconfig/slapd and using the following command was helpful:

ldapsearch -ZZ -d 1 -x -LLL  -W -D cn=Manager,dc=example,dc=com -H ldaps:///

Update and caution: I find that slapd fails to start on reboot. It seems to timeout on some operation. However, it works fine upon:

$ sudo systemctl start slapd.service

Update: this was an issue of too small a timeout for my system in /usr/lib/systemd/system/slapd.service. Commenting the timeout solved the issue.
#TimeoutSec=3

Next: Modifying the schema.

OpenLDAP on Fedora 17 - Understanding Installation

As per the motivation in my previous post, I cleaned up slapd.d and various other files to start with a blank state on Fedora 17. Slapd would not start. It now needs slapd.d to exist.

Examining the installation script:

rpm -q --scripts openldap-servers

we notice that it creates fresh slapd.d at start as follows:

 /usr/libexec/openldap/convert-config.sh
                           -f /usr/share/openldap-servers/slapd.ldif

Obviously, the script is smart enough to upgrade the existing files and database in case slapd is already running.

We can customize slapd.conf as follows for our needs:

1. Modify realm in olcAccess, olcSuffix and olcRootDN entries. 
2. Add an entry for olcRootPW -  olcRootPW:"slappasswd output"
3. Add needed schemas, e.g. cosine and nis as only core schema is included by default.

Create the starting slapd database and start the daemon:

$ sudo /usr/libexec/openldap/convert-config.sh -f slapd.ldif
$ sudo systemctl start slapd.service

 I created base.ldif, users.ldif and groups.ldif using the migrationtools and added them to the ldap database:

$ ldapadd -x -W  -D cn=Manager,dc=example,dc=com  -f base.ldif 

It should now be possible to use this server for authentication.

More in next post.

OpenLdap, Slapd and Fedora 17

Single most useful statement about OpenLdap I found was in "LDAP for Rocket Scientists" :

The bad news is that IOHO never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND and ... and ...

Last time I had used slapd was some years ago. I needed to help a colleague. Fortunately, it was on Ubuntu and the absence of slapd.conf was not too intimidating. It wasn't hard to find that all one needed to do was

# dpkg-reconfigure slapd

I would need to help my colleague some more. So, I decided to set one up at home - on Fedora 16. And that is when I found the comment from "LDAP for Rocket Scientists". There did not seem to be an equivalent of Debian option for getting started. Also, the slapd.d files are substantial differences in the files in slapd.d in Debian and Fedora. Although I managed to get started using ldapmodify, the feeling has been that there has to be a simpler way, especially when I started using tls.

I used self-signed certificates but was having difficulty in getting the certificated trusted. Meanwhile, I upgraded to Fedora 17. There were changes in the way slapd is setup. Instead of /usr/openldap/cacerts, it uses /usr/openldap/certs directory. There are some scripts like generate-server-cert.sh and upgrade-db.sh. There must be some documentation somewhere about these changes. I just haven't found it yet.

So, I plan to drop the slap setup done so far. Start afresh on Fedora 17, making use of the tools provided and see if it makes life simpler.

A few simple things which have tripped me so far -

• Each ldap application is a client and has its own configuration file. It does not need to use /etc/openldap/ldap.conf
• Fedora now relies on sssd for ldap authentication. Since I keep upgrading my system, it did not have this server and was using nss_ldap and pam_ldap.
• The 'Common Name' on the certificate. 

The steps in next post.

Upgrading to Fedora 17 - using yum

Since my experience with preupgrade on the desktop was not so great, I decided to take a chance with upgrading my Lenovo S10-3 netbook to fedora 17 using yum.

The additional steps of modifying the filesystem using dracut were not really complex.

Most of the packages had already been downloaded by preupdate, which I had preserved. I copied them into the cache of  yum and executed:

# yum --releasever=17 --disableplugin=presto distro-sync

Unfortunately, after updating about 500 packages, yum seemed to be doing nothing. I killed the command. And ran yum-complete-transaction. It seemed to be using the repositories of Fedora 16 even though fedora-release files had been installed. So, I ran

# yum-complete-transaction --releasever=17

After a pretty long time, it told me that there were problems. I tried again with

# yum-complete-transaction --releasever=17 --skip-broken

An equally long wait and no better result. The problem was that rpm database had entries for both 16 and 17 versions for the packages which were updated.

The following command also did not help (Next time, I need to try with  the -t option to see if it would have tolerated errors).

# package-cleanup --cleandupes

The problem was that packages which had not yet been updated depended on the duplicates. Had I allowed this script to run, it would have deleted most of the packages.

I found a python script I had written when an upgrade from FC7 had failed because of power failure. The script created a file with the list of older duplicates, which could be used as an input to rpm as below:

# rpm --nodeps -e `cat deleteList.txt`

Finally, I cleaned up the failed yum transaction and ran:

# yum --releasever=17 --disableplugin=presto distro-sync

This time, the upgrade finished cleanly. Although it took about the same time and effort as the preupgrade, I enjoyed solving these problems a bit more.

Firefox crashes

As on the desktop, firefox crashed with even a few tabs. It seemed to be a random problem. However, I downloaded Firefox 12 from Mozilla and firefox works fine!

Updgrading to Fedora 17 - preupgrade

I took this advice in upgrading via yum seriously :

However Fedora 17 is very special. You should seriously consider stopping now and just using anaconda via. DVD or preupgrade, unlike all previous releases it's what the yum/rpm developers recommend. Continue at your own risk.

I decided to use preupgrade. I would have preferred yum as I would have more control over the update even if it were riskier. Anyway, the preupgrade went through nicely overnight. About 4 GB was downloaded and I was ready for the final stage.

Uses grub2 

I rebooted the system and it did nothing. I have continued to use grub and had not migrated to grub2. Preupgrade had created a new file grub.cfg in /boot/grub2. After failing to get the upgrade kernel to boot from grub, I installed grub2. It was easier than I had feared. It left the grub.cfg file untouched. I rebooted and the upgrade started.

It soon told me that I needed an additional GB of space. After making the additional space, I rebooted and the upgrade started. Everything was fine until it was cleaning up files. It just wouldn't end. I noticed at least 3 times glibc being cleaned up. There was little option but to reboot.

The reboot went through the upgrade process and felt that everything was done. I was ready to reboot into Fedora 17, except that the grub.cfg file was still the same and the preupgrade files had been removed. Fortunately, using the minimal editor in grub, I could boot using the F17 kernel. The first thing I did was to create a new grub.cfg file. The fireworks on the desktop looked nice.

SSH and password-less login

One minor issue was that I needed to give the password for using ssh from my remote system. I needed to copy authorized_keys2 to authorized_keys in .ssh.

Firefox crashes

Firefox seems to crash with a few tabs. It seems to be a random problem. However, if I download Firefox 12 from Mozilla, it works fine!

Save preupgrade files in case you want to upgrade more than one system.

I did not want to download the files again for my netbook. As a precaution, I had saved all the preupgrade files, in particular the rpm packages. As I feared, it cleaned up and even though keepcache was set, there were no packages of fedora 17 in the yum cache after the upgrade.