ISPConfig 3 issueshttps://git.ispconfig.org/ispconfig/ispconfig3/-/issues2023-10-12T05:16:31Zhttps://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6588Test if custom path option for shell users is broken2023-10-12T05:16:31ZTill BrehmTest if custom path option for shell users is brokenhttps://forum.howtoforge.com/threads/sftp-not-working.91285/https://forum.howtoforge.com/threads/sftp-not-working.91285/3.2.12https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6579http2 directive nginx changed for latest nginx version2023-09-22T12:04:25ZTill Brehmhttp2 directive nginx changed for latest nginx versionhttps://forum.howtoforge.com/threads/http2-directive-nginx-changed-for-latest-nginx-version.91150/https://forum.howtoforge.com/threads/http2-directive-nginx-changed-for-latest-nginx-version.91150/3.2.12https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6577Move unmaintained old plugins to docs2023-09-16T10:45:06ZTill BrehmMove unmaintained old plugins to docsMove old and unmaintained plugins like bind_dlz_plugin.inc.php and nginx_reverseproxy_plugin.inc.php to docs folder.Move old and unmaintained plugins like bind_dlz_plugin.inc.php and nginx_reverseproxy_plugin.inc.php to docs folder.3.2.12https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5207Update bundled jquery library2019-08-28T15:25:15ZTill BrehmUpdate bundled jquery libraryUpdate bundled jquery libraryUpdate bundled jquery library3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4810Change SSI include option2017-10-05T09:45:00ZTill BrehmChange SSI include optionhttps://www.howtoforge.com/community/threads/suggestion-to-inform-about-dangerous-options-for-shared-hostings.77488/https://www.howtoforge.com/community/threads/suggestion-to-inform-about-dangerous-options-for-shared-hostings.77488/3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4776harddisk quota -1 on website when client has a limit.2020-04-04T19:50:48ZJonnyharddisk quota -1 on website when client has a limit.Not sure if its meant to be like this but, if you limit a client's harddisk quota. When they go to create a site, it has harddisk quota set to -1 which makes it look like they have unlimited space, when they actually don't.
Its a fresh ...Not sure if its meant to be like this but, if you limit a client's harddisk quota. When they go to create a site, it has harddisk quota set to -1 which makes it look like they have unlimited space, when they actually don't.
Its a fresh install as well.
I hope its not a bug but it looks it.3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4759On client change cron.d paths to logs not changed2020-09-08T07:34:31ZSergiOn client change cron.d paths to logs not changedIf a site is changed to a new client, paths on already created cron entries are not updated.
For example :
`00 2 * * * web19 /usr/bin/wget --user-agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -q -t...If a site is changed to a new client, paths on already created cron entries are not updated.
For example :
`00 2 * * * web19 /usr/bin/wget --user-agent='Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -q -t 1 -T 7200 -O /var/www/clients/client8/web19/private/cron_wget.log 'http://example.com/modules/cron_products_full.php' >>/var/www/clients/client8/web19/private/cron.log 2>>/var/www/clients/client8/web19/private/cron_error.log #example.com`
if client8 is changed to client9 using the panel, paths won't be updated here and command 'wget' will fail because it won't find the old path.
Maybe, on client change, cron entries related to the updated site should be reprocessed for paths to be rediscovered.3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4731Updated PowerDNS SQL structure2018-05-26T21:20:40ZTill BrehmUpdated PowerDNS SQL structurehttps://www.howtoforge.com/community/threads/is-powerdns-version-4-supported-in-ispconfig-3.76911/#post-363217https://www.howtoforge.com/community/threads/is-powerdns-version-4-supported-in-ispconfig-3.76911/#post-3632173.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4579Website directive snippets can not be used trough remote api2020-08-28T17:06:37ZTill BrehmWebsite directive snippets can not be used trough remote apihttps://www.howtoforge.com/community/threads/setting-nginx-snippet-directives-through-soap-api.75828/#post-357334https://www.howtoforge.com/community/threads/setting-nginx-snippet-directives-through-soap-api.75828/#post-3573343.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4504Apache2 - reload instead restart (idea)2023-02-27T13:30:01ZTimo BoldtApache2 - reload instead restart (idea)Hi guys,
I looked inside the source code today, because our webserver with many websites got some seconds of offtime after changing website configurations.
So I debugged a little and saw, that the apache2-plugin do a restart and tcp...Hi guys,
I looked inside the source code today, because our webserver with many websites got some seconds of offtime after changing website configurations.
So I debugged a little and saw, that the apache2-plugin do a restart and tcp check to test out, if configs are faulty. In my opinion this is unnecessary, because it could be tested by apache2ctl -t before, OR doing a reload which results in a fail, which will result in an error too, but needs less time.
if($web_config['check_apache_config'] == 'y') {
//* Test if apache starts with the new configuration file
$apache_online_status_before_restart = $this->_checkTcp('localhost', 80);
$app->log('Apache status is: '.($apache_online_status_before_restart === true? 'running' : 'down'), LOGLEVEL_DEBUG);
===> $retval = $app->services->restartService('httpd', 'restart'); // $retval['retval'] is 0 on success and > 0 on failure
$app->log('Apache restart return value is: '.$retval['retval'], LOGLEVEL_DEBUG);
Why to do something like that? Wouldn't it be better to reload, and check for errors then? So existing websites would not get an offtime while ispconfig will fix the faulty config files.
I tested with reload and it worked so far. The correct workflow should be a testing via "apache2ctl -t" before, then reload, shouldn't it?
I think this is not a bug, but should be rethought in newer versions. So far we will patch that files atm.3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4319PowerDNS plugin: repair find function and rectify-zone on insert SOA2020-03-04T09:59:03ZZdenek HermanPowerDNS plugin: repair find function and rectify-zone on insert SOAOn Debian Jessie is problem with exec(type -d) function with www-data user in default state. I use "which" instead of it. And "rectify-zone" on insert SOA record without minimal second NS ending with error.
[0001-use-which-instead-of-ty...On Debian Jessie is problem with exec(type -d) function with www-data user in default state. I use "which" instead of it. And "rectify-zone" on insert SOA record without minimal second NS ending with error.
[0001-use-which-instead-of-type-p-disable-rectify-zone-for.patch](/uploads/a939bef14786b32cbdf2a9a07292bca3/0001-use-which-instead-of-type-p-disable-rectify-zone-for.patch)3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4192[3.1rc1] Domain Limit / Missing info text for customer2020-09-07T18:58:38ZDenny Bortfeldt[3.1rc1] Domain Limit / Missing info text for customerHey,
if you activate the domain limit modul in "system config -> settings -> domains", then the customer isn't able to edit the domain field free anymore (which is clear).
But the html text, which is above the checkbox, won't display an...Hey,
if you activate the domain limit modul in "system config -> settings -> domains", then the customer isn't able to edit the domain field free anymore (which is clear).
But the html text, which is above the checkbox, won't display anywhere so that the customer don't know, why he/she can't edit the field.3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/3805Replace/cleanup DNS hostname validators2020-09-07T13:10:55ZDavid KreitschmannReplace/cleanup DNS hostname validatorsI noticed that the validators for DNS entries are different for most forms. Sometimes * is allowed, sometimes _, sometimes none. Often it can result in invalid entries: _ is only allowed at the beginning, - only in the middle of a label....I noticed that the validators for DNS entries are different for most forms. Sometimes * is allowed, sometimes _, sometimes none. Often it can result in invalid entries: _ is only allowed at the beginning, - only in the middle of a label.
I think this should be a good validator:
```
'validators' => array ( 0 => array ( 'type' => 'REGEX',
'regex' => '/^(\*|(\*\.)?_?([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])(\._?([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9]))*\.?)$/',
',
'errmsg'=> 'name_error_regex'),
```
It allows corner cases, e.g.:
*
*._asdf._asdf (currently not possible for TXT)
asdf.example.com.
but disallows the following invalid records which can currently be entered e.g.:
-asdf
asd_f
asdf*3.3https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6227Apache config file version checks2021-09-03T10:52:28ZTill BrehmApache config file version checksIn Apache vhost.conf file. we use in several places if constructs like:
<tmpl_if name='apache_version' op='>=' value='2.4.30' format='version'>
But in the Apache plugin, we set apache_version variable just to $app->system->getapacheve...In Apache vhost.conf file. we use in several places if constructs like:
<tmpl_if name='apache_version' op='>=' value='2.4.30' format='version'>
But in the Apache plugin, we set apache_version variable just to $app->system->getapacheversion() (means version is set to e.g. 2.4 and not 2.4.30) and not to $app->system->getapacheversion(true), so apache_version does not contain the full version number. But it might even be that the if comparator would have issues with a number that contains two dots.
There seem to be no open issues based on that at the moment, but we should check and verify this as it might be that some apache config snippets will never be used at the moment.https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5959Remove TLSv1 and TLSv1.1 from Postfix2020-12-09T11:07:50ZThomRemove TLSv1 and TLSv1.1 from PostfixTLSv1 and TLSv1.1 are deprecated and we should remove support for it, not now, as discussed in #5770, but it has to happen sometime.
I have run some tests on the biggest webmail providers, dutch mail providers, dutch ISPs, and french I...TLSv1 and TLSv1.1 are deprecated and we should remove support for it, not now, as discussed in #5770, but it has to happen sometime.
I have run some tests on the biggest webmail providers, dutch mail providers, dutch ISPs, and french ISPs, and I only found 2 providers (out of 64) who don't support TLSv1.2: Orange (french ISP) and Excite.com. Orange only supports SSLv3 and TLSv1, Excite only supports TLSv1 and TLSv1.1. None of the tested mailservers have TLSv1 and TLSv1.1 disabled yet.
Question is mostly when - are we waiting for a big provider to start the movement? Do we just wait a little more and do it at the end of 2021?https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5603Link API docs from Development page2020-08-21T11:56:11ZHelmoLink API docs from Development page[The development page](https://www.ispconfig.org/development/) has under the section `Developer Documentation and Tutorials` a link to http://docs.ispconfig.org/ which is outdated, missing SSL and seems to miss styling on some pages.
Ca...[The development page](https://www.ispconfig.org/development/) has under the section `Developer Documentation and Tutorials` a link to http://docs.ispconfig.org/ which is outdated, missing SSL and seems to miss styling on some pages.
Can we add a link to the content from [remoting_client/API-docs](https://git.ispconfig.org/ispconfig/ispconfig3/-/tree/master/remoting_client/API-docs)?https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5324Purge maildrop2020-10-02T16:09:20ZHelmoPurge maildropIn 5827252b7c9e76d18d1bc71cd478ab998cced52e @pixcept 'removed courier support'.
While working on mailfilters I was distracted by the variation between sieve and maildrop in the comments... where it seems that maildrop is no longer an op...In 5827252b7c9e76d18d1bc71cd478ab998cced52e @pixcept 'removed courier support'.
While working on mailfilters I was distracted by the variation between sieve and maildrop in the comments... where it seems that maildrop is no longer an option.
Lets clean up... It's mentioned in the files listed below. I'm preparing a pull request to update a few files I'm confident about. I'd appreciate some guidance, or commits, to get rid of the rest.
- [x] docs/under_development/CHROOTED_DEBIAN_5.0.txt
- [x] helper_scripts/gentoo_setup.sh
- [x] helper_scripts/debian_setup.sh
- [x] install/tpl/opensuse_postfix.conf.master
- [x] install/tpl/fedora_postfix.conf.master
- [x] install/tpl/gentoo_postfix.conf.master
- [x] install/tpl/debian_postfix.conf.master
- [x] install/lib/installer_base.lib.php
- [x] install/dist/lib/gentoo.lib.php
- [x] install/dist/lib/fedora.lib.php
- [x] install/dist/lib/opensuse.lib.php
- [x] interface/lib/plugins/mail_user_filter_plugin.inc.php
- [x] server/plugins-available/mail_plugin.inc.php
- [ ] update manual?https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5198Convert tform events from client domain edit to plugin2020-08-28T16:38:12ZHelmoConvert tform events from client domain edit to pluginWhile working on the domains_domain_update api function in !845 I noticed that events didn't trigger like when updating a client domain via the webUI.
@tbrehm mentioned:
> tform actions are not executed by the api. The api executes plug...While working on the domains_domain_update api function in !845 I noticed that events didn't trigger like when updating a client domain via the webUI.
@tbrehm mentioned:
> tform actions are not executed by the api. The api executes plugins but this code was written before the interface plugins were introduced in ispconfig. So basically the code needs to be migrated to a plugin. But we will have to be careful to not break existing API applications which do the changes on their own.
Another related issue:
- #3997 - maildeliver plugin
the code in onAfterUpdate() in interface/web/client/domain_edit.php would have to go to I guess a new file interface/lib/plugins/client_domain_plugin.inc.php
An example for the structure could be in ./interface/lib/plugins/mail_mail_domain_plugin.inc.phphttps://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4762Harmonize Remote API calls2020-08-28T17:13:18ZJonasHarmonize Remote API callsSome calls have a get_all, while for others there is the primary_id where you could pass the % wildcard which can produce the same result.
As it might break some scripts depending on the remote API, It could be good to do this only in a...Some calls have a get_all, while for others there is the primary_id where you could pass the % wildcard which can produce the same result.
As it might break some scripts depending on the remote API, It could be good to do this only in a major upgrade, and maintaining the compatibility for some time.https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/4639Folder protection options can conflict with existing configured locations in ...2020-09-08T07:45:32ZRamil ValitovFolder protection options can conflict with existing configured locations in nginx (locations merge problem)The problem happens if the following both conditions are met:
1. User configures a password protected folder in ISPConfig (Sites - Web Access - Protected Folders).
2. The same folder is already configured in nginx (for example, in vho...The problem happens if the following both conditions are met:
1. User configures a password protected folder in ISPConfig (Sites - Web Access - Protected Folders).
2. The same folder is already configured in nginx (for example, in vhost template, directive snippets or web options).
In this case the locations are not merged by ISPConfig when it generates the final vhost configuration file. As a result, the file contains mupltiple locations that leads to nginx syntax error.
Example. Let's assume, we have "test" location configured in directive snippets:
```
location /test/ {
try_files $uri $uri/ /index.php?$args;
}
```
Then add "test" to the list of protected folders. The resulting configuration file that ISPConfig generates will be invalid:
```
location /test/ {
try_files $uri $uri/ /index.php?$args;
}
## some other nginx directives
location /test/ { ##merge##
auth_basic "Members Only";
auth_basic_user_file /var/www/clients/client1/web5/web/test/.htpasswd;
location ~ \.php$ {
try_files /89f314d371fa173948fcad289dd51f95.htm @php;
}
}
```
Discussion at [Howtoforge](https://www.howtoforge.com/community/threads/protected-folders-duplicate-location-problem-nginx.76185/)