FAQ
Platform
What OS is ProjektServer based on?
ProjektServer 4 (or PS4 for short) is based on the current Debian Linux. For software stacks we make heavy use of Docker container technology.
We offer a ready-made ISO CD-ROM image based on Debian which allows you to both install the OS and the PS4 software. Should your cloud provide not offer the ability to boot your virtual machine from an ISO image you usually can select a preinstalled OS, in this case use the most current Debian distribution.
Why did you choose Debian?
Because it is optimized for server use and values stability and robustness over leading (bleeding?) edge technology. As project infrastructure quickly develops into a critical resource of a project we believe that having a rock-solid foundation has priority over running the latest releases of the underlying software.
Why isn't PS4 using Kubernetes, OpenShift or other cluster solutions?
These are fine tools which serve two main purposes: Scalability and high availability. That's fine if this is what you need but it comes with a price tag: Increased complexity. In fact modern cloud platforms already provide these features as
- cloud virtual machines are by itself scalable to a wide range (increasing resources is just a matter of pushing the sliders more to the right, msg.Cloud for example currently allows you to scale up to 32 CPUs, 192 GB RAM and 2 TB disk space if you use a single virtual disk, other cloud providers offer even more)
- cloud virtual machines are hosted in clustered environments in order to minimize availability risks
Therefore a cloud virtual machine is by itself a kind of abstraction which provides all benefits of a cluster without causing you to deal with the added complexity of such an environment. In other words: Should your PS4 installation touch the resource limits of your cloud virtual machine then this is a strong indication that your project needs partitioning.
Communication Issues
The ProjectServer tells me "HTTP error 502: Service not available"
You tried to access a service. The underlying stack actually exists but is currently unable to take your request. Did you start or restart the stack recently? Then most likely the stack is still starting and not fully established yet - a few stacks tend to take quite some time to start up, often depending on the amount data they overlook (e.g. Confluence). So simply wait a few seconds and then retry. The Initial Start Time given in the stack's documentation page pages provides an indication (but note that the effective start time may depend on the configuration (e.g. many plugins) or data volume of the stack).
It is also possible that the service has just being closed down on purpose, for whatever reason. Your project should form a habit of informing people before part of the project infrastructure is made unavailable.
Of course there is also a chance that your service fails to start due to a bug in the stack or in the configuration. Look at the container's log using the docker logs <container-name> command. If your stack has multiple containers look at all of them starting with the container which houses the main application (usually names exactly like the stack, e.g. cid-jenkins). If this reveals a failure to start the application but does not give sufficient detail to pinpoint the exact reason enter the container through docker exec -it <container-name> bash and look for additinal log files, often found in the /data or /var/log hierarchy.
A further reason are exhausted resources - the demand on RAM or/and disk space cannot be satisfied. Use the free or top command to check the RAM situation and df -h to spot disk space shortage. Moreover examine the system logs under /var/logs.
When uploading files I get a HTTP error 413: "Request entity too large"
All communication uses the proxy stack as switching center. Proxies often have an implicit limit for the request sizes they allow to pass.
This is also the case with nginx, which the PS4 Proxy stack is built upon. Its request size limit has been lifted starting with proxy stack version 20190630. Check the version of your proxy stack with docker ps (the date you are looking for is the last part of the name given in the IMAGE column).
If your version is older than 20190630
Upgrade the proxy stack by issueing
- docker-stack update
- docker-stack upgrade proxy
The restriction should then be gone.
If your version is newer or the problem persists after updating
Most likely a content inspection utility scans your network traffic to protect you against malicious software. Such software usually slurps the whole data content, examines it and (if considered ok) forwards it to your cloud server.
You have to approach your cloud provider and request a change in this setting. If you are on msg.Cloud contact XT, we will then coordinate with ZI what to do (#1936296).
After cloning a PS4 system there is no network connectivity any more.
In msg.Cloud it happens that the name of the network interface changes when a VM is booted from a snapshot. The symptom is that in output of the ifconfig or ip addr command there is no trace of the IP address you had configured (most likely in /etc/network/interfaces).
To solve the issue proceed as follows:
- Run the command dmesg | grep eth0 and look for a line telling "some drivername, e.g. virtio devicename: renamed from eth0". Often this is the first line of the command output as in the following example:
# dmesg | grep eth0
[ 1.637236] virtio_net virtio0 enp0s17: renamed from eth0
[ 8195.224237] br-df2c8555536d: port 2(veth060dcd6) entered blocking state
[ 8195.224239] br-df2c8555536d: port 2(veth060dcd6) entered disabled state
[ 8195.224328] device veth060dcd6 entered promiscuous mode
- The devicename is the name you are looking for, in the above example it is enp0s17.
- You can test if that is the proper interface configure it manually by issueing ifconfig devicename ip-address netmask netmask up and try to ping another host on your subnet (often the IP address ending in ".1" exists).
- To make the change permanent edit /etc/network/interfaces and replace the original device name by this devicename both on the "allow hotplug" and the "iface" line like so:
allow-hotplug enp0s17
iface enp0s17 inet static
gateway 10.11.12.1
address 10.11.12.51
netmask 255.255.255.0
- To make sure that the change persists reboot the server and check network connectivity.