That is why we move on to the next topic: Accessing environment variables in Puppet! I searched the Internet for documentation about this specific feature; however, all I found was “this is not a built-in feature of Puppet” and a ruby script which enhances Facter.

That is why we have two “scripts” this time.

Writing the Facter script and Puppet manifest
At first create the file /etc/puppet/modules/customfacts/lib/facter/env.rb:

ENV.each do |k,v|
	Facter.add("env_#{k.downcase}".to_sym) do
		setcode do
			v
		end
	end
end

Then create the Puppet manifest /etc/puppet/manifests/xenuser_org-009-using_environment_variables.pp:

file { "demonstrate_env_var_usage":
	path => "/etc/myenvfile",
	ensure => present,
	mode => 0640,
	content => "Content of env var PWD: $env_pwd",
}

Now let’s see if Facter now collects all the environment variables on the target system:

mintbox manifests # facter |grep env
env__ => /usr/bin/facter
env_colorterm => gnome-terminal
env_display => :0.0
env_home => /root
env_lang => C
env_logname => root
env_mail => /var/mail/root
env_oldpwd => /usr/lib/ruby/vendor_ruby/facter
env_path => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
env_pwd => /etc/puppet/manifests
env_shell => /bin/bash
env_shlvl => 1
env_sudo_command => /bin/su
env_sudo_gid => 1000
env_sudo_uid => 1000
env_sudo_user => valentin
env_term => xterm
env_user => root
env_username => root
env_xauthority => /home/valentin/.Xauthority
env_xdg_session_cookie => af6d4563e613c62d87f9eb7400000008-1360505842.231246-1540805281

Yay! Facter now sees our environment variables. Now let’s move on:

mintbox manifests # puppet apply xenuser_org-009-using_environment_variables.pp
Warning: Could not retrieve fact fqdn
Notice: /Stage[main]//File[demonstrate_env_var_usage]/ensure: created
Notice: Finished catalog run in 0.02 seconds
mintbox manifests # cat /etc/myenvfile
Content of env var PWD: /etc/puppet/manifests

Great, it works! We now can access environment variables within Puppet. Please do not forget that you have to place that ruby script (env.rb) on every Puppet agent system.

Analyzing the Facter script and Puppet manifest
In the first step we created a custom ruby script and placed it on the right location where Facter can find it. Facter runs on every system there the Puppet agent is installed.

Facter now adds the environment variables to the catalogue; that is the reason why we can access our environment variables within Puppet manifests.

The puppet manifest itself is very simple and self-explaining.

Summary
Learning that accessing environment variables is not possible within Puppet manifests was a big disappointment. At least we are able to enhance Facter and help ourselves.

The source of the env.rb script is the old Puppet wiki: http://projects.puppetlabs.com/projects/puppet/wiki/Environment_Variables_Patterns

As usual, you can download all “scripts” from this blog post here: env.rb, xenuser_org-009-using_environment_variables.pp

Related posts:

1. Running shell commands with Puppet
2. Mounting NFS-Shares with Puppet
3. Taking a quick look at the configuration management system Puppet

• RHCE Cheat Sheet
• RHEV/RHCVA

Especially the RHEV/RHCVA cheat sheet is not very comprehensive, but maybe it is still a little helpful when learning for the RHCVA exam. Enjoy!

Related posts:

1. New cheat sheets added
2. Review: RHCSA/RHCE Red Hat Linux Certification Study Guide (Exams EX200 & EX300)
3. Cfengine3: Check for running services

Writing the Cfengine 3 code for performing simple backups

body common control {
        version         => "1.0";
        inputs          => { "cfengine_stdlib.cf" };
        bundlesequence  => { "simple_backup" };
}

body contain cd(dir)    {
        chdir           =>      "${dir}";
        useshell        =>      "true";
}

bundle agent simple_backup {
        vars:
          "backup_dir"          string  => "/var/backups";
          "folder_list"         string  => "/root /etc /usr/local/bin";
          "date"                string  => execresult ("/bin/date +\"%k-%M_%m-%d-%y\"", "noshell");

        files:
          "$(backup_dir)/."
                create  => "true";

        commands:
          "/bin/tar czvf automated_cfengine_backup-$(date).tar.gz $(folder_list)"
                contain => cd($(backup_dir));
}

