Horde

The passwd app is a password management/changing utility for Horde which normally lives in a menu „my account“ in the toolbar. While it has been released and is in production use at many sites, it is also under development to expand and improve the ... [More] module. Passwd provides fairly complete support for changing passwords via Poppassd, LDAP, Unix expect scripts, SMB/CIFS (under unix), Kolab, ADSI, Pine, Serv-U FTP, VMailMgr, vpopmail, SQL passwords and other more complicated setups.For a certain horde 5 installation, I needed to move the passwd app under the gearwheel/settings menu and out of the toolbar. After setting up passwd to work correctly, I added only one line to the registry.local.php file: applications['passwd']['menu_parent'] = 'settings'; ?> Everything you put into the menu labelled „settings“ automatically appears in the gearwheel menu. [Less]

The passwd app is a password management/changing utility for Horde which normally lives in a menu “my account” in the toolbar. While it has been released and is in production use at many sites, it is also under development to expand and improve the ... [More] module. Passwd provides fairly complete support for changing passwords via Poppassd, LDAP, Unix expect scripts, SMB/CIFS (under unix), Kolab, ADSI, Pine, Serv-U FTP, VMailMgr, vpopmail, SQL passwords and other more complicated setups.For a certain horde 5 installation, I needed to move the passwd app under the gearwheel/settings menu and out of the toolbar. After setting up passwd to work correctly, I added only one line to the registry.local.php file: applications['passwd']['menu_parent'] = 'settings'; ?> Everything you put into the menu labelled “settings” automatically appears in the gearwheel menu. [Less]

Now that Horde Groupware 5 has been released as stable software, a lot of users noticed the shortcomings of the PEAR packaging systems. It does not provide an easy and smooth way to upgrade Horde 4 to the latest bugfix version anymore. If you run ... [More] Horde 4 apps that have not been ported for Horde 5 yet, you need to be very cautious which pear commands you run. A simple pear upgrade -c horde would break your existing installation because it would upgrade everything to the most recent major version. This is not desirable for production systems. Distribution packaging is the solution to this. Receive only compatible upgrades until you decide to do a major upgrade. Distribution packages of Horde 5 are available for openSUSE and SUSE Linux Enterprise Server from the isv:B1-Systems:Horde5:rolling project. These packages include development snapshots of unreleased applications like Passwd for Horde 5. They have been modified to fit into the distribution specific standard directories, install regular jobs the distribution way etc. For example, the distribution apps don’t have separate .htaccess files but provide a ready-to-run apache2 vhost config. Under debian however, nobody stepped up to help the main debian horde packager, Mathieu Parent, to finish the Horde 5 packages in time. This means, the next stable Debian release will probably not include Horde 5. I have talked to Mathieu and built a patch for the Open Build Service which facilitates PEAR packaging for debian targets. You can see the progress of debian packaging by adding the Debian repository of the project to your /etc/apt/sources.list file cd /root/ echo "deb http://widehat.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0 ./" >> /etc/apt/sources.list wget http://download.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0/Release.key apt-key add Release.key apt-get update As of today, the repository only contains php-horde-autoloader but it I aim to fill it with all ~ 100 Horde pear packages (minus the bundles). If you need business critical, supported Horde 4 or Horde 5 packages for openSUSE/SLES, Redhat/CentOS, Debian, Ubuntu or special architectures like ARM or Itanium, don’t wait for community action but ask for a commercial solution. [Less]

Now that Horde Groupware 5 has been released as stable software, a lot of users noticed the shortcomings of the PEAR packaging systems. It does not provide an easy and smooth way to upgrade Horde 4 to the latest bugfix version anymore. If you run ... [More] Horde 4 apps that have not been ported for Horde 5 yet, you need to be very cautious which pear commands you run. A simple pear upgrade -c horde would break your existing installation because it would upgrade everything to the most recent major version. This is not desirable for production systems. Distribution packaging is the solution to this. Receive only compatible upgrades until you decide to do a major upgrade. Distribution packages of Horde 5 are available for openSUSE and SUSE Linux Enterprise Server from the isv:B1-Systems:Horde5:rolling project. These packages include development snapshots of unreleased applications like Passwd for Horde 5. They have been modified to fit into the distribution specific standard directories, install regular jobs the distribution way etc. For example, the distribution apps don’t have separate .htaccess files but provide a ready-to-run apache2 vhost config. Under debian however, nobody stepped up to help the main debian horde packager, Mathieu Parent, to finish the Horde 5 packages in time. This means, the next stable Debian release will probably not include Horde 5. I have talked to Mathieu and built a patch for the Open Build Service which facilitates PEAR packaging for debian targets. You can see the progress of debian packaging by adding the Debian repository of the project to your /etc/apt/sources.list file cd /root/ echo "deb http://widehat.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0 ./" >> /etc/apt/sources.list wget http://download.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0/Release.key apt-key add Release.key apt-get update As of today, the repository only contains php-horde-autoloader but it I aim to fill it with all ~ 100 Horde pear packages (minus the bundles). If you need business critical, supported Horde 4 or Horde 5 packages for openSUSE/SLES, Redhat/CentOS, Debian, Ubuntu or special architectures like ARM or Itanium, don’t wait for community action but ask for a commercial solution. [Less]

