postfixadmin-devel Mailing List for PostfixAdmin (Page 2)
Brought to you by:
christian_boltz,
gingerdog
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(39) |
Nov
(29) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(5) |
Feb
|
Mar
(8) |
Apr
(8) |
May
|
Jun
(11) |
Jul
(21) |
Aug
(4) |
Sep
(9) |
Oct
(5) |
Nov
(25) |
Dec
(11) |
2009 |
Jan
(40) |
Feb
(16) |
Mar
(1) |
Apr
(46) |
May
(3) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(9) |
Oct
(27) |
Nov
(35) |
Dec
(20) |
2010 |
Jan
(3) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(9) |
Jun
(8) |
Jul
(1) |
Aug
(7) |
Sep
(2) |
Oct
(2) |
Nov
(12) |
Dec
(7) |
2011 |
Jan
(45) |
Feb
(11) |
Mar
(18) |
Apr
(15) |
May
(20) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(8) |
Nov
|
Dec
(14) |
2012 |
Jan
(30) |
Feb
(36) |
Mar
(6) |
Apr
(32) |
May
(20) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
(22) |
Dec
(1) |
2013 |
Jan
(13) |
Feb
(4) |
Mar
(70) |
Apr
(10) |
May
(6) |
Jun
(11) |
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(15) |
Nov
(4) |
Dec
(4) |
2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(8) |
Dec
(2) |
2015 |
Jan
(1) |
Feb
(9) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
(4) |
Feb
|
Mar
(10) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(13) |
2017 |
Jan
(1) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2018 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2023 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christian B. <pos...@cb...> - 2019-03-11 22:10:31
|
Hello, Am Montag, 11. März 2019, 01:15:31 CET schrieb Danny Houtworm: > I have tried everything to the best of my knowledge and ability to > look for solutions on the internet, But i can not seem to figure this > one out > > [houtworm@server ~]$ sudo -u http php > /usr/share/webapps/postfixAdmin/public/setup.php > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ... > <li><b>Error: Depends on: presence config.inc.php - NOT FOUND That's... interesting[tm]. It's especially interesting because setup.php starts with require_once(dirname(__FILE__).'/common.php'); which has require_once(dirname(__FILE__) . '/../common.php'); and that one has $incpath = dirname(__FILE__); if (!is_file("$incpath/config.inc.php")) { die("config.inc.php is missing!"); } require_once("$incpath/config.inc.php"); so setup.php should fail _before_ printing the header, and before printing the failure about finding config.inc.php. This indicates that require_once() can read config.inc.php. To confirm that, please introduce a syntax error in config.inc.php, and then run setup.php on the commandline again. You should see a message about that syntax error. > The location in setup.php is set to /../config.local.php also the inc > one > The files are there 100% they are owned by http:http and the > permissions are 644 > > [houtworm@server ~]$ cd /usr/share/webapps/postfixAdmin/ > [houtworm@server postfixAdmin]$ ls > common.php config.local.php languages public templates_c > composer.json configs lib README.md > composer.lock functions.inc.php model scripts > config.inc.php index.php phpunit.xml templates > [houtworm@server postfixAdmin]$ Looks good. One idea I have is the way how setup.php checks for config.local.php: $file_config = file_exists(realpath("./../config.inc.php")); $file_local_config = file_exists(realpath("./../config.local.php")); Note the realpath() call, which means resolving all symlinks. Does the path /usr/share/webapps/postfixAdmin/public/ include any symlinked part? If in doubt, add echo "\n\n file_config: $file_config local $file_local_config \n\n" to setup.php (directly under the lines quoted above) and check the result. Also note that there's a fallback check for config.local.php: // Fall back to looking in /etc/postfixadmin for config.local.php // (Debian etc) if (!$file_local_config && is_dir('/etc/postfixadmin')) { $file_local_config = file_exists( '/etc/postfixadmin/config.local.php'); } which can mean a) try to create a /etc/postfixadmin/config.local.php and check if setup.php finds it b) make sure your PHP open_basedir allows access to /etc/postfixadmin/ > My Database is ... irrelevant, at least until the problems with config.inc.php and config.local.php are solved ;-) > Nginx Setup: https://paste.ee/p/IE2na > Local and Inc config: https://paste.ee/p/VcMUQ > > I hope there is an obvious mistake here somewhere I checked them, and didn't see an obvious error. That's not surprising because the syntax check already confirmed that your config.*.php is ok, at least the first half of setup.php worked, and the nginx config is irrelevant when running php on the command line. Regards, Christian Boltz -- Es wird also sehr wohl gemountet, wie soll denn yast sonst auf die CD zugreifen? Per dd erstmal alles auf die HD kopieren? Oder lässt es sich die Pakete vielleicht als .wav vorsingen? [Jan Trippler in suse-linux] |
From: Danny H. <dho...@gm...> - 2019-03-11 00:15:41
|
Hello again, I have tried everything to the best of my knowledge and ability to look for solutions on the internet, But i can not seem to figure this one out [houtworm@server ~]$ sudo -u http php /usr/share/webapps/postfixAdmin/public/setup.php <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link rel="stylesheet" type="text/css" href="css/default.css" /> <title>Postfix Admin - PHP Notice: Undefined index: HTTP_HOST in /usr/share/webapps/postfixAdmin/templates/header.php on line 22 </title> </head> <body> <div id="login_header"> <img id="login_header_logo" src="images/logo-default.png" /> </div> <div class='setup'> <h2>Postfix Admin Setup Checker</h2> <p>Running software: <ul> <li>PHP version 7.3.3</li> </ul><p>Checking for dependencies: <ul> <li>Magic Quotes: Disabled - OK</li> <li><b>Error: Depends on: presence config.inc.php - NOT FOUND</b><br /></li> Create the file, and edit as appropriate (e.g. select database type etc)<br />For example:<br /> <code><pre>cp config.inc.php.sample config.inc.php</pre></code> <li><b>Warning: config.local.php - NOT FOUND</b><br /></li> It's Recommended to store your own settings in config.local.php instead of editing config.inc.php<br />Create the file, and edit as appropriate (e.g. select database type etc)<br /><li>Depends on: MySQL 4.1 - OK <br>(change the database_type to 'mysqli' in config.local.php if you want to use MySQL) </li><li>Depends on: PostgreSQL - OK <br>(change the database_type to 'pgsql' in config.local.php if you want to use PostgreSQL) </li><li>Depends on: session - OK</li> <li>Depends on: pcre - OK</li> <li>Depends on: multibyte string - OK</li> <li>Depends on: IMAP functions - OK</li> </ul><p><b>Please fix the errors listed above.</b></p></div> </body> </html> [houtworm@server ~]$ The location in setup.php is set to /../config.local.php also the inc one The files are there 100% they are owned by http:http and the permissions are 644 [houtworm@server ~]$ cd /usr/share/webapps/postfixAdmin/ [houtworm@server postfixAdmin]$ ls common.php config.local.php languages public templates_c composer.json configs lib README.md composer.lock functions.inc.php model scripts config.inc.php index.php phpunit.xml templates [houtworm@server postfixAdmin]$ My Database is MariaDB i have a user postfix with all rights to database postfix with the correct password entered in both config files. nginx is pointed to the /public folder and SSL works fine Nginx Setup: https://paste.ee/p/IE2na Local and Inc config: https://paste.ee/p/VcMUQ I hope there is an obvious mistake here somewhere Thanks and greets :) |
From: Danny H. <dho...@gm...> - 2019-03-09 19:35:43
|
Hello Christian, Yes i was a little confused about the command. I have now created a local config file (I just copied the inc config file and named it config.local.php The directory is /usr/share/webapps/postfixAdmin/config.local.php But when i run the PHP file i get some errors, that it can not find either config files. I can not run as http because i have not set a password for it, i read somewhere that it is not good, But i could do it if it is needed. If i run it as root i get this output [houtworm@server ~]$ sudo php /usr/share/webapps/postfixAdmin/public/setup.php [sudo] password for houtworm: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link rel="stylesheet" type="text/css" href="css/default.css" /> <title>Postfix Admin - PHP Notice: Undefined index: HTTP_HOST in /usr/share/webapps/postfixAdmin/templates/header.php on line 22 </title> </head> <body> <div id="login_header"> <img id="login_header_logo" src="images/logo-default.png" /> </div> <div class='setup'> <h2>Postfix Admin Setup Checker</h2> <p>Running software: <ul> <li>PHP version 7.3.3</li> </ul><p>Checking for dependencies: <ul> <li>Magic Quotes: Disabled - OK</li> <li><b>Error: Depends on: presence config.inc.php - NOT FOUND</b><br /></li> Create the file, and edit as appropriate (e.g. select database type etc)<br />For example:<br /> <code><pre>cp config.inc.php.sample config.inc.php</pre></code> <li><b>Warning: config.local.php - NOT FOUND</b><br /></li> It's Recommended to store your own settings in config.local.php instead of editing config.inc.php<br />Create the file, and edit as appropriate (e.g. select database type etc)<br /><li>Depends on: MySQL 4.1 - OK <br>(change the database_type to 'mysqli' in config.local.php if you want to use MySQL) </li><li>Depends on: PostgreSQL - OK <br>(change the database_type to 'pgsql' in config.local.php if you want to use PostgreSQL) </li><li>Depends on: session - OK</li> <li>Depends on: pcre - OK</li> <li>Depends on: multibyte string - OK</li> <li>Depends on: IMAP functions - OK</li> </ul><p><b>Please fix the errors listed above.</b></p></div> What is the location config.local.php should have? Is /usr/share/webapps/postfixAdmin/config.local.php correct? The config.inc.php is in the same folder. I have set the ownership to http:http, And the permissions are 777, this was default, i imagine i should set this a bit lower too. Thanks, Greets :) On Sat, 2019-03-09 at 19:20 +0100, Christian Boltz wrote: > Hello, > > Am Samstag, 9. März 2019, 01:04:55 CET schrieb Danny Houtworm: > > The output of > > [houtworm@server ~]$ sudo php -l > > /usr/share/webapps/postfixAdmin/config.inc.php > > No syntax errors detected in > > /usr/share/webapps/postfixAdmin/config.inc.php > > Do you also have a config.local.php? (Hint: you should, because it > makes > updates much easier.) > > > I tried to run setup.php, but also no errors there > > Actually there is an error - the command you used > > > [houtworm@server ~]$ sudo php -l run php > > /usr/share/webapps/postfixAdmin/public/setup.php > > prints a nice error: > > > Could not open input file: run > > Can you please run > php /usr/share/webapps/postfixAdmin/public/setup.php > > sudo shouldn't be needed, but trying as the webserver user (for > example > "wwwrun") might be a good idea. > > The expected output is HTML showing that the database was created or > updated, and some more HTML for the form to create a superadmin. > > > Regards, > > Christian Boltz |
From: Christian B. <pos...@cb...> - 2019-03-09 18:20:13
|
Hello, Am Samstag, 9. März 2019, 01:04:55 CET schrieb Danny Houtworm: > The output of > [houtworm@server ~]$ sudo php -l > /usr/share/webapps/postfixAdmin/config.inc.php > No syntax errors detected in > /usr/share/webapps/postfixAdmin/config.inc.php Do you also have a config.local.php? (Hint: you should, because it makes updates much easier.) > I tried to run setup.php, but also no errors there Actually there is an error - the command you used > [houtworm@server ~]$ sudo php -l run php > /usr/share/webapps/postfixAdmin/public/setup.php prints a nice error: > Could not open input file: run Can you please run php /usr/share/webapps/postfixAdmin/public/setup.php sudo shouldn't be needed, but trying as the webserver user (for example "wwwrun") might be a good idea. The expected output is HTML showing that the database was created or updated, and some more HTML for the form to create a superadmin. Regards, Christian Boltz -- In most cases, XSLT is good enough. But I agree, for some parts you need Aspirin. ;-) [Thomas Schraitle in opensuse-doc] |
From: Danny H. <dho...@gm...> - 2019-03-09 00:05:06
|
Hello Christian, Thank you for the response, The output of [houtworm@server ~]$ sudo php -l /usr/share/webapps/postfixAdmin/config.inc.php No syntax errors detected in /usr/share/webapps/postfixAdmin/config.inc.php I have the config file herehttps://paste.ee/p/YaLFf I only changed the database settings and the Configured setting to true. I tried to run setup.php, but also no errors there [houtworm@server ~]$ sudo php -l run php /usr/share/webapps/postfixAdmin/public/setup.php Could not open input file: run [houtworm@server ~]$ sudo php -l /usr/share/webapps/postfixAdmin/public/setup.php No syntax errors detected in /usr/share/webapps/postfixAdmin/public/setup.php Any more things i might have overlooked? On Fri, 2019-03-08 at 23:11 +0100, Christian Boltz wrote: > Hi Danny, > > Am Freitag, 8. März 2019, 11:47:15 CET schrieb Danny Houtworm: > > And i am stuck at PostfixAdmin, because the tutorial depends on > > Postfixadmin to create the database tables > > > > The tutorial uses Apache, but i use Nginx, so i think the problem > > lies > > in my nginx config file. > > Or somewhere in your PHP files. > > My guess is that you have a syntax error in config.local.php, and > that > causes the blank page. > > > server { > > > > listen 443 ssl; > > server_name houtworm.email; > > Thanks for including the server name! I just tested a bit, and it > seems > your setup is correct - for example, I get 200 (+ blank page) for / > and > login.php, and 404 for config.inc.php (which is outside of the > "public" > directory). > > I'd recommend to > - check your config.*.php for syntax errors with php -l > - run php setup.php on the commandline - maybe you get an error > message? > > > Regards, > > Christian Boltz |
From: Christian B. <pos...@cb...> - 2019-03-08 22:37:00
|
Hi Danny, Am Freitag, 8. März 2019, 11:47:15 CET schrieb Danny Houtworm: > And i am stuck at PostfixAdmin, because the tutorial depends on > Postfixadmin to create the database tables > > The tutorial uses Apache, but i use Nginx, so i think the problem lies > in my nginx config file. Or somewhere in your PHP files. My guess is that you have a syntax error in config.local.php, and that causes the blank page. > server { > > listen 443 ssl; > server_name houtworm.email; Thanks for including the server name! I just tested a bit, and it seems your setup is correct - for example, I get 200 (+ blank page) for / and login.php, and 404 for config.inc.php (which is outside of the "public" directory). I'd recommend to - check your config.*.php for syntax errors with php -l - run php setup.php on the commandline - maybe you get an error message? Regards, Christian Boltz -- Stell dein cron auch deine Rechneruhr? Ja? Dann würde ich ihm nicht allzuviel mehr anvertrauen - er scheint leicht überlastet und strebt in Riesenschritten die Rente an ;-) [Matthias Houdek in suse-linux zu einer Mail aus der Zukunft] |
From: Danny H. <dho...@gm...> - 2019-03-08 10:47:25
|
Hello, I have been at this for the last 2 days, but i can not seem to figure it out. I have MariaDB, PHP and Nginx working fine, my nextcloud instance is working great. I followed this tutorial https://wiki.archlinux.org/index.php/Virtual_user_mail_system And i am stuck at PostfixAdmin, because the tutorial depends on Postfixadmin to create the database tables The tutorial uses Apache, but i use Nginx, so i think the problem lies in my nginx config file. This is the content of /etc/nginx/sites-available/postfix which is symlinked to /etc/nginx/sites-enabled/postfix server { if ($host = houtworm.email) { return 301 https://$host$request_uri; } } server { listen 443 ssl; server_name houtworm.email; root /usr/share/webapps/postfixAdmin/public/; index index.php; charset utf-8; ## SSL settings ssl_certificate /etc/letsencrypt/live/houtworm.email/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/houtworm.email/privkey.pem; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot ssl_protocols TLSv1.2; ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:!aNU LL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4"; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_ecdh_curve add_header Strict-Transport-Security max-age=31536000; # add_header X-Frame-Options DENY; # auth_basic "Restricted area"; # auth_basic_user_file /etc/nginx/passwd; location / { try_files $uri $uri/ index.php; } location ~* \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; } } server { listen 80; server_name houtworm.email; return 404; # managed by Certbot } I only get blank pages, nothing in the body, no 404. nothing in the logs of nginx, php-fpm or postfix, no entries for postfixadmin. I am not sure what to do at this point, I thought i would ask the Gurus :) Greets, Danny |
From: Christoph L. <chr...@it...> - 2018-04-02 21:17:18
|
Am 02.04.18 um 20:37 schrieb Johnny A. Solbu: > On Monday 2. April 2018 18.32, Christoph Lechleitner wrote: >> Am 02.04.18 um 15:31 schrieb Johnny A. Solbu: >>> Debian provides tools available for automatically checking for the latest version, download it, apply any patches and declare it ready for build. >> >> What's that tool's name? > > uscan and uupdate [...] Thanks for all the info and your repo efforts! Regards, Christoph |
From: Johnny A. S. <jo...@so...> - 2018-04-02 18:38:11
|
On Monday 2. April 2018 18.32, Christoph Lechleitner wrote: > Am 02.04.18 um 15:31 schrieb Johnny A. Solbu: > > Debian provides tools available for automatically checking for the latest version, download it, apply any patches and declare it ready for build. > > What's that tool's name? uscan and uupdate When we check for new version of a package, we just run «uscan» in the package folder (i.e. where the «debian/» folder resides) It's magic is done using the debian/watch file. This is the line we use to update oidentd for it's new upstream Github repo: == version=3 https://github.com/janikrabe/oidentd/releases .*/oidentd-(\d\S*)\.tar\.gz debian uupdate == > I didn't read up in this area for many years, because I didn't have to ;-) > We don't do re-packaging often, but only if we have to. We do the same, we only update packages when we must. Sometimes to get new functionality that we want, > > It is this process Debian packagers use for updating package sources. > > We do this on our public local repo, for our servers. > > How public? > > Asking for a friend ;-) https://www.kristshell.net/debian/ If it's interesting, I also have a few public rpm repos (I am a packager for Mageia) https://www.solbu.net/progs/rpms/ Feel free to use any of them. :-) We have squeeze, wheezy and jessie «codenames» in that repo. The easy way to install that repo is by installing this package: https://www.kristshell.net/debian/pool/main/k/kristshell-repo/kristshell-repo_1.3_all.deb That package will set up the lines below in sources.list.d/kristshell.list, and add our repo key. == deb http://login.kristshell.net/debian jessie main deb-src http://login.kristshell.net/debian jessie main == Also, if you «dget https://www.kristshell.net/debian/pool/main/k/kristshell-repo/kristshell-repo_1.3.dsc» it will fetch and unpack the source that we use for easy updating our repo accross all servers. So if we need to move the repo, we just update that package and all servers will switch on next package updates. it is also easy to properly setup our repo on new servers. -- Johnny A. Solbu web site, http://www.solbu.net PGP key ID: 0x4F5AD64DFA687324 |
From: Christoph L. <chr...@it...> - 2018-04-02 16:33:29
|
Am 02.04.18 um 15:31 schrieb Johnny A. Solbu: > On Monday 2. April 2018 14.39, Christoph Lechleitner wrote: >> Am 02.04.18 um 12:41 schrieb Johnny A. Solbu: >> Adding source repo support to the underlying software ("PBA") would require a lot of developer time > > We use reprepro for this «reprepro includedsc <repo name (jessie/wheezy/whatever)> package_version.dsc», and it add the source files in the proper repo all by itself. There are 10s of solutions, we developed ours when there were maybe 2 that didn't fit our needs back then. > And unless you are the copyright holder and publish the packages for everyone to download, you often have no choice but to provide the source packages. > GPLv2 §3 and GPLv3 §6 states that one need to ship the source package, /or/ provide a written offer valid for 3 full years after last binary release stating that anyone asking for the source package should get it. Anything else is a violation of the GPL license[1]. Hmm. Packaging "ate" the github link in the control file, but the description points to my github fork, should be satisfactory. The other few 3rd party projects we re-compile (for windows crossbuilding) are covered in a similar way, the (re)packaging sources are publicly available via anonymous svn. Interesting point though. >>> If one want to make changes or customize the deb package, >> >> ... then one should and would use the upstream git anyway (which is fully debianzed) or maybe use the source packages from Debian or a Debian derivate. > > Debian provides tools available for automatically checking for the latest version, download it, apply any patches and declare it ready for build. What's that tool's name? I didn't read up in this area for many years, because I didn't have to ;-) We don't do re-packaging often, but only if we have to. Besides version jumps beyond difficult versions in debian or centos versions used by our customers (some 5 cases) we had to apply situation-critical 3rd party patches to the debian kernel before they made it through the normal process. > It is this process Debian packagers use for updating package sources. > We do this on our public local repo, for our servers. How public? Asking for a friend ;-) Our repos as well as our clean room builders (dedicated servers, with scripts around pbuilder) are organized in a slightly non-standard way, and I don't want to change that anytime soon (there are reasons we do it a bit differently). This is why introduction of source repos will require more work than one might expect. It is on our wishlist though, for years, it will happen, maybe this summer. Regards, Christoph |
From: Johnny A. S. <jo...@so...> - 2018-04-02 13:31:45
|
On Monday 2. April 2018 14.39, Christoph Lechleitner wrote: > Am 02.04.18 um 12:41 schrieb Johnny A. Solbu: > With arch independent there's no real difference between binary and source packages ;-) Yes, there is. You can't take a deb file and rebuild it, for that you need the source package. > Adding source repo support to the underlying software ("PBA") would require a lot of developer time We use reprepro for this «reprepro includedsc <repo name (jessie/wheezy/whatever)> package_version.dsc», and it add the source files in the proper repo all by itself. > and some valuable disc space. I can understand the diskspace argument. And unless you are the copyright holder and publish the packages for everyone to download, you often have no choice but to provide the source packages. GPLv2 §3 and GPLv3 §6 states that one need to ship the source package, /or/ provide a written offer valid for 3 full years after last binary release stating that anyone asking for the source package should get it. Anything else is a violation of the GPL license[1]. > > If one want to make changes or customize the deb package, > > ... then one should and would use the upstream git anyway (which is fully debianzed) or maybe use the source packages from Debian or a Debian derivate. Debian provides tools available for automatically checking for the latest version, download it, apply any patches and declare it ready for build. It is this process Debian packagers use for updating package sources. We do this on our public local repo, for our servers. [1] https://www.softwarefreedom.org/resources/2008/compliance-guide.html – section 4 -- Johnny A. Solbu web site, http://www.solbu.net PGP key ID: 0x4F5AD64DFA687324 |
From: Christoph L. <chr...@it...> - 2018-04-02 12:40:13
|
Am 02.04.18 um 12:41 schrieb Johnny A. Solbu: > On Tuesday 13. March 2018 16.37, Christoph Lechleitner wrote: >> Yep, a simple >> dpkg-buildpackage -b -us -uc >> ran through without issues. >> >> I'll probably test the resulting package on our own server soon, >> with nighly backups as insurance. > > first, sorry for not seeing this earlier. Don't be, it wouldn't have made any difference to my choices ;-) > If there is going to be an upstream repo for everyone to use, Our's is an upstream-based repo, not an upstream repo, and I think that's clear enough. Keeping our repo private would be wrong. > I highly advice against building binary only packages. With arch independent there's no real difference between binary and source packages ;-) > (The «-b» switch) In our case there'd be much more to it. Our clean room build infrastructure has suited us well for almost a decade now, providing deb and rpm repos and deb-packaged win32 and win64 crossbuilds for every bit of software (libraries, frameworks, apps, cross compilers, ...) we produce or need to reproduce. Adding source repo support to the underlying software ("PBA") would require a lot of developer time and some valuable disc space, for no real gain whatsoever, so to me it'd feel like a waste of resources. > I am one of those that utterly refuse to install a package (deb or rpm) if the source package is not available, Suit yourself. > If one want to make changes or customize the deb package, ... then one should and would use the upstream git anyway (which is fully debianzed) or maybe use the source packages from Debian or a Debian derivate. I admit there are situations where source packages can be useful (to build upon some distro's integration and security patches), but this is no such case at all. I haven't made any real changes, apart from unavoidable adaptions to our slightly non-standard and potentially over-customized build infrastructure. There is one enhancement on my wishlist though that I might apply someday: The current packages enabling the apache2 conf snippet globally and without asking during postinst, that's a bad idea in the ages of https-everywhere, letsencrypt and SNI. Fortunately our servers' /etc directories are "gittified" (under git control) now ;-)) Regards, Christoph |
From: Johnny A. S. <jo...@so...> - 2018-04-02 11:00:26
|
On Tuesday 13. March 2018 16.37, Christoph Lechleitner wrote: > Yep, a simple > dpkg-buildpackage -b -us -uc > ran through without issues. > > I'll probably test the resulting package on our own server soon, > with nighly backups as insurance. first, sorry for not seeing this earlier. If there is going to be an upstream repo for everyone to use, I highly advice against building binary only packages. (The «-b» switch) I am one of those that utterly refuse to install a package (deb or rpm) if the source package is not available, and I know that I am not alone in this. If one want to make changes or customize the deb package, one can run «apt-get source <package>» and it will fetch the sources and prepare for local build. (No, the tarball is not enough, we want the source packages also) -- Johnny A. Solbu web site, http://www.solbu.net PGP key ID: 0x4F5AD64DFA687324 |
From: Christoph L. <chr...@it...> - 2018-04-01 17:28:54
|
Am 13.03.18 um 16:37 schrieb Christoph Lechleitner: > Am 12.01.18 um 21:24 schrieb Christian Boltz: >> Am Samstag, 30. Dezember 2017 schrieb Christoph Lechleitner: >>> On 2017-12-30 14:08, Christian Boltz wrote: >>>> The openSUSE build service might be another option. I'm already >>>> building the RPM package there, and if someone gets me started with >>>> building DEBs there, we'd have everything at one place, which would >>>> make the release work easier. >>> >>> I should be able to help here, we use debian packages for everthing >>> for 7 years now (even for the windows crossbuilds). >> >> :-) >> >> We already have the debian/* files in git, so building a DEB on a Debian >> system is probably easy. > > Yep, a simple > dpkg-buildpackage -b -us -uc > ran through without issues. > > I'll probably test the resulting package on our own server soon, It works. >> The PostfixAdmin git is "boring" - for me, git commit, pull and push are >> enough, which also means I didn't need to learn more. At least you made me use github ;-) Ac. to what seems to be best practice I've created a fork https://github.com/CLechleitner42/postfixadmin and a branch https://github.com/CLechleitner42/postfixadmin/tree/pba2deb.clazzes.org where I adapted the debianization to allow me to feed postfixadmin trunk debs into the public debian repository of our Open Source project Clazzes.org, so I can keep our 2 installations up-to-date easy and clean. Full details about my efforts can be found here: https://confluence.clazzes.org/x/CQAuAQ If someone wants an account there just ask. We had to disable public self registration after some nasty Spam incidents, but we are open to honest account requests (and we have to be; as for other OpenSource platforms Atlassian provides free licenses of Confluence and Jira). I'm not sure if or when I'll find time to spend on eventual SuSE build service integration, but I will update our packages whenever critical or interesting developments happen on the postfixadmin upstream repo, at least as long as we stay with our current mailserver setups (they're bound to be replaced by something fresh with quarantine zones and the like, but that will not happen soon). Regards, Chrisotph Lechleitner |
From: Michael N. <ne...@ne...> - 2018-03-13 16:37:41
|
Hi Christoph On 13.03.2018 16:37, Christoph Lechleitner wrote: > Some content of the debian/ directory seems to come from Debian's maintainers directly. > > So, just out of curiousity: > Is there some kind of established roundtrip workflow between your upstream git and debian's source git? No there isn't. Every now and then I am begging a friend of mine who is a DD to update the package in Debian. The original Debian package maintainer is unfortunately pretty much MIA wrt. the postfixadmin package. This friend of mine hates to take snapshots, so I am always eagerly waiting for Christian to change the version number..... Cheers Mike |
From: Christoph L. <chr...@it...> - 2018-03-13 15:37:42
|
Am 12.01.18 um 21:24 schrieb Christian Boltz: > Am Samstag, 30. Dezember 2017 schrieb Christoph Lechleitner: >> On 2017-12-30 14:08, Christian Boltz wrote: Long time no read ;-) >>> The openSUSE build service might be another option. I'm already >>> building the RPM package there, and if someone gets me started with >>> building DEBs there, we'd have everything at one place, which would >>> make the release work easier. >> >> I should be able to help here, we use debian packages for everthing >> for 7 years now (even for the windows crossbuilds). > > :-) > > We already have the debian/* files in git, so building a DEB on a Debian > system is probably easy. Yep, a simple dpkg-buildpackage -b -us -uc ran through without issues. I'll probably test the resulting package on our own server soon, with nighly backups as insurance. > The PostfixAdmin git is "boring" - for me, git commit, pull and push are > enough, which also means I didn't need to learn more. Some content of the debian/ directory seems to come from Debian's maintainers directly. So, just out of curiousity: Is there some kind of established roundtrip workflow between your upstream git and debian's source git? > However I never tried to build a DEB in the > openSUSE build service, so help in this area is welcome ;-) I see what I can do. If openSUSE should be too demanding (there were reasons for why we ran away from SuSE some 10 years ago) I might create a branch that feeds binary packages in deb.clazzes.org, the debian repo of our own open source project. We'll see. > The salt repo for the openSUSE infrastructure uses a slightly more > interesting git repo where I at least need to use branches. That sounds "very SuSE". > If you have "silly questions" about git, feel free to ask ;-) Btw., we have collected a few links to useful git tutorials and the like, including some made for subversion veterans: https://confluence.clazzes.org/x/EIB3 Regards, Christoph Lechleitner |
From: Christoph L. <chr...@it...> - 2018-01-12 20:46:12
|
Am 12.01.18 um 21:24 schrieb Christian Boltz: >>> - Also, the new default only applies when adding the column, so if >>> you> >>> already have the activeuntil column, the 2000-01-01 values will >>> survive. In theory the new default also applies when doing an >>> INSERT >>> without specifying activeuntil, but this won't happen with >>> PostfixAdmin ;-) >> >> So that's mostly a concern for custom or third-party tools. > > That, and for people who upgraded with the buggy upgrade code - which > basically means everybody who upgraded from 2.3.x (or older) to 3.x. We started with 2.1 or so. > Yes, we kept the history when migrating to github. Also, the SVN history > won't vanish just because I "svn rm" all files and replace them with a > README ;-) (done now) Right. But one has to check out or switch to the revision before the rm to see anything beyond the Readme ;-) >> I should be able to help here, we use debian packages for everthing >> for 7 years now (even for the windows crossbuilds). > > :-) > > We already have the debian/* files in git, so building a DEB on a Debian > system is probably easy. However I never tried to build a DEB in the > openSUSE build service, so help in this area is welcome ;-) Hmm. We left SuSE over 10 years ago, I never tried their build service. So much to learn ;-) We'll see. > Oh, and I still have a small (non-public) project that uses CVS for > historical reasons ;-) LOL. Our 2 most important projects started in cvs too, but as soon as the project grew to the huge number of 2 developers it got complicated, we happily migrated to svn rather early. > If you have "silly questions" about git, feel free to ask ;-) Thanks. My business partner is relatively familiar with git, over the last 3 years or so he made contributions to several open source projects using git pull requests. For now I'm happy the manually copied vacation.pl does it's job and I have more critical priorities (Meltdown & Spectre, DRBD hickups, customer project deadlines ...), but switching to the postfixadmin upstream using deb packages definitely is on my has-to-be-done-soon-list ;-) Regards, Christoph |
From: Christian B. <pos...@cb...> - 2018-01-12 20:24:44
|
Hello, Am Samstag, 30. Dezember 2017 schrieb Christoph Lechleitner: > On 2017-12-30 14:08, Christian Boltz wrote: > > Yes, that's the expected behaviour: > > 0 = reply exactly once for the whole vacation period > > 1 = reply to every mail > > 2 = reply if the last reply was sent more than $seconds ago > > > > The examples in config.inc.php will tell you the same ;-) > > Sorry I didn't look there. > > There was no need to touch that in years. ;-) [vacation end date when doing database upgrades] > > I just pushed a fixed upgrade.php to fix this, but there's a fine > > print: > > - As I just found out, sqlite doesn't support to change the > > field> > > default later, so people with existing sqlite databases will have > > to > > live with the wrong default. > > > > - Also, the new default only applies when adding the column, so if > > you> > > already have the activeuntil column, the 2000-01-01 values will > > survive. In theory the new default also applies when doing an > > INSERT > > without specifying activeuntil, but this won't happen with > > PostfixAdmin ;-) > > So that's mostly a concern for custom or third-party tools. That, and for people who upgraded with the buggy upgrade code - which basically means everybody who upgraded from 2.3.x (or older) to 3.x. > > (Just wondering - should I do a final commit that deletes everything > > and only puts a README with a pointer to github there?) > > If you are interested in the long term change history I'd double check > if the svn era history has survived the migration to github. > > Otherwise the only argument against deleting would be eventual old > deep links in issues, mailing list archives and the like. Yes, we kept the history when migrating to github. Also, the SVN history won't vanish just because I "svn rm" all files and replace them with a README ;-) (done now) > I have the luxury of an internal instance (for our own domain, no > customers) where nobody needs vacation.pl, so I can easily test it > anyways. Oh, I even have a full mailserver setup with Postfix, Dovecot and PostfixAdmin on my laptop. Actually I even have multipe PostfixAdmin instances - a "productive" one to manage the mailboxes I use as local IMAP storage, and a few with test databases for PostfixAdmin development. > >> 3. A PHP script, currently PostgreSQL only (other limits, too): > >> https://sourceforge.net/p/postfixadmin/patches/9/ > >> > >> 4. A python script, currently PostgreSQL only (other limits, too): > >> https://sourceforge.net/p/postfixadmin/patches/10/ > > > > These are user contributions, but since they are incomplete, it's > > unlikely that we pick them up. They can't completely replace the > > current perl script because of their limitations and I'm not going > > to maintain multiple vacation scripts. > > > > Actually it might be a good idea to finally close these tickets as > > rejected - having them hang around isn't useful for anybody. > > I agree. Both rejected now. > Unless it's already there a link to the refurbished vacation.pl > wouldn't hurt neither. I'll just assume that people know how to download the latest tarball ;-) > > The openSUSE build service might be another option. I'm already > > building the RPM package there, and if someone gets me started with > > building DEBs there, we'd have everything at one place, which would > > make the release work easier. > > I should be able to help here, we use debian packages for everthing > for 7 years now (even for the windows crossbuilds). :-) We already have the debian/* files in git, so building a DEB on a Debian system is probably easy. However I never tried to build a DEB in the openSUSE build service, so help in this area is welcome ;-) > But it might take me some time to get comfy with git, because we > happily still use svn for our own commercial and open source > projects. I know this problem ;-) The PostfixAdmin git is "boring" - for me, git commit, pull and push are enough, which also means I didn't need to learn more. The salt repo for the openSUSE infrastructure uses a slightly more interesting git repo where I at least need to use branches. Also, AppArmor switched from bzr to gitlab recently - which finally forced me to learn some more things about git. Oh, and I still have a small (non-public) project that uses CVS for historical reasons ;-) If you have "silly questions" about git, feel free to ask ;-) Regards, Christian Boltz -- Wer nur "geht nicht" schreit, kann als Antwort auch nur ein "muß aber gehen" kriegen, denn Kristallkugeln haben wir nicht. :-) [Peer Heinlein in postfixbuch-users] |
From: Christian B. <pos...@cb...> - 2017-12-30 13:25:29
|
Hello, Am Mittwoch, 27. Dezember 2017 schrieb Christoph Lechleitner: > Problem 1: Sender.pm almost unusable in Debian stretch: > > Unfortunately, as I just commented in > https://sourceforge.net/p/postfixadmin/patches/136/#e917 > the Sender.pm coming with Debian stretch can not be satisfied by > adding to the first line of vacation.pl -X any more. > > I kind-of worked around that commenting out some lines in Sender.pm, > which is less than ideal ;-) Indeed ;-) > I might be able to patch out the Sender.pm dependency, but it seems > that has already happend (on the trunk at least) and might be in vain > for other reasons, too. Yes, this was already changed in git. > Problem 2: vacation.pl confusion around $interval resp. interval_time: > > Interval variant 1, legacy: > > In the configuration part, $interval is supposed to set the vacation > message interval for all vacations. > > This is overruled though, by > $interval = get_interval($to); > > Interval variant 2: > > The patch dated 2012-04-19 is (in the old version, not in the trunk > version) described to introduce a policy where interval (or > interval_time?) means > 0 = one reply, 1 = autoreply, > 1 = Delay reply Yes, that's the expected behaviour: 0 = reply exactly once for the whole vacation period 1 = reply to every mail 2 = reply if the last reply was sent more than $seconds ago The examples in config.inc.php will tell you the same ;-) > Interval variant 3: > > The actual interval used is detected through get_interval() only, > which queries interval_time from vacation. > > Interval future? > > Can someone clarify the current idea around interval / interval_time? > > I guess it's that 0/1/>1 strategy? Right, see above. > Problem 3, only somehow related: > > The recent upgrade from Debian jessie to stretch, i.e. postfixadmin > 2.3.7 to 3.0.2, seems to have set vacation.activefrom and > vacation.activeuntil to 2000-01-01 00:00:00. > > Could that be? > > Are activefrom, activeuntil supposed to be used? > > (I hate databases' date types ..., we usually use unixtime seconds or > milliseconds as integers) Oops, interesting bug. We use the 2000-01-01 as default date mostly because you can't use CURRENT_TIMESTAMP on more than one field in MySQL. This usually isn't a problem because it's "old enough" - but for the vacation end date, we should default to a date in the (far) future when adding the "activeuntil" field during the upgrade. This is one of the few cases where I'll modify an existing upgrade function in upgrade.php - doing this change later means to get a wrong value when adding the column. (Nevertheless, I'll add a new function to keep the scheme in sync for those who already have the activeuntil column.) I just pushed a fixed upgrade.php to fix this, but there's a fine print: - As I just found out, sqlite doesn't support to change the field default later, so people with existing sqlite databases will have to live with the wrong default. - Also, the new default only applies when adding the column, so if you already have the activeuntil column, the 2000-01-01 values will survive. In theory the new default also applies when doing an INSERT without specifying activeuntil, but this won't happen with PostfixAdmin ;-) > Intermediate question: > > Are there plans to remove support for MySQL/MariaDB from postfixadmin, > making it PostgreSQL-only? No worries, I use PostfixAdmin with MariaDB myself ;-) > Conclusion rg. vacation: > > If I understand it correctly there are currently 4 vacation scripts > around: > > 1. Old vacation.pl with several issues (Sender.pm, interval), but > MySQL support. > > 2. Newer vacation.pl in svn SVN won't see any updates anymore, so please ignore it and use github. (Just wondering - should I do a final commit that deletes everything and only puts a README with a pointer to github there?) > Concluding from the intermediate name vacation-pgsql.pl it seems it is > or was PostgreSQL only? Yes. Years ago, we had separate vacation scripts for MySQL and PostgreSQL. Needless to say that that was a maintenance pain, so we decided to merge everything into one script. A "real" merge is difficult with two completely different scripts, so the PostgreSQL script "won" and got some additions to handle MySQL specific cases. > The current version, > https://github.com/postfixadmin/postfixadmin/blob/master/VIRTUAL_VACAT > ION/vacation.pl does contain some MySQL code, but is that up-to-date? I'm using it (the version from PostfixAdmin 3.0.2) with MySQL on several servers, so I'm quite sure it works ;-) > 3. A PHP script, currently PostgreSQL only (other limits, too): > https://sourceforge.net/p/postfixadmin/patches/9/ > > 4. A python script, currently PostgreSQL only (other limits, too): > https://sourceforge.net/p/postfixadmin/patches/10/ These are user contributions, but since they are incomplete, it's unlikely that we pick them up. They can't completely replace the current perl script because of their limitations and I'm not going to maintain multiple vacation scripts. Actually it might be a good idea to finally close these tickets as rejected - having them hang around isn't useful for anybody. Personally I prefer python over perl, so if someone sends us a vacation.py that implements all features of vacation.pl, I'll consider it as a replacement ;-) (and make vacation.pl a wrapper to avoid that everybody needs to change master.cf ;-) > What are the plans for vacation script's future? > The newer vacation.pl from the git trunk? Yes. > Vacation strategies: > > What does anybody propose for the immediate situation of us (and > propably other Debian stretch setups)? > > Should we switch to the new vacation.pl? > Does that have any open issues we should know about? > (I am willing to help with those if there are any) Just check the open bugs (which are still spread across Sourceforge and github) - but in general, we fix bugs and (hopefully) don't introduce new ones ;-) > Should we rather add MySQL support to on of the 3rd party vacation > scripts in PHP resp. Python? As I wrote above - personally I'm a python fan because it forces you to write clean code, but I'm not sure if rewriting vacation.pl "just to make it python" is worth the effort. > Should we switch to postfixadmin 3.1 completely? Using the latest version is always a good idea ;-) > We might be able to provide a repository for Debian (and Devuan, > Ubuntu, ...) within our OpenSource platform, Clazzes.org (resp. the > http://deb.clazzes.org repository collection) :-) The openSUSE build service might be another option. I'm already building the RPM package there, and if someone gets me started with building DEBs there, we'd have everything at one place, which would make the release work easier. Regards, Christian Boltz -- > es ist doch ausgesprochen ruhig hier und das nach dem Release einer > neuen openSUSE Version. Sollte es etwa keine Probleme geben? Vermutlich sind alle damit beschaeftigt, kmail2 ans Laufen zu bekommen. Dann gibt es auch wieder Mails :-) [> Marco Röben und Thomas Moritz in opensuse-de] |
From: Christoph L. <chr...@it...> - 2017-12-27 22:58:51
|
Hello everybody! We are using postfixadmin for over 4 years now, first in Debian wheezy, then Debian jessie, now Debian stretch. We are using MySQL and the old "stable" vacation.pl. We appreciate the project, obviously, and early on I even submitted a patch for vacation.pl that got accepted: https://sourceforge.net/p/postfixadmin/patches/117/ Unfortunately, after our upgrade to Debian stretch the vacation script situation has became more than difficult, and I'd like to find a way out of that SNAFU. I'm willing to work on more patches and the like, but not without discussing the strategy first, so here come our current problems and some thoughts ... Problem 1: Sender.pm almost unusable in Debian stretch: Unfortunately, as I just commented in https://sourceforge.net/p/postfixadmin/patches/136/#e917 the Sender.pm coming with Debian stretch can not be satisfied by adding to the first line of vacation.pl -X any more. I kind-of worked around that commenting out some lines in Sender.pm, which is less than ideal ;-) I might be able to patch out the Sender.pm dependency, but it seems that has already happend (on the trunk at least) and might be in vain for other reasons, too. Problem 2: vacation.pl confusion around $interval resp. interval_time: Interval variant 1, legacy: In the configuration part, $interval is supposed to set the vacation message interval for all vacations. This is overruled though, by $interval = get_interval($to); Interval variant 2: The patch dated 2012-04-19 is (in the old version, not in the trunk version) described to introduce a policy where interval (or interval_time?) means 0 = one reply, 1 = autoreply, > 1 = Delay reply which seems to match the broken <select class="flat" name="fInterval_Time"> <option value="0" selected="selected"></option> </select> created by vacation.php (3.0.2, Debian stretch). I have not investigated the trunk version of vacation.php yet, sorry. Interval variant 3: The actual interval used is detected through get_interval() only, which queries interval_time from vacation. Interval future? Can someone clarify the current idea around interval / interval_time? I guess it's that 0/1/>1 strategy? Problem 3, only somehow related: The recent upgrade from Debian jessie to stretch, i.e. postfixadmin 2.3.7 to 3.0.2, seems to have set vacation.activefrom and vacation.activeuntil to 2000-01-01 00:00:00. Could that be? Are activefrom, activeuntil supposed to be used? (I hate databases' date types ..., we usually use unixtime seconds or milliseconds as integers) Intermediate question: Are there plans to remove support for MySQL/MariaDB from postfixadmin, making it PostgreSQL-only? Changing our 2 installations of postfixadmin & postfix & dovecot & apache authentication (for CalDAV) from MySQL/MariaDB to PostgreSQL would be a LOT OF HARD WORK (and I don't like Debian's approach to PostgreSQL upgrades), but we might be able to manage it. Conclusion rg. vacation: If I understand it correctly there are currently 4 vacation scripts around: 1. Old vacation.pl with several issues (Sender.pm, interval), but MySQL support. 2. Newer vacation.pl in svn Concluding from the intermediate name vacation-pgsql.pl it seems it is or was PostgreSQL only? The current version, https://github.com/postfixadmin/postfixadmin/blob/master/VIRTUAL_VACATION/vacation.pl does contain some MySQL code, but is that up-to-date? 3. A PHP script, currently PostgreSQL only (other limits, too): https://sourceforge.net/p/postfixadmin/patches/9/ 4. A python script, currently PostgreSQL only (other limits, too): https://sourceforge.net/p/postfixadmin/patches/10/ What are the plans for vacation script's future? The newer vacation.pl from the git trunk? Vacation strategies: What does anybody propose for the immediate situation of us (and propably other Debian stretch setups)? Should we switch to the new vacation.pl? Does that have any open issues we should know about? (I am willing to help with those if there are any) Should we rather add MySQL support to on of the 3rd party vacation scripts in PHP resp. Python? Should we switch to postfixadmin 3.1 completely? We might be able to provide a repository for Debian (and Devuan, Ubuntu, ...) within our OpenSource platform, Clazzes.org (resp. the http://deb.clazzes.org repository collection) Regards, Christoph -- Christoph Lechleitner ------------------------------------------------------------------------ ITEG IT-Engineers GmbH | Conradstr. 5, A-6020 Innsbruck, Austria Mail: chr...@it... | Web: http://www.iteg.at/ ------------------------------------------------------------------------ |
From: Sophie L. <so...@kl...> - 2017-11-27 21:54:02
|
Issue was permissions 555 / root:root on directory. Changed and works :) Problem solved via the irc. > On 27 Nov 2017, at 20:40, Sophie Loewenthal <so...@kl...> wrote: > > Hi guys, > > Apologies for quick set up question! > > In postfixadmin 3.1 I have this config for sqlite in config.local.php: > > $CONF['database_type'] = 'sqlite'; > $CONF['database_host'] = 'localhost'; > $CONF['database_user'] = 'postfix'; > $CONF['database_password'] = 'password'; > $CONF['database_name'] = '/var/sqlite/postfixadmin.db'; > $CONF['database_prefix'] = ''; > > -rwxr-xr-x 1 www-data mail 0 Nov 27 19:28 /var/sqlite/postfixadmin.db > > This was created with the command # sqlite3 /var/sqlite/postfixadmin.db > > > When I call setup.php this message is returned: > > • Depends on: SQLite - OK > • Error: Can't connect to database > Please edit the $CONF['database_*'] parameters in config.local.php. > DEBUG INFORMATION > Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty. > > Any idea why this is breaking? > > > Kind regards, Sophie. > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Postfixadmin-devel mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel |
From: Sophie L. <so...@kl...> - 2017-11-27 19:56:35
|
Hi guys, Apologies for quick set up question! In postfixadmin 3.1 I have this config for sqlite in config.local.php: $CONF['database_type'] = 'sqlite'; $CONF['database_host'] = 'localhost'; $CONF['database_user'] = 'postfix'; $CONF['database_password'] = 'password'; $CONF['database_name'] = '/var/sqlite/postfixadmin.db'; $CONF['database_prefix'] = ''; -rwxr-xr-x 1 www-data mail 0 Nov 27 19:28 /var/sqlite/postfixadmin.db This was created with the command # sqlite3 /var/sqlite/postfixadmin.db When I call setup.php this message is returned: • Depends on: SQLite - OK • Error: Can't connect to database Please edit the $CONF['database_*'] parameters in config.local.php. DEBUG INFORMATION Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty. Any idea why this is breaking? Kind regards, Sophie. |
From: Johnny A. S. <jo...@so...> - 2017-02-24 08:10:23
|
On Thursday 23. February 2017 22.47, Robert Moskowitz wrote: > On 02/23/2017 03:28 PM, Christian Boltz wrote: > > AFAIK Sourceforge doesn't provide direct wget'able download URLs, so > > you'll always have to start at the web interface. Yes, they do. All download links on SourceForge is wget-able. I usually go to the files section of any project and download from there. > wget https://sourceforge.net/projects/postfixadmin/files/latest/download > > downloads the tarball as file 'download' > > Rename it and you are on your way. It's even easier: add the switch «--content-disposition» $ wget --content-disposition https://sourceforge.net/projects/postfixadmin/files/latest/download will download the latest version and save it as postfixadmin-3.0.2.tar.gz, or whatever the latest version is when downloading. But «files/latest/download» doesn't point to the latest version, but the latest uploaded file, which usually is the latest version, but not allways. I run a few projects on SourceForge, and also upload gpg signatures (.sig), so those who care can verify that I uploaded it. If the sig file is uploaded after the tarball, sourceForge select the the sig file as the latest version. -- Johnny A. Solbu web site, http://www.solbu.net PGP key ID: 0x4F5AD64DFA687324 |
From: Robert M. <rg...@ht...> - 2017-02-23 21:47:38
|
On 02/23/2017 03:28 PM, Christian Boltz wrote: > Hello, > > Am Donnerstag, 16. Februar 2017, 19:58:39 CET schrieb Robert Moskowitz: >> On a mail server with no GUI, is there a nice wget command to download >> the .tar.gz directly to the server? >> >> Something like >> >> wget >> https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixa >> dmin-n.n.n.tar.gz >> >> ? >> >> Or does this defeat the download count feature of sourceforge? > AFAIK Sourceforge doesn't provide direct wget'able download URLs, so > you'll always have to start at the web interface. > > My usual trick is to copy the link behind "if the download doesn't start > automatically, click here" - it points to the tarball on a mirror and > can be used with wget. I discovered that: wget https://sourceforge.net/projects/postfixadmin/files/latest/download downloads the tarball as file 'download' Rename it and you are on your way. I got this URL from right clicking on the download button then copying link. > > > Regards, > > Christian Boltz |
From: Aaron L. <aa...@ac...> - 2017-02-23 21:10:59
|
On Feb 23 21:28, Christian Boltz wrote: > Hello, > > Am Donnerstag, 16. Februar 2017, 19:58:39 CET schrieb Robert Moskowitz: > > On a mail server with no GUI, is there a nice wget command to download > > the .tar.gz directly to the server? > > > > Something like > > > > wget > > https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixa > > dmin-n.n.n.tar.gz > > > > ? > > > > Or does this defeat the download count feature of sourceforge? > > AFAIK Sourceforge doesn't provide direct wget'able download URLs, so > you'll always have to start at the web interface. They're just well-hidden! Try: # pkgver=3.0.2 # wget https://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-${pkgver}/postfixadmin-${pkgver}.tar.gz Lifted from the Arch Linux PKGBUILD: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/postfixadmin -Aaron |