jhmaverick/hestiacp-docker

Dockerized Hestia Control Panel

HestiaCP in Docker

Warning: The project is still in development and may have issues. Use at your own risk.

• Changelog
• Docker Hub
• Github
• Hestia Project

How to use this image

wget https://raw.githubusercontent.com/jhmaverick/hestiacp-docker/main/docker-compose.yml
HSTC_HOSTNAME="example.com" docker-compose up -d

A random password will be generated for the admin user and will be displayed in the container logs on first run.

Note: MariaDB runs in a separate container to optimize initialization time for the main container.

Build your own image

The docker-helper used in the project is just a layer for docker-compose that makes it possible to use variables for different environments, custom scripts and hooks. It depends on docker and docker-compose being installed and must be run with bash docker-helper or ./docker-helper.

All configurations for building, running and pushing the images can be found in the docker-helper.yml in the project root.

Build image

Run the build script informing the name of the image that will be built.

./docker-helper image-build <image>

Example:

./docker-helper image-build stable

Run image

Start services using stable image:

./docker-helper up

Start services using another image:

./docker-helper image-up <image>

Example:

./docker-helper image-up beta

Local Access

Admin URL: https://hestiacp.localhost:8083
Username: admin
Password: admin

Push image

Run the push script by entering the image name defined in docker-helper.yml.

./docker-helper image-push <image> <all|version|latest|<any>>

Example:

Push stable image with latest and version:

./docker-helper image-push stable all

Volumes

• /conf Persistent data.
• /home All data from users.
• /backup Backups. Include backups from users, system credentials and daily backups from /conf.

Initial data

• /conf-start Data for initialize /conf.
• /home-start Data for initialize /home.

Variables

General

• DOCKER_REPOSITORY Docker repository for building and pulling images.

Container

• HSTC_HOSTNAME Sets the hostname of the Hestia container.
• MAIL_ADMIN Change mail from admin account in the first running.
• AUTOSTART_DISABLED Disable services on container startup. Ex: "clamav-daemon,ssh,vsftpd".

Build

• HESTIACP_REPOSITORY Hestia project git that will be used in the build.
• MULTIPHP_VERSIONS Defines the PHP versions that will be installed in the build.
• MARIADB_CLIENT_VERSION Defines the version of the MariaDB client that will be installed.

Known Issues

Build terminating for no apparent reason

Rerun the build with the --no-cache option. Ex: ./docker-helper image-build stable --no-cache.
If that doesn't solve the problem, check the zlib version in the "hst_autocompile.sh". When a new version of zlib is released, the old one is removed from the official website causing an error when compiling. You can update the version by adding the variable "ZLIB_VERSION" in the .env in the project root or by updating in the hst_autocompile.sh.

The data directory cannot be deleted

Run ./docker-helper fix-data-chattr and try again

hestiacp-docker's Issues

Persistent Files Confusion

Hi, I'm trying to generate a custom image but the persistent files look confusing to me.

I see during build it does backup a selection of files in the container.
rootfs/usr/local/hstc/install/add-default-persistent-files.sh

After that during the boot there is another operation that updates more files persistence.
rootfs/etc/my_init.d/10_updates.sh

I'm confused about how that works specially in regard the /conf persistent volume.
Can you give us some details about the purpose and operation?

By the way, many thanks for sharing the build environment.

bind9 fails

I get an error message when starting the container:

Starting domain name service...: bind9 failed!
Any idea how I can troubleshoot this?

TIA

Security issues with this build.

The main reason one would use docker on a server is segregation! This means a flaw in mariadb only affects mariadb, not the whole system. Docker images with multiple services running is less than ideal because of this. While it is useful for a quick and dirty "does this work", it should never be used in a production environment. What would be great is seeing something built that segregates all services to their own containers.

There is also no way to disable insecure applications such as ftp - yes, you can not map the port, but the service is still running.

There is also the issue that host networking and the big ports like 80 and 443 are used, this could be circumvented by use of an edge router such as traefik, or use of nginx proxy manager. Both of these options would allow for easy mapping of domains to other docker services. Want to install plex too? Just throw in a docker-compose with labels to add it to traefik, or set it up with nginx proxy manager! Right now you can't run HestiaCP on a server with only a single IP address and use a useful application such as traefik to route to other containers - this project could improve on that.

The biggest security flaw right now is MARIADB_ROOT_HOST: "%" alongside a mapped port. This means that anybody who knows your server IP can bruteforce your mysql root pass with no issues! Ports that are not needed externally should NEVER be mapped!

I would highly recommend:

• Install script to write a custom docker-compose.yml file
• Options within the install script to include or exclude software (A la original install.sh)
• Separate docker images for each service (use of the official docker images would be beneficial here like you did with MariaDB)
• Integration of either traefik (complex) or nginx proxy manager (easier) for domains
• Map my.cnf to allow tuning of MariaDB

While this will be a little bit of work, I think it would make the project much more adoptable in a production environment.

Helm Chart

We are a small company running Hestia in production and would like to run it in a kubernetes cluster soon.
Are you interested in working with us on improving this configuration and turning it into an enterprise-ready (but of course open-source) helm chart?