Posts Tagged ‘OpenSUSE’

12. August 2013

by

In: OpenSUSE, Tech

No comments

A colleague of mine recently faced difficulties to upload large opensource DVD images (>4G) into ownCloud during a demonstration. After some analysis, it turned out that it wasn’t ownCloud’s fault at all: PHP itself simply could not cope with large file uploads due to an overflow in some key variables. Further research showed that this had been known since 2008 under the bug number #44522. There was even a half completed patch available. I decided to pick up the existing patch and comments from developers and critics and port it to recent PHP, also making some changes to data type definitions. After a discussion on the PHP list, it turned out that this patch cannot be shipped for any upstream PHP before the next release (PHP 5.6) due to backwards compatibility. SUSE Enterprise Linux and openSUSE ship a similar patch with their PHP packages though. Finally, Michael Wallner added tests and included the patch into the PHP master branch.

There only has been very basic testing for Windows and other non-linux PHP ports yet but there is still some time to do this before PHP 5.6 gets released.

26. November 2012

by

In: Allgemein, Tech

Kommentare deaktiviert

This is beginner’s talk, but I have seen it too many times anyway.

A lot of tutorials on the web claim that you have to state “AllowOverride All” in an apache config and it magically activates mod_rewrite somehow.

This is all bullshit. Your mileage may vary, you may be lucky on debianish systems. It’s not very secure anyway.

Here’s what you do instead:

(suse)

yourserver:# /etc/apache2/conf.d # a2enmod rewrite
yourserver:# /etc/apache2/conf.d # vim /etc/apache2/vhosts.d/www.somesite.com.conf
<VirtualHost *>
 DocumentRoot /srv/www/somesite.com/wordpress
 ServerName www.somesite.com
 ServerAdmin ralf.lang@somesite.com
 <Directory /srv/www/somesite.com/wordpress>
  Options +FollowSymlinks
  RewriteEngine On
  ## put your rewriting-related .htaccess file content here, for example wordpress
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  ## end put stuff here
  ## ... more vhost stuff to follow

  ## finally
  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>
 yourserver:# rcapache2 reload

(debian)

yourserver:~# /etc/apache2/conf.d # a2enmod rewrite
yourserver:~# vim /etc/apache2/sites-available/www.somesite.com 
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName  www.somesite.com
        DocumentRoot /var/www/somesite.com/www
        <Directory />

                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/somesite.com/>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>                Options Indexes +FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
     ## more debianish vhost stuff
     ## ...
     ## finally
</VirtualHost>
yourserver:/etc/apache2/conf.d # a2ensite www.somesite.com
yourserver:/etc/init.d/apache2 reload

Here’s the explanation why:

AllowOverride allows a special hidden file .htaccess in any directory of your vhost to override settings from your apache vhost configs, especially security-related stuff like URL rewriting and symlink behaviour. This is fine for your hacky development setup but you do not want this in production. First, it’s slow because every lookup has to check for a .htaccess file and parse it if present. Second, it’s a hassle to debug once something screws up. Something will screw up at some point. Usually you are better off configuring your vhost properly.

Why does it work on debian?

Debian systems often have mod_rewrite enabled (loaded) but not active (working) in the default config. Allowing .htaccess files to magically activate them will work in many cases and provide a confusing problem for the rest.

Why doesn’t it work on openSUSE 12 and SLES 11??

SLES is optimized for enterprise environments where security counts. If you don’t enable overriding, it’s usually turned off. If you don’t enable mod_rewrite globally or for the site, it won’t magically be loaded later on. This leads to more tedious work but also a more predictable environment for admins under fire.

Stop confusing people. Tell them how to do it right and make them understand why it works. It will spare you trouble.

2. März 2012

by

In: horde, OpenSUSE

Kommentare deaktiviert

When installing horde to a custom pear location, you need to run the pear of your custom location, not the system pear with the custom location’s config.

So the steps would be:

 
1  mkdir /srv/horde 
2  pear config-create /srv/horde/ /srv/horde/pear.conf 
3  pear -c /srv/horde/pear.conf install PEAR 

as the install docs say but then:

