After spending lots of time trying to make Gerrit work we agree with a conclusion that “Gerrit is ugly, intimidating, and inhumane“ and buggy. At least for us and Ubuntu 12.04.1.

According to Gerrit documentation:

The first user to sign-in and register an account will be automatically placed into the fully privileged Administrators group, permitting server management over the web and over SSH.

But here is our 5 attempts to make it work:

1. installing Gerrit 2.5 with H2 (aka Quick Installation in 10 Minutes) with stock Ubuntu Apache as reverse proxy, installation successful, logging in with Google Account OpenID, no administrator rights
2. installing Gerrit 2.5 with MySQL with stock Ubuntu Apache as reverse proxy, installation successful, logging in with Google Account OpenID, no administrator rights
3. installing Gerrit 2.4.2 (maybe it’s a problem with 2.5 only?) with H2 with stock Ubuntu Apache as reverse proxy, installation successful, logging in with Google Account OpenID, no administrator rights
4. installing Gerrit 2.4.2 with MySQL with stock Ubuntu Apache as reverse proxy, installation successful, logging in with Google Account OpenID, no administrator rights
5. installing Gerrit 2.5 with MySQL (no Apache and reverse proxy this time), installation successful, logging in with Google Account OpenID, no administrator rights
   Thus whatever path we chose, Gerrit failed to properly grant administrator rights to the first user as it clearly indicated in the docs.

There is a solution of course which is to edit database directly. However it makes one wonder what other nice “features” Gerrit is hiding.

And off we go to Phabricator.

After yet another trip to the Alps I decided to take a look at Picasa for quick processing of RAW photos from our Pentax DSLR. A major reason for trying Picasa instead of Lightroom was its speed, face recognition feature and out of the box G+ integration.

To my surprise freshly imported RAW photos looked visibly different (and subjectively quite worse) in Picasa. It took some time to find the answer, which was not on the surface and immediately caused me to go back to Lightroom for RAW processing:

Picasa and raw sensor data (RAW)

Picasa supports hundreds of distinct raw formats. Picasa’s raw data support is based on the free and open source dcraw. Camera makers generally create a new, distinct (and incompatible) raw format for just about every new camera body they make. That means that, for example, a .CR2 raw from a Canon 20d is not at all the same as a .CR2 raw from a Canon 5D, or the latest Rebel. They all have the .CR2 extension. But they’re incompatible and different. Same with Nikon .NEF raws and the raws of other camera makers.

At any point in time, the current version of Picasa will be unable to work with the raw photos taken by the most recently released cameras. Historically, several times per year, Picasa puts out a new release that includes support of new raw formats. We generally don’t really know when a new release will come out, or if any particular new raw format will be supported.

It’s important to understand how Picasa supports raw sensor data, though.

Picasa’s goal in supporting raws was to make it easy to shoot raws and to organize and share them.

At that, Picasa has succeeded wonderfully.

You shoot raw photos… and, in Picasa, you don’t even see a difference in how you work with them.

You see the photo. You edit the photo just like you would a JPEG.

You burn it to a Gift CD,… you upload it to a web album… you e-mail it to someone… you print it…

It’s easy… it’s exactly the same as if you were shooting JPEGs. No tricky stuff to worry about.

But, if you’re serious about shooting raws, you will need a “real” raw processor. A real raw processor includes the “tricky stuff.” The “tricky stuff” is how you tease out the details in the raw data.

Picasa supports raw data by immediately doing a fully automatic conversion to 8 bit data from the raw data with no input from you. You have no way to influence the raw conversion to JPEG. This pretty much eliminates the main reason you would shoot raw. A “real” raw processor requires that you get involved with the conversion process, helping to decide how to map those 12/14-bit color raw data into 8-bit color JPEG. What color balance should be used, etc. etc.

On easy, well-lit, well-exposed raw data, Picasa’s default translation to JPEG will likely be fine. On the tough shots, the tricky exposures (for example: night shots)… that’s where you’re going to want a “real” raw processor. Picasa’s automatic conversion process will most likely be sub-optimal on these kinds of shots.

You might want to consider using a raw processing program to work with the raws, and then let Picasa organize the resulting JPEGs.

Now that took some time to solve. When viewing taxonomy term in Drupal 7, by default both term description and all matching nodes are shown. However as soon as you enable “Taxonomy term” view (in views 7.x-3.3 in my case), the description is gone. Getting it back is not very straightforward, but fortunately doable without any custom PHP code.