That’s already it! Now save the snippet as “xenuser_org-019-performing_simple_backups.cf” and apply it:

/var/cfengine/bin/cf-promises -f xenuser_org-019-performing_simple_backups.cf
/var/cfengine/bin/cf-agent -f xenuser_org-019-performing_simple_backups.cf

Great! Let’s have a look at our backup folder:

mintbox backups # ls -lah --color /var/backups
total 219M
drwxr-xr-x  4 root root   4,0K 2013-02-17 22:16 .
drwxr-xr-x 14 root root   4,0K 2013-02-17 20:50 ..
-rw-r--r--  1 root root    36K 2012-10-09 23:08 apt.extended_states.0
-rw-r--r--  1 root root   3,1K 2012-10-01 23:08 apt.extended_states.1.gz
-rw-r--r--  1 root root   3,1K 2012-09-22 23:08 apt.extended_states.2.gz
-rw-r--r--  1 root root   3,1K 2012-08-07 19:20 apt.extended_states.3.gz
-rw-r--r--  1 root root   3,0K 2012-06-20 22:59 apt.extended_states.4.gz
-rw-r--r--  1 root root   3,0K 2012-06-10 19:59 apt.extended_states.5.gz
-rw-r--r--  1 root root     42 2012-06-03 15:06 apt.extended_states.6.gz
-rw-r--r--  1 root root   2,8M 2012-05-09 22:36 aptitude.pkgstates.0
-rw-r--r--  1 root root   288K 2011-11-24 20:12 aptitude.pkgstates.1.gz
-rw-------  1 root root    32M 2013-02-17 21:21 automated_cfengine_backup-21-20_02-17-13.tar.gz

Yay! Cfengine 3 just created a simple backup!

Analyzing the Cfengine 3 code snippet
Well, the first part of the code snippet doesn’t contain any surprises. At first we define the “body common control” which contains a few information about the Cfengine 3 policy file. Afterwards we create another body, but this time a “contain(ment) body” which provides a sandbox for running commands as a non-privileged user inside an isolated directory tree. The “body contain cd(dir)” is needed to define and run a change dir command which can be used later:

body common control {
        version         => "1.0";
        inputs          => { "cfengine_stdlib.cf" };
        bundlesequence  => { "simple_backup" };
}

body contain cd(dir)    {
        chdir           =>      "${dir}";
        useshell        =>      "true";
}

The next section is very simple as it contains only a promise of the type vars. We define a place for storing our backups, a list of folders to be archived and we let Cfengine 3 define a variable which contains the current date:

bundle agent simple_backup {
        vars:
          "backup_dir"          string  => "/var/backups";
          "folder_list"         string  => "/root /etc /usr/local/bin";
          "date"                string  => execresult ("/bin/date +\"%k-%M_%m-%d-%y\"", "noshell");

Now here comes the interesting part. The promise of the type “files” ensures that our directory containing the backups exists. The promise of the type “commands” then runs the command “/bin/tar czvf” which creates a .tar.gz file. “$(folder list) contains the directories to be backed up:

        files:
          "$(backup_dir)/."
                create  => "true";

        commands:
          "/bin/tar czvf automated_cfengine_backup-$(date).tar.gz $(folder_list)"
                contain => cd($(backup_dir));
}

Summary
As you can see, it is very easy to create a backup mechanism within Cfengine 3. However, my sample above lacks a few details:

• The backups are created each time Cfengine 3 runs.
• The backups are stored locally.

It is up to you if you let Cfengine 3 e.g. store the .tar.gz files on a NFS share or let them be transported to another server directly (rsync, scp..).

As usual, you can download today’s Cfengine 3 code snippet here.

Related posts:

1. Creating new symlinks with Cfengine 3
2. Add a new user with Cfengine 3
3. Simple reporting with Cfengine 3

Writing the Puppet manifest for configuring sshd

package	{ "openssh-server":	ensure => "installed" }

service	{ "ssh":		ensure => "running",
				enable => "true",
				require => Package["openssh-server"]
}

augeas { "configure_sshd":
	context	=> "/files/etc/ssh/sshd_config",
	changes	=>	[ 	"set PasswordAuthentication yes",
				"set UsePam yes"
			],
	require	=> Package["openssh-server"],
	notify	=> Service["ssh"]
}

