Everything is a Freaking DNS problem

I`m an oldschool guy .. I still love pop3(s) to get my mails locally and read them with my fat email client. Evolution.

So when gmail breaks their pop/imap infra I`m screwed for a while. I hate reading mail from a web gui and the collapsed threading model gmail uses makes me nauseus.

So I fiddled with my config .. disabled it.. deleted the account.. created it again. But even after gmail was up again . I couldn't access my mail from my favourite client. Yet from other clients it seemed to work.

This obviously is real fun when you are travelling and trying to keep an eye on a number of different email threads ..

So I`m back home from Paris now and spend some 10 minutes figuring out what could be wrong.

I ran into https://bugzilla.redhat.com/show_bug.cgi?id=949180 which points out that for newly created there is a problem with the keyring prompting

And refers to https://bugzilla.redhat.com/show_bug.cgi?id=953641 accounts Which states that gcr-3.6.2-3 breaks password prompt/keyring unlocks.

And indeed ..

yum shell
Loaded plugins: langpacks, presto, ps, puppetverify, refresh-packagekit
> remove gcr
> install gcr-3.6.2-1.fc18
adobe-linux-x86_64                                       |  951 B     00:00     
fedora/18/x86_64/metalink                                |  31 kB     00:00     
google-chrome                                            |  951 B     00:00     
google-earth                                             |  951 B     00:00     
google-talkplugin                                        |  951 B     00:00     
rpmfusion-free-updates                                   | 3.3 kB     00:00     
rpmfusion-nonfree-updates                                | 3.3 kB     00:00     
updates/18/x86_64/metalink                               |  24 kB     00:00     
rpmfusion-free-updates/primary_db                          | 279 kB   00:01     
> run
 --> Running transaction check
---> Package gcr.x86_64 0:3.6.2-1.fc18 will be installed
---> Package gcr.x86_64 0:3.6.2-3.fc18 will be erased
 --> Finished Dependency Resolution
 
 ================================================================================
  Package       Arch             Version                Repository          Size
 ================================================================================
  Installing:
   gcr           x86_64           3.6.2-1.fc18           fedora             627 k
  Removing:
    gcr           x86_64           3.6.2-3.fc18           @updates           2.3 M
 
    Transaction Summary
 ================================================================================
  Install  1 Package
  Remove   1 Package
 
    Total download size: 627 k
    Is this ok [y/N]: y
    Downloading Packages:
    gcr-3.6.2-1.fc18.x86_64.rpm                                | 627 kB   00:02     
    Running Transaction Check
    Running Transaction Test
    Transaction Test Succeeded
    Running Transaction
      Installing : gcr-3.6.2-1.fc18.x86_64                                      1/2 
      Cleanup    : gcr-3.6.2-3.fc18.x86_64                                      2/2 
      Verifying  : gcr-3.6.2-1.fc18.x86_64                                      1/2 
      Verifying  : gcr-3.6.2-3.fc18.x86_64                                      2/2 
           Removed:
              gcr.x86_64 0:3.6.2-3.fc18                                                     
           Installed:
             gcr.x86_64 0:3.6.2-1.fc18                                                     
 
               Finished Transaction
                > quit
             > Leaving Shell

Solved the problem

So John wrote down his experiences on deploying Drupal sites with Puppet .

It's not a secret that I've been thinking about similar stuff and how I could get to the best possible setup.

John starts of with using Puppet to download Drush... while I want to use rpm for that ...

I want my core infrastructure to be fully packaged... not downloaded and untarred. I want to be able to reproduce my platform in a couple of months , with the exact same versions I`m using now .. not with the version that happens to be on ftp.drupal.org at that point in time, or with ftp.drupal.org being down.

Now the next question off course is what's the core infrastructure.
Where does the infrastructure end and does the application start. There's little discussion about having a puppet created vhost , an apache conf.d file, a matching .htaccess file if wanted , and the appropriate settings.php for a multisite drupal config.

There's also little doubt to me on using drush to run the updates, manage the drupal site etc . Reading John's article made me think some further about what and when I want things packaged.

John's post lead to a discussion on #infra-talk on getting all drupal modules packaged for Centos with Karan and some others

In a development environment I probably want to have periodic drush updates getting the latest modules from the interwebs and potentially breaking my devs code. But making sure that when you put a site in production it will be on a fairly up to date platform, and not on the platform you started developing on 24 months ago.

In a production environment however you only want tested updates of your modules as indeed they will break code.

It's probably going to be a mix and match setup having a local rpm/deb repo with packaged modules that have been tested and validated in your setup and using drush to enable or configure them for that production setup.

But also having a CI environment wher Drush will get the new modules from the interwebs when needed. and package them for you.

To me that sounds beter than getting all the available Drupal modules and packaging them, even automated, and preparing a repository of those modules of which only a small percentage will actually be used by people.

But I need to think about it some more :)

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

It seems like Jeremy wants to be MySQL community president this week :)

The announcement of a MySQL yum repository is a good one but it's slightly confusing me .. didn't Jeremy already have this with
Dorsal, where there are also 5.1 builds. So what's the difference between Dorsal and the new yum repo anyway .

But he asks for Adittionals packages , well 5.1 to start with, apart from that the CentosPlus repo also has builds for Cluster , having a uniform place go get those to would be good.

And what about builds for CGE ?
Oh and while you are at it .. can you run genbasedir also .. that way we can also use apt4rpm :)

Now I all need is a repository with all drupal modules packaged separatly :)

So while upgrading python from a limited local repository I broke yum

[root@NTC-BASE-2 ~]# yum -y install foo
Traceback (most recent call last):
  File "/usr/bin/yum", line 28, in ?
    import yummain
ImportError: No module named yummain
<code>
 
However apt was still working
<code>
[root@NTC-BASE-2 ~]# rpm -e yum
[root@NTC-BASE-2 sources.list.d]# apt-get update
STUFF CUT
Fetched 3980kB in 8s (478kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done
[root@NTC-BASE-2 sources.list.d]# apt-get install yum
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  yum-metadata-parser
The following NEW packages will be installed:
  yum yum-metadata-parser
0 upgraded, 2 newly installed, 0 removed and 234 not upgraded.
Need to get 419kB of archives.
After unpacking 1412kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 <a href="http://mirror.centos.org" title="http://mirror.centos.org">http://mirror.centos.org</a> centos/4/apt/i386/os yum-metadata-parser 1.0-8.el4.centos [24.0kB]
Get:2 <a href="http://mirror.centos.org" title="http://mirror.centos.org">http://mirror.centos.org</a> centos/4/apt/i386/os yum 2.4.3-4.el4.centos [395kB]
Fetched 419kB in 1s (417kB/s)
Committing changes...
Preparing...                ########################################### [100%]
   1:yum-metadata-parser    ########################################### [ 50%]
   2:yum                    ########################################### [100%]
Done.
[root@NTC-BASE-2 sources.list.d]# y
[root@NTC-BASE-2 sources.list.d]# yum update
Setting up Update Process
Setting up repositories

Back in business :)

Good idea Raskas :)

So Russel is wondering how to figure out what platform you are on by adding a script or so that will tell you you are on a RPM based machine when trying to run dpkg or tell you you need to use rpm.

Imvho that system is broken .. as everybody with some brains uses apt, even on an rpm based system.