The answer was found here although it’s even simpler than rt_davies posted:

1. Create a new view:
   • Name: Taxonomy description (or whatever you like)
   • Description: A view to display taxonomy description in taxonomy term view (if you want)
   • Show: Taxonomy terms
   • Click Continue & Edit
   • Fields > Add: Taxonomy term: Term description (feel free to remove Taxonomy term: Name, if you like)
   • Advanced > Contextual filters > Add: Taxonomy term: Term ID
2. Edit the existing Taxonomy term view:
   • Header > Add: Global: View area
     • View to insert: View: taxonomy_description – Display: default
     • Inherit contextual filters: check
   • Click Save (to save updated Taxonomy term view)

A brief guide:

1. Install ruby and passenger dependencies

   1	yum -y install ruby zlib-devel curl-devel openssl-devel httpd-devel apr-devel apr-util-devel mysql-devel

2. Install gem

   1 2 3 4

   wget http://production.cf.rubygems.org/rubygems/rubygems-1.8.17.tgz tar zxvf rubygems-1.8.17.tgz cd rubygems-1.8.17 ruby setup.rb

3. Install and build a Passenger for Apache

   1 2	gem install passenger passenger-install-apache2-module

4. Create passenger.conf file in /etc/httpd/conf.d

   1 2 3

   LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.11/ext/apache2/mod_passenger.so PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.11 PassengerRuby /usr/bin/ruby

5. Create conf file for your Rails application

6. Temporarily go into SELinux permissive mode

   1	setenforce 0

7. Restart Apache

   1	/sbin/service httpd restart

8. Start using your Rails application

9. Walk through SELinux log and generate new SELinux policy module

   1	grep httpd /var/log/audit/audit.log | audit2allow -M passenger

10. Install newly created SELinux module

    1	semodule -i passenger.pp

11. Switch SELinux back into enforcing mode

    1	setenforce 1

If you want to use Python with Twitter API, skip Python Twitter library for now. Get followers for any user bug makes version 0.6 pretty much useless. In addition to this, both next_cursor and previous_cursor are not supported.

Those who, after a seemingly successful upgrade from Magento 1.3.x to Magento 1.4.0.1, have problems with Magento acknowledging PayPal payments (changing order status from Pending Payment to Processing) and sending out New Order emails to their clients should do/check the following things:

1. In PayPal: Go to My Account -> Profiles -> More Options -> Instant Payment Notification Preferences -> Edit Settings and change instant payment notification (IPN) URL in PayPal IPN settings from:

   http://www.yoursite.com/paypal/standard/ipn/

   to:

   http://www.yoursite.com/paypal/ipn/standard/

2. In Magento admin panel: Go to Systems -> Configuration -> Payment Methods -> PayPal Website Payments Standard and check that Payment Action is set to Sale and New Order status to Processing

3. In Magento code: In file Ipn.php located in app/code/core/Mage/Paypal/Model/Ipn.php find function:
   

   public function getIpnFormData($key = null)

   
   comment out line:
   

   //return isset($this->_ipnFormData[$key]) ? $this>_ipnFormData[$key] : null;

   
   and add the following line immediately after it:
   

   return isset($this->_ipnFormData[$key]) ? urldecode($this->_ipnFormData[$key]) : null;

   
   This should do it. Your order status should be changing from Pending Payment to Processing and emails should work also.

Для установки сервера 1С:Предприятия 8.1 (без Web Services) и PostgresSQL 8.2 понадобятся следующие пакеты:

• 1C_Enterprise-server
• 1C_Enterprise-server-nls
• 1C_Enterprise-common
• 1C_Enterprise-common-nls
• postgresql
• postgresql-server
• postgresql-contrib
• postgresql-libs

Пошаговые инструкции:

1. Устанавливаем сервер 1С:Предприятия 8.1

   rpm -ivh 1C_Enterprise-common-8.1.11-67.i386.rpm 1C_Enterprise-common-nls-8.1.11-67.i386.rpm 1C_Enterprise-server-8.1.11-67.i386.rpm 1C_Enterprise-server-nls-8.1.11-67.i386.rpm
   

2. Устанавливаем PostgresSQL 8.2

   rpm -ivh postgresql-8.2.4-6.1C.i386.rpm postgresql-contrib-8.2.4-6.1C.i386.rpm postgresql-server-8.2.4-6.1C.i386.rpm postgresql-libs-8.2.4-6.1C.i386.rpm
   