Now that Horde Groupware 5 has been released as stable software, a lot of users noticed the shortcomings of the PEAR packaging systems. It does not provide an easy and smooth way to upgrade Horde 4 to the latest bugfix version anymore. If you run ... [More] Horde 4 apps that have not been ported for Horde 5 yet, you need to be very cautious which pear commands you run. A simple pear upgrade -c horde would break your existing installation because it would upgrade everything to the most recent major version. This is not desirable for production systems. Distribution packaging is the solution to this. Receive only compatible upgrades until you decide to do a major upgrade. Distribution packages of Horde 5 are available for openSUSE and SUSE Linux Enterprise Server from the isv:B1-Systems:Horde5:rolling project. These packages include development snapshots of unreleased applications like Passwd for Horde 5. They have been modified to fit into the distribution specific standard directories, install regular jobs the distribution way etc. For example, the distribution apps don’t have separate .htaccess files but provide a ready-to-run apache2 vhost config. Under debian however, nobody stepped up to help the main debian horde packager, Mathieu Parent, to finish the Horde 5 packages in time. This means, the next stable Debian release will probably not include Horde 5. I have talked to Mathieu and built a patch for the Open Build Service which facilitates PEAR packaging for debian targets. You can see the progress of debian packaging by adding the Debian repository of the project to your /etc/apt/sources.list file cd /root/ echo "deb http://widehat.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0 ./" >> /etc/apt/sources.list wget http://download.opensuse.org/repositories/isv:/B1-Systems:/Horde5:/rolling/Debian_6.0/Release.key apt-key add Release.key apt-get update As of today, the repository only contains php-horde-autoloader but it I aim to fill it with all ~ 100 Horde pear packages (minus the bundles). If you need business critical, supported Horde 4 or Horde 5 packages for openSUSE/SLES, Redhat/CentOS, Debian, Ubuntu or special architectures like ARM or Itanium, don’t wait for community action but ask for a commercial solution. Truncated by Planet Horde, read more at the original (another 541 bytes) [Less]

-------- Original-Nachricht -------- Betreff: [announce] End Of Life for Horde 3 Datum: Tue, 27 Nov 2012 13:21:17 +0100 Von: Jan Schneider Antwort an: [email protected] An: [email protected], [email protected], [email protected] ... [More] The Horde Team is announcing the End Of Life (EOL) for the Horde 3 release series. With the final release of Horde 5 the state of the following release series is updated: Horde 3: EOL Horde 4: Security Fixes Horde 5: Bug Fixes Please see http://wiki.horde.org/Doc/Dev/ReleaseCycle for details about the Horde release cycle and http://www.horde.org/development/versions for the affected applications. Horde 3 had been a huge milestone in Horde's history and has served us well for 8 long years. We really hope you enjoyed it too. We know it's still in use in many, many places, and we like to encourage everyone to upgrade to the latest version which is such a huge improvement over the now outdated Horde 3 line. Thank you, Horde 3, and thank you, everyone who made it such a great success! I do agree with Jan that Horde 3 had a great time and anybody still using it should migrate to Horde 4/5 soon. [Less]

