I'm using ISPConfig Version 3.3.0p1 and tried to activate an aliasdomain as vHost without changing the empty basedir-field. After saving, it looks like the aliasdomain "web" basedir was automatically created/used in /web1 and not in /web1/web as I would have expected to be the same as the main web. This deleted all folders with the same user-owner that already have been in /web1 like /backup, /private, /web, etc. and broke apache2 to be able to restart, telling me, that there are wrong user rights (sorry, not exactly shure anymore, because I deleted the apache-vhost and the web afterworth to be able to get it working again). Is it always necessary to put at least "web" in that field for not breaking the main web? Then a hint for maybe doing it wrong would be great. If it's a bug or a missunderstanding in my case, then a statement would be nice. PS: I'm creating this web as admin, not as user under ISPConfig...
It should, in fact, not be possible to leave the field for the folder empty. I'll check that. Thank you for reporting this.
Actually, now I created an aliasdomain as vhost with basedir "web" and deleted it again. After saving, the hole web-dir from the main web got deleted! Any idea, whats going wrong on this server?
The config for the specific main website in ISPConfig is still there, but the folder /web1 got completly deleted.
First, I would not use the same folder for two sites, which you do by choosing 'web' as folder for a vhost domain. If you want additional domain to point to a site, always use normal alias and not vhost alias domains. Deleting the vhost domain where you set the web root to the main web root might damage something. There can be reasons to choose web as a folder, but using normal alias domains is better.
Regarding your report that it's possible to set an empty directory. I just verified that it's not possible in the recent ISPConfig version. Maybe you use an old or modified ISPConfig?
Tested this as well now. The web folder is not damaged and nothing from main site is deleted in recent ISPConfig versions.
Well, I just wanted to make clear, what's happening...as I said, maybe a hint for that behavior would be good. However, the idea was to create and use a multidomain typo3 installation with that by using 2 different certificates. I could and should use a normal Aliasdomain for that, but I still got these 2 certificates and thought, it should be possible to use them. However, as you said and as I realized by now, it's a very dangerous idea. But, at least, it should warn you or disallow to let you think as stupid as I did, when it can breake the hole setup. PS: After deleting the aliasdomain in ISPConfig, some dirs and configs aren't (log-line in fstab, /var/www/conf/web1, /var/log/ispconfig/httpd/"aliasdomain")
Not sure how you modified your system, but all problems you describe do not appear on any standard installation of ISPConfig, tested on Debian and Ubuntu with Apache and Nginx.
Hm, that's weird...as I said, I'm using ISPConfig Version 3.3.0p1 (which can't be upgraded to final 3.3.0 over ispconfig_update.sh --force) on Ubuntu 22.04.5 (upgraded manually some time ago from 20.04 and changed the hostname itself a couple weaks ago).
3.3.0p1 is newer than 3.3.0, so the updater doesn't let you downgrade your system to avoid that you break it by installing an older version on top of a newer one.
There are 2 or 3 things that I could think of maybe being related to this (the ISPConfig code should be fine, nothing changed): 1. I'm using an proxmox LXC container for the machine 2. The machine itself is really fast, so sometimes the apache cannot be restarted automatically after updates, because the command seems to come to quick 3. I'm using a special 50-server.cnf on that machine (but on others too): # Manually added Optimization for NextCloud / ILIAS Installation max_allowed_packet = 256M # Reduce maximum packet size to save memory innodb_large_prefix = on # Support for large index key prefixes innodb_file_format = barracuda # Use the Barracuda file format for InnoDB tables innodb_file_per_table = 1 # Store each InnoDB table in its own file # InnoDB Settings for Limited Memory innodb_buffer_pool_size = 4G # Set buffer pool to 50% of RAM to balance cache size and memory usage innodb_buffer_pool_instances = 4 # Reduce number of instances due to lower RAM innodb_log_file_size = 512M # Reduce log file size to balance memory and disk usage innodb_flush_log_at_trx_commit = 2 # Less strict ACID compliance to improve write performance innodb_flush_method = O_DIRECT # Use O_DIRECT to avoid double buffering in InnoDB and OS cache innodb_io_capacity = 500 # Lower capacity due to reduced I/O throughput on smaller systems # Query Cache Configuration (optional but recommended for smaller servers) query_cache_size = 64M # Small cache to speed up repeated queries query_cache_type = 1 # Enable Query Cache for read-heavy workloads # Connection and Thread Settings max_connections = 200 # Set maximum connections for limited RAM capacity thread_cache_size = 50 # Reduce thread cache size for smaller RAM table_open_cache = 1000 # Reduce table cache to save memory # Log and Timeout Settings slow_query_log = 1 # Enable slow query log slow_query_log_file = /var/log/mysql/mariadb-slow.log # Log file for slow queries long_query_time = 1 # Time threshold for slow queries in seconds log_queries_not_using_indexes = 0 # Disable logging of queries that do not use indexes innodb_lock_wait_timeout = 60 # Reduce lock wait timeout to prevent long waits # End of manual Optimization for NextCloud / ILIAS
