a lot of questions, I'll try to cover them all.
But please don't apologise for being inexperienced. That's true for nearly everyone.
We are delighted you decided to evaluate the system.
Let me start with the rpm signing issue:
Last week I noticed that the gpg key I use for signing the packages was expired.
Unfortunately that was a few day after expiration, but since I can't travel backward in time, no way to fix that.
(I am an experience time traveller forward in time though ;-)
Anyway, I generated a new key, uploaded it and rebuilt all the packages which I uploaded as well.
I can't rule out that I made a mistake during the process.
And I didn't have the time to test the rpm installation yet. But I will do it this week.
Anyway, because I generated the certificate myself, it can't be verified by central authorities. This is why you need to confirm the validity of the key.
Basically this confirmation means that you don't believe that our web site has been hacked.
My road map foresees the use of an "official" key, but that'll still take some time.
Because the installation of the examples package failed, you don't find anything below folder SYSTEM.
Naturally the system is empty after a fresh installation.
We provide some convenience objects (Exit State Profile STANDARD, Exit State Mapping UNIX and Exit State Definitions SUCCESS, SKIPPED and FAILURE, or so), which are loaded during the installation of the server rpm.
The examples package creates a folder called EXAMPLES and a bunch of subfolders below the SYSTEM folder, as well as a few local jobservers.
OK, the examples package isn't that crucial at this point in time, so let me try get the more important problems fixed first.
1. Shut down Zope
From your description it looks like Zope has been started as a service.
What we do is that we start a "scrolllog" and instruct it to start Zope as a "foreground" process.
But since scrolllog runs as a daemon, Zope will run in the background nevertheless.
The effect is that if Zope crashes for some reason, it'll be immediately restarted by scrolllog.
If the reason for crashing is a kind of soft error (an error that is caused by a temporary situation), this approach will improve the availability of the GUI.
Since, for whatever reason (we'll find that out later), the init.d script doesn't work in your environment, you'll have to get rid of Zope in another way.
If the Zope management form is reachable, the easiest way to get rid of the process is:
- click on "Control Panel"
- click the "Shutdown" button
The effect is that Zope will exit with exit code 0, which signals scrolllog that the termination of the process was intended.
scrolllog won't automatically restart the Zope process and will terminate itself instead.
Alternatively you can kill both the Zope process and its parent process.
2. The scheduling server
The fact that the start gets stuck means that the server-start script doesn't seem to return.
There is a kind of race condition which can cause this, but that's a very rare situation.
(To elaborate this: if you, for instance, instruct Java to display garbage collect messages, it is possible that such a message collides with a server message that reports a successful startup.
Since the server-start script doe a "grep" for this message, it won't find it in that case and it'll continue waiting although the server is running fine.
My estimate is that this occurs at most once in a hundred startups. But hey, there exist people that win the jackpot at the first attempt).
The more likely cause for getting stuck is a problem during startup.
But in order to analyze that, I'm going to need the server's log file(s).
If you feel uncomfortable posting them here, you can send me them per e-mail (ronald dot jeninga, then an at-sign and the company name, independit and the top level domain de).
The path to happiness we're going to follow is:
- get rid of the problematic processes (the Zope server and (maybe) the scheduling server)
- analyze the reasons for failing
- eliminate those reasons (I might have to build new rpms; open source environments are unfortunately pretty volatile, and I'm certainly not perfect either)
- get both the schedulix server and Zope running
- install the examples again (i.e. we try and see what happens, analyze any problems and repair them)
Don't worry about us. We're not perfect but eager to learn from our mistakes. And every improvement of the system (that includes the rpms) is important to us.