3. Инициализируем кластер PostgresSQL с локалью ru_RU.utf8 для русского языка или uk_UA.utf8для украинского:

   su - postgres -c 'initdb --locale=uk_UA.utf8 -D /var/lib/pgsql/data/'
   

4. Отключаем пароли на подключение к PostgresSQL, заменяя в файле /var/lib/pgsql/data/pg_hba.conf строку

   host   all     all    0.0.0.0/0    md5
   

   на

   host   all     all    0.0.0.0/0    trust
   

5. Запускаем PostgresSQL

   /sbin/service postgresql start
   

6. Подключаемся к PostgresSQL
   

   
   psql -h localhost postgres postgres
   

   
   меняем пароль пользователя postgres
   

   
   ALTER USER postgres PASSWORD ‘new_password’;
   

   
   и выходим \q

7. Включаем пароли на подключение к PostgresSQL, заменяя в файле /var/lib/pgsql/data/pg_hba.confстроку

   host   all     all    0.0.0.0/0    trust
   

   на

   host   all     all    0.0.0.0/0    md5
   

8. Перезапускаем PostgresSQL

   /sbin/service postgresql restart
   

Если у Вас установлен Apache и возникают проблемы с библиотеками при замене родного системного PostgresSQL 8.1 на 8.2 - читаем Installing the PostgreSQL 8.2 RPMs on RHEL 5/CentOS 5

Вкратце, при апгрейде postgresql-libs с версии 8.1 до версии 8.2, библиотека libpq.so.4 заменяется на libpq.so.5. Однако libpq.so.4 необходима для системного httpd Apache и после апгрейда postgresql-libs с версии 8.1 до версии 8.2, httpd Apache станет не работоспособным.

Для решения проблемы достаточно установить compat-postgresql-libs (compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm) с опцией замены файлов

rpm -iv --replacefiles compat-postgresql-libs-4-1PGDG.rhel5.i686.rpm

compat-postgresql-libs также содержит libpq.so.4 и после его установки апгрейд postgresql-libs с версии 8.1 до версии 8.2 становится возможным, так как с удалением postgresql-libs версии 8.1, libpq.so.4 поставляется пакетом compat-postgresql-libs.

Скачать compat-postgresql-libs можно здесь: http://www.postgresql.org/ftp/binary/v8.2.7/linux/rpms/redhat/rhel-5-i386/

Those who installed Samba on RHEL or any other SELinux enabled distribution may have faced the problem when they actually cannot access any Samba shares from their Windows machines. Samba logs in /var/samba/log may show lots of such messages:

[2007/07/03 16:37:44, 0] smbd/service.c:make_connection_snum(911)
  '/opt/blah' does not exist or permission denied when connecting to [blah] 
  Error was Permission denied

This is probably an SELinux problem and to fix it you’ll need to execute:

chcon -t system_u:object_r:samba_share_t /opt

or, in order to survive relabel:

• add these lines to /etc/selinux/targeted/contexts/files/file_contexts.local file (if you are using targeted policy):

  /opt(/.*)?  system_u:object_r:samba_share_t:s0
  

• probably, reboot

• execute:

  restorecon -R /opt/
  

This will set appropriate SELinux context on all files in /opt directory and SELinux won’t prevent Samba access anymore.

To allow Samba to share your home directories with SELinux execute the following:

setsebool -P samba_enable_home_dirs 1

Fedora Legacy project announced shutdown on February 9th, 2007. It is definitely bad news for Fedora unless Fedora people understand what they do and do this on purpose. They just dropped Server spin from Fedora 7 release and now there is no way to get security updates beyond 18 month period for older Fedora releases.

We have several servers running Fedora and this means that now we must be thinking about either upgrading them to the most recent release of Fedora every 18 months or consider changing the Linux distribution we rely on. An upgrade every 18 months may not sound that bad for a workstation, but for a fully configured server it is definitely a hassle, taking into account many issues that can arise.

I do hope Fedora guys reconsider their support policy for maintenance distributions. However it is quite possible that Red Hat endorsed Fedora Legacy shutdown to drive more people toward Red Hat Enterprise Linux, in which case the chances for reconsideration are quite low.

Fedora 7 Test 2 has been released today, however it doesn’t provide a separate Server spin. It turns out this feature has been cancelled, which is too bad, however understandable, taking into account how much Fedora people intend accomplish with Fedora 7.