4 /srv/horde/pear/pear -c /srv/horde/pear.conf channel-discover pear.horde.org 
5 /srv/horde/pear/pear -c /srv/horde/pear.conf run-scripts horde/Horde_Role 
6 /srv/horde/pear/pear -c /srv/horde/pear.conf install --alldeps horde/groupware 

Otherwise running the Horde_Role script will fail saying

config-set (horde_dir, /srv/horde/, user) failed, channel pear.php.net

This was experienced on SLES11SP1, SLES11SP2 and openSUSE Factory.

I did not test this for any debian based products yet.

22. Februar 2012

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

The spring 2012 release of the Horde Application Suite and Framework will probably be called Horde 5. In a recent discussion the majority of developers agreed on a new major revision for some changes that some view as minor backward compatibility break. Currently planned features include:

  • New standard UI for “traditional view”
  • Move of Ajax code from specific apps to a common framework
  • Release of a small inventory management app (sesha)
  • complete configuration via UI (likely)
  • Webmail: Write support for smartphone view
  • Calendar: Resource calendar support for ajax view

At the same time, Horde 3 will no longer receive any support. Horde 3 has been around since 2005 and really has reached its end of life.

Since the Horde 4 release, The Horde 3 family of applications has only received critical bugfixes and security updates, the last being released this february. You should really consider updating to Horde 4 – the transition from Horde 3 to Horde 4 has been tested and done by numerous people and the transition from Horde 4 to Horde 5 should run smoothly as both releases are PEAR based.

I have already removed all things horde3 from OpenSUSE-Factory. OpenSUSE 12.2 will not ship Horde 3 any longer. Depending on packaging progress, openSUSE 12.2 will very likely ship Horde 5 or the most recent Horde 4 release. Horde 4 maintainence will continue.

Horde 3 Packages in the server:php:applications repository (see here) will be available at least until openSUSE 12.1 runs out of maintainence. I won’t give these much attention though. Please also note Eleusis Password Manager will be dropped with currently no planned replacement.

26. Mai 2011

by

In: Allgemein, OpenSUSE, Tech

Kommentare deaktiviert

Today the openSUSE project announced that their packaging solution OpenSUSE Build Service will be re-branded to highlight the crossplatform nature of the product. The new name of the platform will be Open Build Service (OBS). Commercial support will also be available soon.

Ralph Dehner, CEO at B1 Systems GmbH noted:

“In the past B1 Systems has written build environments for the customers by itself. With the open Build Service now exists a “standard” which makes it easy to build packages for different distributions and architectures.

This will be also interesting for many other open source projects.”

26. Mai 2011

by

In: Allgemein, horde, OpenSUSE, Tech

3 comments

Today I submit-requested the Horde 4 Application Framework and the stable apps for openSUSE Factory.
This is becoming openSUSE 12.1 if the packages get accepted on time. They are currently in review.

openSUSE Legal team wants to review all packages’ licensing – I’m sure that’s NOT the fun part of their job.

If everything works fine, openSUSE 12.1 will be the first distribution to feature horde 4 in their mainstream repositories.

// read more >

21. Mai 2011

by

In: Allgemein, OpenSUSE, Tech

Kommentare deaktiviert

The %php_pear_gen_filelist macro, maintained by Christian Wittmer, is really handy for packaging php pear software packages. It generates rpmlint-happy filelists and if you manage to get the dependencies right, packaging pear stuff for rpm is really a no-brainer. But the standard recipe for using this macro has one drawback: It’s ignorant of installed 3rd party roles and channels. 3rd party pear packages which depend on their channel being registered normally fail.

The workaround is easy: Copy the channel file to the build location.

Example:

#
# spec file for package php5-pear-Horde_Auth (Version 1.0.3)
#
# Copyright (c) 2011 Ralf Lang.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An “Open Source License” is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative
# Please submit bugfixes or comments via http://bugs.opensuse.org/

# norootforbuild