Save the code snippet above as /etc/puppet/manifests/xenuser_org-007-configuring_ssh_or_any_other_service.pp and apply it:

cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.BAK

puppet apply xenuser_org-007-configuring_ssh_or_any_other_service.pp
Warning: Could not retrieve fact fqdn
Notice: /Stage[main]//Augeas[configure_sshd]/returns: executed successfully
Notice: /Stage[main]//Service[ssh]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 1.19 seconds

diff /etc/ssh/sshd_config.BAK /etc/ssh/sshd_config
51c51
< PasswordAuthentication no
---
> PasswordAuthentication yes
87c87
< UsePam no
---
> UsePam yes

As you can see, Puppet just changed some config values in sshd_config and took care of /etc/init.d/ssh.

Analyzing the Puppet manifest
At first we define that there is a package which should be installed. “openssh-server” will be used later as a dependency for editing sshd_config:

package	{ "openssh-server":	ensure => "installed" }

Afterwards, we define that the ssh service should always be running. Please note that we use “ssh” and not “sshd” so Puppet is able to find the init.d script:

service	{ "ssh":		ensure => "running",
				enable => "true",
				require => Package["openssh-server"]
}

Now here comes to most interesting part. We use augeas, a tool which was added after Puppet was already used for a couple of years, for editing the sshd_config file. Please note that we use the “set” command in the “changes” method. Last but not least, we define a dependency (package “openssh-server”) and let augeas trigger a reload of sshd if any changes were applied to the config file:

augeas { "configure_sshd":
	context	=> "/files/etc/ssh/sshd_config",
	changes	=>	[ 	"set PasswordAuthentication yes",
				"set UsePam yes"
			],
	require	=> Package["openssh-server"],
	notify	=> Service["ssh"]
}

Summary
When I compary both the Cfengine 3 and the Puppet snippets with each other, I find the Puppet manifest to be shorter, better readable and somehow more accurate. Everything is linked in the manifest while in Cfengine 3, we simply defined a couple of promised which were processed from line to line.

A disadvantage of Puppet (at least in my eyes) is that there is no direct ability to edit files; in Cfengine 3, you simply do it and have not to use another tool like augeas here.

However, both code snippets do the job. As usual, you can download today’s Puppet manifest here.

Related posts:

1. Configuring SSHd (or any other service) with Cfengine 3
2. Installing packages with Puppet
3. Puppet: Ensure pre-defined services are running

Writing the Puppet manifest for running a shell command

exec { "start_mysql":
	command	=> "/etc/init.d/mysql start"

	# Here you could also use require
	# require	=> Package["mysql-server"]

	# Another important feature would be setting the path variable
	# path	=> "/usr/local/bin:/bin/"
}

Now let’s apply the manifest and verify the result:

/etc/init.d/mysql stop

ps aux |grep mysql
root     12366  0.0  0.0   4384   832 pts/0    S+   15:48   0:00 grep
--colour=auto mysql

puppet apply xenuser_org-006-running_shell_commands.pp
Warning: Could not retrieve fact fqdn
Notice: /Stage[main]//Exec[start_mysql]/returns: executed successfully
Notice: Finished catalog run in 2.25 seconds

ps aux |grep mysql
mysql    12611  2.7  0.9 318512 34604 ?        Ssl  15:48   0:00
/usr/sbin/mysqld
root     12833  0.0  0.0   4384   836 pts/0    S+   15:48   0:00 grep
--colour=auto mysql

There you go – MySQL is up and running.

Summary
I think that executing shell commands directly via a Puppet manifest is not very “clean”, but sometimes you have no other option. I like that the function for doing so is called “exec” and that there are a lot of cool and useful parameters for it:
http://docs.puppetlabs.com/references/stable/type.html#exec

Compared to Cfengine 3, I am missing the “comment” which will appear in the syslog. However, the code in Puppet is much shorter.
As usual, you can download today’s Puppet manifest for executing a shell command here.

Related posts:

1. Running shell commands with Cfengine 3
2. Puppet: Ensure pre-defined services are running
3. Configuring sshd with Puppet

While the fifth part in my Cfengine 3 blog series was about managing apt sources lists with Cfengine 3, this blog post will cover the same topic except that we use Puppet instead of the other configuration management tool from Oslo, Norway.

