Posts Tagged ‘PHP’

23. Juli 2014

by

In: Allgemein, OpenSUSE, Tech

3 comments

For more than 10 years, PHP core developers repeatedly raised the topic of providing a formal language specification for PHP. Now a team of facebook employees has written such a specification. The spec document is currently only available as a preview chapter a preview chapter . PHP veteran Sara Golemon announced on the „PHP internals“ list that the full document will be ready for O’Reilly’s OSCON 2014. Sara Golemon published the standard book on „Extending and Embedding PHP“ some years ago and now works for Facebook’s own PHP implementation HHVM. The PHP spec defines PHP version 5.6 in about 200 pages and contains all the odd and obscure quirks of the language core. Facebook’s own HHVM aims to be as close to the spec as possible. Currently, PHP developers discuss how amending the spec can become a mandatory part of the language development process. Though some are sceptic that all developers will embrace the change in the process, everybody on the list was happy to have the new document.

Software Architect Stas Malyshev:

Thank you Sara and Facebook team for doing something we’ve been talking
about for more than a decade and before that nobody actually attempting
to do. I think it is a great development and I hope to see the first
version soon.

http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf

23. Juli 2014

by

In: Tech

Kommentare deaktiviert für Sara Golemon (Facebook) kündigt PHP Language Specification auf OSCON 2014 an

Seit über 10 Jahren bringen immer wieder einige der PHP-Sprachentwickler den Plan an, eine formale Spezifikation für den Sprachkern bereitzustellen. Ein Team bei Facebook hat das nun getan. Die Spezifikation, die bisher nur als Vorschau vorliegt, wurde von Sara Golemon auf der Entwickler-Liste angekündigt und soll auf der OSCON 2014 vorgestellt werden. Sara Golemon veröffentlichte schon vor einigen Jahren ein Standardwerk über die Entwicklung von PHP-Erweiterungsmodulen und arbeitet mittlerweile an Facebooks eigener PHP-Version HHVM.

Das rund 200 Seiten starke Dokument orientiert sich an der PHP-Version 5.6 und enthält auch obskure Verhaltensweisen des PHP-Sprachkerns in seltenen Randfällen. Die Facebook-eigene PHP-Version HHVM soll sich möglichst eng an diese Vorgaben halten.

Die PHP-Community berät derzeit, wie sie die Fortschreibung der Spezifikation in den Entwicklungsprozess einbinden kann. Die Ankündigung wurde mit viel Begeisterung aufgenommen.

Software-Architekt Stas Malyshev:

Thank you Sara and Facebook team for doing something we’ve been talking
about for more than a decade and before that nobody actually attempting
to do. I think it is a great development and I hope to see the first
version soon.

http://dl.hhvm.com/resources/PHPSpec-SneakPeak.pdf

12. August 2013

by

In: OpenSUSE, Tech

Kommentare deaktiviert für I managed to bring large file uploads into PHP 5.6

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.

14. Dezember 2012

by

In: OpenSUSE, Tech

5 comments

In a recent developer vote, the php project decided to deprecate the mysql extension in PHP 5.5 and finally remove it from the main PHP project. It may or may not be available for a longer period as a PECL extension.

The mysql extension has long been superseded by two more powerful extensions, PDO/Mysql and mysqli (improved). For years, the older extension has not received any new features and the developers kept it around just to keep compatibility with old code. Framework and application developers are now urged to update their code to use one of the alternative mysql APIs. There are a lot of old code snippets and tutorials around which describe the old API. Eventually, this code will begin to throw warnings and finally stop to work.

Developers discussed the impact of this move on end users. While it might be shocking to see hordes of old installations break just because the hoster updates his PHP version, there is no need to panic. Most hosters have not even upgraded to the recent PHP 5.4 release and it might be years to go until PHP 5.6 finally hits enterprise distributions like SLES or RHEL. Additionally, distributors and hosters might opt to provide the PECL version of the mysql extension for backward compatibility. There is enough time left for developers and end users to react on the coming change.

More on the deprecation vote

10. Juli 2012

by

In: horde, Tech

Kommentare deaktiviert für Horde 5 enters release cycle – First Alpha of Sesha Inventory App available

All’s well that ends well. During the last few days, the first alpha releases of the Horde Framework and some of its core apps hit the announcement list. Horde 5 sports a completely revamped user interface which allows a much tighter integration of the portal dashboard, ajax mode applications like the IMP Webmailer or traditional mode applications (whups ticketing etc).

Horde 5 has a completely renewed user interface (Image shows the IMP 6 webmailer)

While IMP, turba and the Ingo Mailfilter are already available as alpha packages, the calendar (kronolith) is not yet done.