-------- Original-Nachricht -------- Betreff: [announce] End Of Life for Horde 3 Datum: Tue, 27 Nov 2012 13:21:17 +0100 Von: Jan Schneider Antwort an: [email protected] An: [email protected], [email protected], [email protected] ... [More] The Horde Team is announcing the End Of Life (EOL) for the Horde 3 release series. With the final release of Horde 5 the state of the following release series is updated: Horde 3: EOL Horde 4: Security Fixes Horde 5: Bug Fixes Please see http://wiki.horde.org/Doc/Dev/ReleaseCycle for details about the Horde release cycle and http://www.horde.org/development/versions for the affected applications. Horde 3 had been a huge milestone in Horde's history and has served us well for 8 long years. We really hope you enjoyed it too. We know it's still in use in many, many places, and we like to encourage everyone to upgrade to the latest version which is such a huge improvement over the now outdated Horde 3 line. Thank you, Horde 3, and thank you, everyone who made it such a great success! I do agree with Jan that Horde 3 had a great time and anybody still using it should migrate to Horde 4/5 soon. [Less]

-------- Original-Nachricht -------- Betreff: [announce] End Of Life for Horde 3 Datum: Tue, 27 Nov 2012 13:21:17 +0100 Von: Jan Schneider Antwort an: [email protected] An: [email protected], [email protected], [email protected] ... [More] The Horde Team is announcing the End Of Life (EOL) for the Horde 3 release series. With the final release of Horde 5 the state of the following release series is updated: Horde 3: EOL Horde 4: Security Fixes Horde 5: Bug Fixes Please see http://wiki.horde.org/Doc/Dev/ReleaseCycle for details about the Horde release cycle and http://www.horde.org/development/versions for the affected applications. Horde 3 had been a huge milestone in Horde's history and has served us well for 8 long years. We really hope you enjoyed it too. We know it's still in use in many, many places, and we like to encourage everyone to upgrade to the latest version which is such a huge improvement over the now outdated Horde 3 line. Thank you, Horde 3, and thank you, everyone who made it such a great success! I do agree with Jan that Horde 3 had a great time and anybody still using it should migrate to Horde 4/5 soon. [Less]

One thing I always disliked about the way we organized our Horde repository was the fact that we have all library modules and applications lumped together in a single git repository. Of course there are some good reasons for that type of monolithic ... [More] repo. But for someone just interested in our (really powerful) IMAP library this is a drawback: The library is hidden somewhere between the other libraries and if you want to work on it you will nevertheless have to clone the whole repository. And there are other situations in which small, module specific repositories would make sense. So far I wasn't aware of a solution that would allow for a reasonable compromise. Originally I only knew that git submodule would allow including additional git repositories into a master repository. This approach has some drawbacks though. We could construct the current horde repository out of a bunch of submodules. But the work flow within this master repository would be significantly more cumbersome as git submodule interferes with the default way of working with git.git subtree to the rescue!git subtree however seems to allow for the perfect solution: Separate subrepositories can co-exist with the monolithic master repository. And any commits to either of them can be exchanged between them. The stream of commits to the monolithic master can even be transmitted automatically to the splitted repositories. None of these steps seem to introduce any additional overhead to any of these repositories.Installing "git subtree"The subtree command has been added to the git-1.7.11 release. But as many distributions do not yet offer this variant you can install the tool in a more hackish way if desired:cd /usr/lib/git-core/ wget https://raw.github.com/apenwarr/git-subtree/master/git-subtree.sh mv git-subtree.sh git-subtree chmod 755 git-subtree Replacing a "submodule" with a "subtree"A while ago I pulled the Jenkins installation procedures into our horde-support repository using git submodule. In order to give git subtree a first test run I replaced the Jenkins submodule by the subtree approach. The first step had to be the removal of the old submodule:git rm .gitmodules ci/jenkins git commit -m "Remove the jenkins installation procedures as a submodule. Prepares for replacement by 'git subtree'" Now I imported the repository previously registered via git submodule using git subtree:git subtree add --prefix=ci/jenkins --squash https://github.com/wrobel/jenkins-install.git master This pulled the external repository into the current horde-support repository at prefix "ci/jenkins" and squashed all commits of the imported repository into a single commit. The imported code is now an equivalent citizen to the rest of the code in the repository - none of the standard git work flows are affected in any way.Of course the interesting question is whether updates to this imported code can be merged back into the original repository. I commited a small change within the imported code:git commit -m "Update to jenkins-1.475" ci/jenkins/jenkins.mk This change can indeed now be splitted into the subtree again and exported to the original archive:git subtree split --prefix=ci/jenkins --annotate="(horde-support) " d73edc4878c8.. --branch ci-jenkins What happens here is that git subtree splits the path specified with the prefix option into a separate branch named ci-jenkins. It will prefix any commit transported into this branch with (horde-support) to indicate the origin of the commit. Usually the branch range given here (d73edc4878c8..) is unnecessary for the operation. But the code within ci/jenkins had been included as submodule before commit d73edc4878c8. This part of the history should not be imported into the splitted branch.After the splitting operation created the new ci-jenkins branch in my repository it should be equivalent to our original, imported repository. Thus I was able to push back to it:git push [email protected]:wrobel/jenkins-install.git ci-jenkins:master Using "git subtree" for the horde repositoryCan the subtree approach be used to have both a monolithic horde repository as well as the small modular repositories at the same time? This would be the best of both worlds: While we develop in the monolithic horde repositories we allow other developers to also watch and patch single modules. If the commits from the monolithic repo can be transferred to the modular repos on a regular basis while we can also import patches the other way around without blowing up any of the associated git repos: I'd be reTruncated by Planet Horde, read more at the original (another 4092 bytes) [Less]