Writing the Puppet manifest for managing apt sources.list files

include apt

apt::source { "puppetlabs_precise":
        location        => "http://apt.puppetlabs.com/",
        release         => "precise",
        repos           => " main",
        include_src     => false
}

apt::source { "ubuntu_archiv_precise":
        location        => "http://archive.ubuntu.com/",
        release         => "precise",
        repos           => "main restricted universe multiverse",
        include_src     => false
}

apt::source { "ubuntu_archiv_precise-updates":
        location        => "http://archive.ubuntu.com/",
        release         => "precise-updates",
        repos           => "main restricted universe multiverse",
        include_src     => false
}

apt::source { "ubuntu_archiv_precise-security":
        location        => "http://archive.ubuntu.com/",
        release         => "precise-security",
        repos           => "main restricted universe multiverse",
        include_src     => false
}

apt::source { "canonical_archiv_precise":
        location        => "http://archive.canonical.com/ubuntu/",
        release         => "precise",
        repos           => "partner",
        include_src     => false
}

apt::source { "linuxmint_maya":
        location        => "http://packages.linuxmint.com/",
        release         => "maya",
        repos           => "main upstream import",
        include_src     => false
}

The sample above will only work with the official apt module from Puppetlabs, so make sure you install it before you run the Puppet manifest:

puppet module install puppetlabs/apt
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ puppetlabs-apt (v1.1.0)
  └── puppetlabs-stdlib (v3.2.0)

puppet apply /etc/puppet/manifests/xenuser_org-005-managing_apt_sources_lists.pp

What now happens is that Puppet creates a bunch of files in /etc/apt/sources.list.d/ and runs apt-get update.
Lets verify that our Puppet manifest works:

cd /etc/apt/sources.list.d
ls -la
total 40
drwxr-xr-x 2 root root 4096 Feb  3 20:48 .
drwxr-xr-x 7 root root 4096 Feb  3 20:48 ..
-rw-r--r-- 1 root root   84 Feb  3 20:42 canonical_archiv_precise.list
-rw-r--r-- 1 root root   78 Feb  3 20:42 linuxmint_maya.list
-rw-r--r-- 1 root root   50 Jun 20  2012 local-repository.list
-rw-r--r-- 1 root root   49 Jun 20  2012 local-repository.list.save
-rw-r--r-- 1 root root   66 Feb  3 20:42 puppetlabs_precise.list
-rw-r--r-- 1 root root   99 Feb  3 20:42 ubuntu_archiv_precise.list
-rw-r--r-- 1 root root  117 Feb  3 20:42 ubuntu_archiv_precise-security.list
-rw-r--r-- 1 root root  115 Feb  3 20:42 ubuntu_archiv_precise-updates.list

Go ahead and have a look at those files

Analyzing the code snippet and summary
Instead of editing the file /etc/apt/sources.list directly (like I did in the Cfengine 3 version of this code snippet), we let Puppet create single sources.list files for every “apt source”. The downside of this approach is that we have to define a “release” for each “section” of the same release name (e.g. precise, precise-updates…).

While this is definitely a good and clean approach for managing apt sources.list files, we now have more complexity in comparison to the single file approach. However, I think that using the apt Puppet module is the right way to do it.

As usual, you can download today’s Puppet manifest here.

Update from February 10th, 2013:
As Jean Rémond suggested in the comment below, you could also use “${::lsbdistcodename} instead of directly naming the distri version name, such as precise. However, in my example, using this variable brought “lisa” as the result (although my Linux Mint was updated from version 12 “Lisa” to version 13 “Maya”).
Here is the code snippet I used:

apt::source { "test":
        location        => "http://test.test.com/",
        release         => "${::lsbdistcodename}",
        repos           => "main upstream import",
        include_src     => false
}

There might be a better way than writing “precise” or “maya” directly into the Puppet manifest; maybe I’ll cover that in another blog post.

Related posts:

1. Managing APT sources.lists with Cfengine 3
2. Running shell commands with Puppet
3. Using environment variables in Puppet

Writing the Puppet code snippet for mounting a NFS share

mount { "/mnt":
        device  => "localhost:/blubb",
        fstype  => "nfs",
        ensure  => "mounted",
        options => "defaults",
        atboot  => "true",
}