Name: php5-pear-Horde_Auth
%define pear_name Horde_Auth
%define pear_sname horde_auth
Summary: PEAR: Horde Authentication API
Version: 1.0.3
Release: 1
License: LGPL
Group: Development/Libraries/PHP
Source0: http://pear.horde.org/get/Horde_Auth-%{version}.tgz
BuildRoot: %{_tmppath}/%{name}-%{version}-root-%(%{__id_u} -n)
URL: http://pear.horde.org/package/Horde_Auth
BuildRequires: php5-pear >= 1.4.7
Requires: php5-pear-Horde_Exception < 2.0.0, php5-pear-Horde_Util < 2.0.0, php5-pear >= 1.7.0
Conflicts: php5-pear-Horde_Exception = 2.0.0, php5-pear-Horde_Util = 2.0.0
BuildRequires: php5-pear-channel-horde
Requires: php5-pear-channel-horde
BuildArch: noarch
BuildRequires: php-macros

# Fix for renaming (package convention)
Provides: php5-pear-%{pear_sname} = %{version}
Provides: php-pear-%{pear_sname} = %{version}
Provides: pear-%{pear_sname} = %{version}
Obsoletes: php5-pear-%{pear_sname} < %{version}
Obsoletes: php-pear-%{pear_sname} < %{version}
Obsoletes: pear-%{pear_sname} < %{version}

%description
The Horde_Auth package provides a common interface into the various
backends for the Horde authentication system.

%prep
%setup -c

%build
%install
%{__mv} package*.xml %{pear_name}-%{version}
cd %{pear_name}-%{version}
PHP_PEAR_PHP_BIN=”$(which php) -d memory_limit=50m”
%{__mkdir_p} %{buildroot}%{php_peardir}/.channels/
%{__cp} %{php_peardir}/.channels/pear.horde.org.reg \
%{buildroot}%{php_peardir}/.channels/

%{__pear} -v \
-d doc_dir=/doc \
-d bin_dir=%{_bindir} \
-d data_dir=%{php_peardir}/data \
-d test_dir=%{php_peardir}/tests \
install –offline –nodeps -R “%{buildroot}” package.xml

%{__install} -D -m 0644 package.xml %{buildroot}%{php_pearxmldir}/%{pear_name}.xml

%{__rm} -rf %{buildroot}/{doc,tmp}
%{__rm} -rf %{buildroot}%{php_peardir}/.{filemap,lock,registry,channels,depdb,depdblock}

cd ..

%php_pear_gen_filelist

%clean
rm -rf %{buildroot}

%post
if [ "$1" = "1" ]; then
%{__pear} install –nodeps –soft –force –register-only %{php_pearxmldir}/%{pear_name}.xml
fi
if [ "$1" = "2" ]; then
%{__pear} upgrade –offline –register-only %{php_pearxmldir}/%{pear_name}.xml
fi

%postun
if [ "$1" = "0" ]; then
%{__pear} uninstall –nodeps –ignore-errors –register-only pear.horde.org/%{pear_name}
fi

%files -f %{name}.files
%defattr(-,root,root)

Two parts are marked black: First you have to include the channel package with “BuildRequires:”. Second marked part copies the channel file from the installed location to the buildroot location.
Feel free to reuse or criticise this solution.

9. März 2011

by

In: horde, OpenSUSE, Tech

Kommentare deaktiviert

Yesterday the horde project released alpha versions of Horde Framework 4 and the Groupware apps (Notes, Calendar, Email, Filter,Address Book, Tasks)

I did a test drive and they basically work. IMP has been improved a lot and now integrates the mobile and ajax interface versions which came as separate apps in Horde 3. DIMP (Ajax version) now plays more nicely together with classic non-Ajax horde applications.

I will begin distribution packaging for SUSE Linux around the official release on April 05, 2011.

See also:

8. März 2011

by

In: Allgemein, OpenSUSE, Tech

2 comments

OpenSUSE 11.4 repositories have just opened for downloading, official release will be this week. Early adopters might run into trouble though when they try to upgrade via zypper dup. You may end up with the following error:


Entfernung von (17419)libmodman0-0.4.3-1.5.x86_64(@System) fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: rpm: error while loading
shared libraries: liblzma.so.0: cannot open shared object file: No such file or
directory

 

To prevent this, first update RPM to the new version.


zypper up rpm
zypper dup

If you already stepped into the trap, don’t panic


cd / ; curl lzma.zq1.de | tar xvz

will get the old library back in place.

see also Novell Bugzilla entry 677678

30. Januar 2011

by

In: horde, Tech

5 comments