One thing I always disliked about the way we organized our Horde repository was the fact that we have all library modules and applications lumped together in a single git repository. Of course there are some good reasons for that type of monolithic ... [More] repo. But for someone just interested in our (really powerful) IMAP library this is a drawback: The library is hidden somewhere between the other libraries and if you want to work on it you will nevertheless have to clone the whole repository. And there are other situations in which small, module specific repositories would make sense. So far I wasn't aware of a solution that would allow for a reasonable compromise. Originally I only knew that git submodule would allow including additional git repositories into a master repository. This approach has some drawbacks though. We could construct the current horde repository out of a bunch of submodules. But the work flow within this master repository would be significantly more cumbersome as git submodule interferes with the default way of working with git. git subtree to the rescue! git subtree however seems to allow for the perfect solution: Separate subrepositories can co-exist with the monolithic master repository. And any commits to either of them can be exchanged between them. The stream of commits to the monolithic master can even be transmitted automatically to the splitted repositories. None of these steps seem to introduce any additional overhead to any of these repositories.Installing "git subtree"The subtree command has been added to the git-1.7.11 release. But as many distributions do not yet offer this variant you can install the tool in a more hackish way if desired:cd /usr/lib/git-core/ wget https://raw.github.com/apenwarr/git-subtree/master/git-subtree.sh mv git-subtree.sh git-subtree chmod 755 git-subtree Replacing a "submodule" with a "subtree"A while ago I pulled the Jenkins installation procedures into our horde-support repository using git submodule. In order to give git subtree a first test run I replaced the Jenkins submodule by the subtree approach. The first step had to be the removal of the old submodule:git rm .gitmodules ci/jenkins git commit -m "Remove the jenkins installation procedures as a submodule. Prepares for replacement by 'git subtree'" Now I imported the repository previously registered via git submodule using git subtree:git subtree add --prefix=ci/jenkins --squash https://github.com/wrobel/jenkins-install.git master This pulled the external repository into the current horde-support repository at prefix "ci/jenkins" and squashed all commits of the imported repository into a single commit. The imported code is now an equivalent citizen to the rest of the code in the repository - none of the standard git work flows are affected in any way.Of course the interesting question is whether updates to this imported code can be merged back into the original repository. I commited a small change within the imported code:git commit -m "Update to jenkins-1.475" ci/jenkins/jenkins.mk This change can indeed now be splitted into the subtree again and exported to the original archive:git subtree split --prefix=ci/jenkins --annotate="(horde-support) " d73edc4878c8.. --branch ci-jenkins What happens here is that git subtree splits the path specified with the prefix option into a separate branch named ci-jenkins. It will prefix any commit transported into this branch with (horde-support) to indicate the origin of the commit. Usually the branch range given here (d73edc4878c8..) is unnecessary for the operation. But the code within ci/jenkins had been included as submodule before commit d73edc4878c8. This part of the history should not be imported into the splitted branch.After the splitting operation created the new ci-jenkins branch in my repository it should be equivalent to our original, imported repository. Thus I was able to push back to it:git push [email protected]:wrobel/jenkins-install.git ci-jenkins:master Using "git subtree" for the horde repositoryCan the subtree approach be used to have both a monolithic horde repository as well as the small modular repositories at the same time? This would be the best of both worlds: While we develop in the monolithic horde repositories we allow other developers to also watch and patch single modules. If the commits from the monolithic repo can be transferred to the modular repos on a regular basis while we can also import patches the other way around without blowing up any of the associated git repos: I'd be reTruncated by Planet Horde, read more at the original (another 3911 bytes) [Less]