Save the file as /etc/puppet/manifests/xenuser_org-004-mounting_a_nfs_share.pp and let it run:

ls -lah --color /mnt
total 8,0K
drwxr-xr-x  2 root root 4,0K 2012-05-10 22:36 .
drwxr-xr-x 23 root root 4,0K 2012-08-20 22:04 ..

puppet apply xenuser_org-004-mounting_a_nfs_share.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Mount[/mnt]/ensure: defined 'ensure' as 'mounted'
notice: /Stage[main]//Mount[/mnt]: Triggered 'refresh' from 1 events
notice: Finished catalog run in 0.18 seconds

As you can see, Puppet claims that the provided NFS share was mounted. Let’s verify that:

grep blubb /proc/mounts
localhost:/blubb/ /mnt nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,minorversion=0,local_lock=none,addr=127.0.0.1 0 0

ls -lah --color /mnt
total 8,0K
drwxr-xr-x  2 root root 4,0K 2012-05-10 22:36 .
drwxr-xr-x 23 root root 4,0K 2012-08-20 22:04 ..
-rw-r--r--  1 root root    0 2012-05-10 22:36 blobb

Great!

Summary
Mounting the NFS share via Puppet was easy. In addition, Puppet added a new entry in /etc/fstab:

cat /etc/fstab
# HEADER: This file was autogenerated at Sat Jan 19 21:27:19 +0100 2013
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc	/proc	proc	nodev,noexec,nosuid	0	0
# / was on /dev/sda1 during installation
UUID=f89cb605-8324-424f-9a0c-c555e7e0e779	/	ext4,acl	errors=remount-ro	0	1
# swap was on /dev/sda5 during installation
UUID=a66917ea-c89b-4067-80ec-7c13f0a4bd1c	none	swap	sw	0	0
localhost:/blubb	/mnt	nfs	defaults	0	0

There is also a way to add an entry to the fstab file with Cfengine 3 but unfortunately I did not cover it in my blog entry about mounting NFS shares with Cfengine 3.

When comparing both the Cfengine 3 and Puppet snippets with each other, I do not see which configuration management tool does it the more effective or easy way. Both do a good job when looking at the amount of lines you need to write for this purpose. However, one could argue that Puppet does the job a little bit better since you can directly provide the info if the NFS share should be mounted at boots or not (fstab entry).

As usual, you can download today’s Puppet manifest here.

Related posts:

1. Mounting NFS-Shares with Cfengine 3
2. Managing APT sources.lists with Puppet
3. Performing simple Backups with Cfengine 3

Writing the Puppet manifest for installing new packages

# There are multiple possibilities here, 3 of them are shown here
# Possibility #1
# package { "slapd":            ensure  => "installed" }
# package { "ldap-utils":       ensure  => "installed" }

# Possibility #2
# Package {                     ensure => "installed" }
# package { "slapd": }
# package { "ldap-utils": }

# Possiblity #3
 $packagesToBeInstalled = [ "slapd", "ldap-utils" ]
 package { $packagesToBeInstalled:      ensure => "installed"

I saved the Puppet code snippet above as /etc/puppet/xenuser_org-003-ensure_packages_are_installed.pp and ran it with…

puppet apply xenuser_org-003-ensure_packages_are_installed.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Package[slapd]/ensure: created
notice: /Stage[main]//Package[ldap-utils]/ensure: ensure changed 'purged' to 'present'
notice: Finished catalog run in 18.09 seconds

On my Linux Mint box I can verify that these packages got installed with…

dpkg -l |grep slapd
ii  slapd                                  2.4.25-1.1ubuntu4.1                     OpenLDAP server (slapd)
dpkg -l |grep ldap-utils
ii  ldap-utils                             2.4.25-1.1ubuntu4.1                     OpenLDAP utilities

Some words on the code
One link I found showed me that there are several ways of installing packages with Puppet. The most simple and straight forward way is this one:

package { "slapd":            ensure  => "installed" }
package { "ldap-utils":       ensure  => "installed" }

The second possibility of installing new packages could be this one:

Package {                     ensure => "installed" }
package { "slapd": }
package { "ldap-utils": }

I think it is not 100% self-explaining, but still easy to adapt to your needs.
Another way, similar to the one I used in the Cfengine 3 snippet:

$packagesToBeInstalled = [ "slapd", "ldap-utils" ]
package { $packagesToBeInstalled:      ensure => "installed" }

I like this way the most. You first define an array containing the packages to be installed and then use the array in the “package” method. Awesome!

Summary
Again I am surprised in a positive way; the Puppet code is even shorter than the Cfengine 3 code snippet, but still performing the same task.

As usual you can download today’s Puppet manifest here.

Related posts:

1. Installing packages with Cfengine 3
2. Configuring sshd with Puppet
3. Puppet: Ensure pre-defined services are running

Today we are re-writing the Cfengine 3 code snippet which ensured that a list of pre-defined services are running.

Writing the Puppet code snippet for ensuring that those services are running

service { "apache2":
        ensure  => "running",
}

service { "mysql":
        ensure  => "running",
}

Save the code above as /etc/puppet/manifests/xenuser_org-002-ensure_processes_are_running.pp and execute it:

puppet apply xenuser_org-002-ensure_processes_are_running.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Service[mysql]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]//Service[apache2]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 1.35 seconds

