eGroupWare Installed

Under Linux, or on several Web-server installations, there exists a Web-application, which is written in PHP scripts, named “eGroupWare”. This is particularly easy to install under Debian / Linux.

Its purpose to to allow an administrative user to grant numerous non-administrative users access to tools, which allow the coordination of projects, timetables, and the booking of (any, symbolized) resources. It allows for notifications to be sent out, as well as for some socializing to take place between registered users. It also allows for its own WiKi to be created, and a custom Web-page. It is extensible through numerous apps that exist within.

Most importantly, each user has complex Access Control Lists, which control in great detail what aspects of the functioning of objects he is allowed to decide. Obviously, the main administrative user has his ACLs set to allow access to everything, including the editing of the ACLs themselves.

I have installed and started eGroupWare on this server. But my great failing in this is, that currently, I am also the only user, even though I could invite people to visit and receive accounts from me, and to collaborate through this site.

Without an actual user population, this is just a fun game to play for me, in administering my Web-site in general.

Dirk

(Edit 11/05/2016 : ) It is a fact that while I was installing eGroupWare on this machine, because the same machine also hosts my blog, my blog was offline for a few minutes, around 15h08 November 3. This happened in fact, because I was making ad-hoc changes to a suggested configuration script belonging to the Debian-packaged version of eGroupWare, in hopes of making this Web-application more secure. These changes of mine prevented me from restarting the Apache server, until I edited them back out. And so, by 15h27 that same night, my server was back up.

I had assumed that nobody would notice, as this outage really only lasted a few minutes, and I was not experiencing heavy traffic at that time.

And as it turned out, there was a more-correct way to change the configuration, than the method I had been trying – to edit that file.

 

Momentary Software Update Today

By default, “WordPress” blogs are actually stored on a “MySQL server”, so that actual ‘PHP’ scripts access this database, and render it as HTML from the Web server.

Today the Linux package manager installed an update to the MySQL server running on this box. This also triggered a restart of the server-instance running centrally as user ‘root‘. Therefore, access to my blog may have been affected briefly, from 18h50 until about 18h55 today.

I apologize for any inconvenience.

Dirk

 

Momentary Software Update Today

Just today, there was an update to several of the packages on this server, that provide PHP5. This triggered an automatic restart of my Apache server, due to which the site might have momentarily been unavailable from 19h06 until 19h07 this afternoon.

There appears to have been no deterioration in how the site works, and because my caching daemon is a separate process, the site should also be as quick to view, as it was at any time the computer has been up for a few days.

Dirk

 

WordPress.org needs to be adapted to Debian.

I guess that when many people blog, they may go directly to a (paid) hosting service for blogs. WordPress.com would be an example of that. But the assumption that seems to come next, is that people have a Web-hosting service already, with the privileges to FTP files up to it, and privileges to run (server-side) CGI scripts written in PHP. One type of software which they can then upload to this service, can be WordPress.org.

Hence, a lot of the assumptions made in the packaging of WordPress.org, are relevant to this usage scenario, including perhaps the need that can come up to solve technical issues, by tolerating possible configuration changes on the part of the blogger.

What I’m doing is a bit more out of the ordinary, to host my site on my own server, including to host WordPress.org. The way this Web-application is set up by default, it has a root or base directory, plus a content directory that underlies the root. Because many people simply upload this package to their Web-host, and then tinker with it until it works, it’s not an urgent need as seen by the WordPress.org devs, to fend off the root directory as having a username different from the username of the content directory.

But in my setup that’s how it is. And so, entirely because I, too, was tinkering with my setup, I did trigger an attempted core update, which would have rewritten the contents of my root directory. But, because this site’s root has different permissions set on my computer, the WordPress version I use was also unable to give itself a complete update. This is a good thing, because mine was initially installed via my (Debian / Linux) package manager, and I need to keep it compatible with any future updates the package-manager might give it. OTOH, sub-directories of my content directory are supposed to contain more-personalized information.

My enforcement of this was such, that the WordPress.org Web-application was unable to put the site into “Maintenance Mode”, in order to do its core-update. But the fact remains, that even if the site wanted only to update plug-ins or the theme that I happen to be using, this Web-application would still need to put the site into maintenance mode first, which by default it can’t. So by default, even updates to plug-ins would fail.

But my past practice, of just deleting a plug-in from the content directory, and of copying the new version into that content directory – which might be called ‘a manual update’ – will no longer continue to serve me well. From now on, I’ll want to run my updates in-place. And this required some further modification – I.e. some more fiddling on my part, to prepare.

As it stands an attempted in-place update even just for a plug-in, will still fail harmlessly, unless I now do something specific with my root password first. And I’m not going to be more specific than that. I did post some questions on the WordPress.org forums about the issue that I ran in to before, but then just posted my own answer to this issue. It’s just that since nobody did reply to my questions within a few hours of my posting them – until I marked my own issue as Resolved – I also feel that I shouldn’t be wasting their time with more of my details. And without these details, they may not be confident that I really do understand this subject. It’s just that nobody over there even bothered to follow up on that thought, let’s say with any questions of their own.

Dirk