However, today Horde release the first alpha version of the sesha inventory app. I have been working on sesha and related packages since horde 4, but things dragged on.

Sesha allows to organize any kind of items in a searchable inventory. First you have to define properties like age, weight, length or location of an item.

A defined group of properties makes up a category, something like an inventory type: Books, DVDs, network interfaces or computer monitors all have very different sets of properties. With sesha, there is no limit on the things you can put into your catalog. Just create categories of properties and finally add stock.

Sesha has been released under the GNU General Public License and may be used free of charge.

19. März 2012

by

In: Tech

Kommentare deaktiviert für PHP goes git

Today the main PHP development branch has moved to the git version control system. In the past, PHP has been developed on cvs and svn. The move to git is very common these days. Git is, for example, the version control system used by the linux kernel developers and the Horde Application Framework.

PHP uses the github infrastructure for the public repository, which currently holds 52 branches. It will be interesting to see how they will convert their commit email script to git.

The public PHP git repository is available under http://github.com/php/php-src

15. März 2012

by

In: OpenSUSE

Kommentare deaktiviert für php5.3 packages in SLES 11 SP2

SLES 11 SP2 ships php5.3 binaries but the default package php5 still installs php5.2 which already has reached upstream end of life and should be considered unsupported by any means. Recent versions of phpunit and other developer tools won’t provide all features on php5.2 any more.
You must use apache2-mod_php53, php53, php53-mysql and so on if you want to use php on SLES.

2. März 2012

by

In: horde, OpenSUSE

Kommentare deaktiviert für Installing Horde 4 pear packages to a custom pear location (SUSE)

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.

18. Februar 2012

by

In: Allgemein, horde, Tech

Kommentare deaktiviert für Distributed applications with Horde 4

Synopsis

Horde’s powerful RPC API has been used numerous times to allow integration of horde-based data into external applications or remote sites. It also provides an easy to set up basis for distributed applications with headless workers. In this article I will give you a brief introduction on how to build a scalable distributed architecture based on Horde 4.

Distributed Architecture

Assumptions:

  •  You want your application to be scalable over several hosts. We call the controlling instance the master and the reacting instances the workers.
  •  You don’t want to keep a lot of state on the worker. Adding or removing a worker instance should not require complicated setup. Most cloud layers like OpenStack assume worker instances to be virtually stateless. The master is the single source of truth and should be able to rebuild any broken or lost worker setup from stored information.
  • You are working in a hostile environment, e.g. the internet. Firewall only allows select ports and data has to travel over lines you cannot trust. You want to resort to https transport with real certificates.

The master:

I won’t go into too many  details on the master setup this time. Create a basic app from the skeleton as the horde wiki describes. Separate a communication driver for worker Api calls from the driving logic in your app and don’t couple them too tightly. Usually you want small commits of changes to both the master’s idea and the worker’s reality and you want to check back if everything worked out. This doesn’t scale well on large-scale changes though.

Sometimes you want to make complex changes to the „truth“ or „theory“ in the master’s db before you commit them to the worker world out there.

Accessing the worker from the master:

The core piece of your communication with the worker are just a few lines of code

   protected function callWorker(WorkerInstance $worker, $callMethod, array $parameters = array()) {
       try {
            $http = new Horde_Http_Client(array('request.username' => $worker->rpcuser, 'request.password' => $worker->rpcuserpass, 'request.timeout' => 20 ));
            $response = Horde_Rpc::request(
                    'xmlrpc',
                    'https://' . $worker->worker_hostname . '/' . $worker->worker_subdir .'/rpc.php',
                    $callMethod,
                    $http,
                    array($parameters)
            );
        }
        catch (Exception $e) {
            throw new Appname_Exception($e);
        }
        return $response;
    }

This is a dumbed down version for demonstration purposes. You might want to model WorkerInstance based on Horde_Rdo, the horde ORM layer. It is desirable to evaluate lazy relations and lazy attributes. This has important performance implications but more on this in another post. We’re also selling consulting 😉

Worker setup:

We want a stateless worker instance. Obviously, this is theory. Truth is: You need a unique IP and you probably want a unique hostname. Nowadays cloud layers can provide that level of configuration. How about a horde instance without db?

horde/config/registry.local.php

You want the worker to talk under a specific api name. Add a block to your registry.local.php

 'myvpnworkerworker' => array (
        'name' => _("someworkerfooname"), /* we can even drop the _() as nobody will localize this */
        'provides' => 'myvpnworkerapp',
    )

horde/config/conf.php

This is stripped down to just the important lines
$conf['auth']['params']['htpasswd_file'] = '/not/in/webroot/passwords.secret';
 $conf['auth']['params']['encryption'] = 'plain'; /* In real world, you want to use some encryption instead */
 $conf['auth']['driver'] = 'http'; /* We want authentication by http layer after all */