On my box (Linux Minth 12), Apache2 and MySQL were both installed and not running. Applying the Puppet manifest started those services again. You might have to adjust the code for your local Linux test box.

Analyzing the Puppet manifest
There is not much to do in terms of analyzing the code snippet above. It is very short and simple. I like that.
One could argue that it would be better to define a list of services and apply the “ensure -> running” part on the list while iterating through it. However, the approach above is sufficient.

By the way, Puppet supports a notifying method which listens on changes of a specified config file of a specific service. If the config file is changed, the correct service will be restarted.

Summary
In comparison to the Cfengine 3 snippet we had to write less “code” and achieved the same result. What I liked most was that I did not have to provide the path to the init scripts.

As usual, you can download today’s Puppet manifest here.

Related posts:

1. Configuring sshd with Puppet
2. Installing packages with Puppet
3. Running shell commands with Puppet

Anfang November 2010 schaffte ich mir das damals brandneue HTC Desire Z bei O2 an (ich “bloggte”). Damals sprach vor allem die Hardware-Tastatur für das Gerät, obwohl es mit 560 Euro recht teuer war.

Immernoch zufrieden!
Nach 2 Jahren und knapp 3 Monaten fällt mein Fazit immer noch sehr positiv aus: Das Gerät weist zwar deutliche Gebrauchsspuren an der Hülle auf, ist aber immernoch in Takt. Der Akku hält gefühlt noch genauso lange wie zu Beginn und der Slide-Mechanismus des Keyboards ist kein bisschen abgenutzt.

Leider ging mir im April 2011 das Display kaputt, was jedoch gegen 140 Euro Gebühr von einem Münchner Unternehmen ausgetauscht wurde.

Einziges Manko: Android
HTC hat als letzte Android-Version 2.3.3 für das Desire Z veröffentlicht. Während ich auch ohne Android 3/4 auskomme, stört mich doch, dass das Handy schon beim Starten von wenigen Apps anfängt zu ruckeln. Ab und an erscheint zusätzlich ein weißer Bildschirm mit dem HTC-Schriftzug, was einem “Reload” gleich kommt. Während dieser Zeit kann ich das Gerät fast nicht bedienen – ungünstig! Selbst die Deinstallation von nicht mehr benötigten Apps und das Löschen von Daten bringt keine Besserung (vermutlich hilft nur ein vollständiger Reset, aka “Neuinstallation”).

2 Jahre – und nun?
Da das Gerät langsam in die Jahre kommt, sehe ich mich gerade nach einem möglichen Nachfolger um. Leider haben jedoch HTC und andere Hersteller kein Interesse mehr an der Veröffentlichung von Smartphones mit HW-Tastaturen – ohne eine solche Erweiterung möchte ich jedoch kein Handy bedienen. Derzeit gibt es Gerüchte, wonach Samsung eine Variante vom Galaxy S3 mit HW-Tastatur veröffentlichen möchte, allerdings wird da vermutlich der Bildschirm kleiner als beim “Original” ausfallen.

Mal sehen, was 2013 auf den Markt kommt!

Related posts:

1. HTC Desire Z mit Android 2.2 (Froyo): Erster Eindruck
2. The best games for Android 2.2 (Froyo) running on a HTC Desire Z
3. Xen ported to ARM architecture