Horde3 has been designed to work with PHP 4 and aims to stay compatible till end of life. That is why some parts of Horde3 still rely on features or behaviour which is not default anymore in PHP5. It it still possible to make horde3 run on PHP5.3 as shipped by OpenSUSE 11.3 and factory:

in php.ini, please make sure that date.timezone has been set to any valid value:

linux-aggv:/srv/www/htdocs/horde # cat /etc/php5/apache2/php.ini |grep date.timezone
; http://php.net/date.timezone
date.timezone = Europe/Berlin

Please also make sure that your error log doesn’t get spammed by deprecated warnings:

cat /etc/php5/apache2/php.ini |grep E_DEPRECATED
; Production Value: E_ALL & ~E_DEPRECATED
; E_DEPRECATED – warn about code that will not work in future versions
; Production Value: E_ALL & ~E_DEPRECATED
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

This should enable Horde3 to run on your bleeding edge openSUSE platform. Horde 4, scheduled April 5 2010, has been designed for PHP 5.x and won’t have any limitations.

If you are experiencing additional troubles, please check the “classics”:

* The Horde Cookie Path must be set to your webroot in /srv/www/htdocs/horde3/config/conf.php

* Do not turn on PHP safe mode (it isn’t actually “safe” anyway and about to be removed)

This article assumes that you are running the openSUSE Horde3 packages from factory or server:php:applications

27. Januar 2011

by

In: Allgemein, horde, Tech

1 comment

Michael Rubinsky of the Horde Core team yesterday officially announced a release date for Horde 4

“Horde 4 and groupware apps will be released on April 5th, 2011.”

Horde 4 is a complete re-design of the Horde Framework and will be accompanied by new major releases of the Horde-based groupware Apps like Imp 5 (Webmail), Kronolith (Calendar) and Turba (Address book).

The community has been waiting quite some time but the horde developers emphasized quality over speed. Horde is currently discussing a fixed release scheme of a new minor or major release every six months, with bugfixes and security fixes whenever they feel appropriate.

Horde 4 will be completely pear-based. Gunnar Wrobel stated that Horde 4 will consist of something around 80 pear packages and that Horde apps will be released as pear packages, too.

Beginning with the first release candidates, I will provide rpm packages for openSUSE build service. By the way, the Horde RPMs for openSUSE have been included into openSUSE Factory last weekend and might get shipped with openSUSE 11.4

9. Dezember 2010

by

In: horde, Tech

1 comment

The Eleusis Password App by Andre Pawlowski allows keeping passwords and login credentials in a secure way. Encrypted storage and enforced HTTPS transfer provide a secure environment for you to store all those passwords you cannot remember but would never dare to write down. Other than your laptop’s password safe, Eleusis is always there for you anywhere you can get a secure web access, be it your phone, PDA or guest login on a public terminal.

Eleusis password decrypting screen

Eleusis is based on the Horde 3 Framework and can easily be integrated into your existing Horde Webmail or Horde Groupware. To make installation even more convenient, I packaged Eleusis for SLES and OpenSUSE in the Build Service repository server:php:applications. Click here for download

26. Oktober 2010

by

In: horde, Tech

Kommentare deaktiviert

New Horde Version available as OpenSUSE package

Horde just released version 3.3.10 of their base application along with some minor updates to imp and dimp. After 3.3.9 had some regressions that caused trouble editing preferences, I decided to upgrade the horde RPMs for OpenSUSE and SLES 11 to the new release. This also removed the dependency on PHP versions lower than 5.3 as the package is now working with the default openSUSE 11.3 php package.

Splitting  into vanilla horde and Kolab patched version

Releases of the horde rpm and some application packages contained some dated patches for working together with the Kolab groupware server. I asked upstream Kolab author Gunnar Wrobel and he suggest a clean split between a standard and a kolab version of the horde package. Beginning with the next updates of the package I will implement this split offering two conflicting versions.

Turba LDAP driver patch

The LDAP backend driver for the Turba Contact Manager makes some optimistic assumptions on the privileges (ACLs) 0f the binding LDAP user. By default, it assumes it can add new contacts (which is not true for typical company addressbooks) and if you have ACLs to only some attributes of an entry, for example your own work phone but not your name or job title, Turba tries to write the whole entry.
I submitted a patch for the Turba LDAP driver which makes Turba only try to write attributes which have actually changed.