We want the server to be stateless and not to rely on external data. We don’t want a local mysqld running and we don’t want a remote ldap either. We will store the credentials in a .htpasswd style file. For demonstration purposes, we use plain authentication.

The file would look like this:

passwd.passwd would look like this: 

rpcuser:totallysecretrpcuserpass
adminuser:adminpass
localdebuguser:secretlocaldebugpass

We also want to get rid of any components which cannot work without an sql backend

$conf['log']['priority'] = 'DEBUG';
$conf['log']['ident'] = 'HORDE';
$conf['log']['name'] = LOG_USER;
$conf['log']['type'] = 'syslog';
$conf['log']['enabled'] = true;
$conf['log_accesskeys'] = false;

As the worker will probably only show the admin UI to localhost or VPN, you want to log any debug relevant data locally into a file
$conf['prefs']['driver'] = 'Session';
$conf['alarms']['driver'] = false;

We don’t want user prefs or alarms on the worker. You might consider setting up some basic email delivery and sending alarms by mail. I won’t cover this here.

$conf['datatree']['driver'] = 'null';
$conf['group']['driver'] = 'Mock';

Datatree support is sql-only. Datatree is mostly legacy support and it isn't particularly fast either. There is no guarantee future horde revisions will support datatree. You don't want it. Period. You don't want groups either. The primary user of your instance is the RPC user.
$conf['perms']['driver'] = 'Null'

Only the master speaks to your worker and this must be ensured on the ssl/https layer. No need for a perms backend

$conf['cache']['driver'] = 'File';

If we use caching at all, we want to use a primitive one.

$conf['lock']['driver'] = 'Null';
$conf['token']['driver'] = 'Null';

Horde_Locks is a cool library. Ben Klang wrote it in 2008 when I was working in a non-public project that needed it and I mailed some stuff to him. But it’s sql-only. We don’t want it here.
Horde_Tokens are essential for a lot of verification tasks but the worker is not the single source of truth.

$conf['vfs']['type'] = 'File';

You probably don’t want a vfs at all. Vfs means state.

$conf['sessionhandler']['type'] = 'Builtin';

Anything but sql. You probably don’t want sessions.

This should be the key parts to make your stock horde installation not want a database at all.

The RPC Worker app.

The key to your RPC worker app is Api.php

This is the entry point for any Horde RPC calls.

Basically it works this way:

  • The upper layer of array() is internal to the horde rpc request layer
  • In our client example we wrapped our params into an additional array() to facilitate optional parameters. This means any method in Api.php accepts an array as the single parameter. You could also use a fixed list of parameters with optionals in the rear positions.
  • While the horde registry calls applications apis as ‚domain/function‘, the rpc api calls them as domain.function. Examples are horde.listApis and myvpnapp.fetchData

Any function  you can call from the outside is a method in Fooworkername_Api in Fooworkername/lib/Api.php.

Concurrency and queueing:

Horde is written in PHP. PHP is generally lacking in thread safety and doesn’t support real forking from within an apache module. You can however fork and detach processes using shell_exec. Horde ships some classes which help you use PHP in a shell environment but sometimes you want to resort to shell scripts or perl or anything else because it already exists or is more suitable to the job. shell_exec allows you use all of these. Usually you want your api calls to return fast. This doesn’t scale well. Make sure your individual call usually finishes in predictable worst case scenarios in 1/3 of the client’s response timeout. In our example we chose 20 seconds for timeout. Mind network latency and external script worst case runtime.

The solution here is decoupling:

  • Don’t make any UI element depend on live data from the worker
  • make a service/daemon or cron job collect worker state at short intervals and serialize these data points in time stamped files or directories
  • Create an api entry point to collect most recent state/results
  • Collect results of all workers from a commandline script, daemon, cron job or service in reasonable sequences.
  • Don’t expect most tasks immediately but add them to a queue. Horde_Queue may help you with that task.

Choose wisely where to call existing external apps and where to resort to PHP and the Horde Framework to solve common data collection, processing, formatting and returning tasks.

Remember to have fun.

The author is severly biased towards all things horde and has used horde classes and applications to solve various work-for-hire problems. The Horde Framework is one of the oldest and mature php projects and drives mission critical collaboration and data retrieval software all over the globe.

28. August 2011

by

In: Tech

1 comment

Don’t forget: when you change pear settings as root, usually you want to set values in the system pear config, not in root’s personal config. The crucial third parameter is optional and defaults to ‚user‘. We want ’system‘ instead

pear config-set test_dir /usr/share/php/tests systems

verify:
pear config-show

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 für Howto: Packaging 3rd party pear channel software with %php_pear_gen_filelist macro

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.

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