From dbird at sgul.ac.uk Mon Jun 1 23:51:16 2020 From: dbird at sgul.ac.uk (Daniel Bird) Date: Mon, 1 Jun 2020 22:51:16 +0000 Subject: [ZendTo] SAML Auth References: Message-ID: Evening all, I?ve just ?upgraded? to version 6 (fresh install, and moved over some configs and drop offs) from version 4 and I have it working as per our previous install, using LDAP auth. Great stuff! ? I was planning on having a go at getting SAML auth against ADFS up and running, but It appears I am stumbling at the first hurdle, and the SAML RPM packages are missing? https://zend.to/saml#packages FYI; CentOS 8. Any pointers? ----------- #> rpm --import https://zend.to/files/zendto.gpg.asc #> rpm -Uvh https://zend.to/files/zendto-repo.rpm #> yum install zendto-saml Last metadata expiration check: 0:06:37 ago on Mon 01 Jun 2020 23:25:08 BST. No match for argument: zendto-saml Error: Unable to find a match: zendto-saml # yum search zendto Last metadata expiration check: 0:06:46 ago on Mon 01 Jun 2020 23:25:08 BST. ======================================================================================= Name Exactly Matched: zendto ======================================================================================= zendto.noarch : Web-based File Transfer and Storage System zendto.noarch : Web-based File Transfer and Storage System ====================================================================================== Name & Summary Matched: zendto ====================================================================================== zendto-repo.noarch : Yum Repository Setup for ZendTo Or even #> curl -O https://zend.to/files/zendto-saml_version.rpm #> curl -O https://zend.to/files/zendto-saml_6.0-1.rpm #> file zendto-saml_6.0-1.rpm zendto-saml_6.0-1.rpm: HTML document, ASCII text #> more zendto-saml_6.0-1.rpm 404 Not Found

Not Found

The requested URL /files/zendto-saml_6.0-1.rpm was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

-------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at pcfreak.de Tue Jun 2 07:14:29 2020 From: mailinglists at pcfreak.de (Der PCFreak) Date: Tue, 2 Jun 2020 08:14:29 +0200 Subject: [ZendTo] LDAP authentication In-Reply-To: References: <5EC444660200001300143E82@mail.msktd.com> <6fbcd674-9b2b-d0fb-0a5a-78176fb9de83@pcfreak.de> Message-ID: Hi, I recently also went the LDAPs way on CentOS 7. The way described at https://zend.to/activedirectory.php did not work for me, especially the part where to put ther certificate of the CA and the modifications to ldap.conf - but it was very easy to get it working. We use Microsoft Active Directory here and the Domain Controllers (which I authenticate against) have a certificate created by our internal, active-directory-integrated CA. The Windows admins told me to use port 636 with ldaps to connect and gave me the public certificate of the CA that issued the DCs certificates. So the only thing (for CentOS7) I had to do was to copy the CAs public certificate to |/etc/pki/ca-trust/source/anchors/| and then execute the command |update-ca-trust| which imported the certificate into the trusted CA database. After that everything worked fine and I could verify the connection using |ldapsearch|. One should ensure, that you *connect to the DCs using their FQDN* because their certificate usually contains only the FQDN as certificate subject. So I *added the DCs with their IP and FQDN to the CentOS |/etc/hosts| file* and replaced IPs with FQDNs in ZendTo config and setting |'authLDAPUseSSL' => true,| . - All works fine now here. For troubleshooting, you should first do a generic connection test to your AD domain controllers with openssl like this: |openssl s_client -connect fqdn.of.dc:636 -showcerts < /dev/null | This should show the certificate of the DC and a |Verify return code: 0 (ok)|. Then use ldapsearch to check the certificate chain (assuming you have the CA already copied and used |update-ca-trust|) My ldapsearch command to check everything looked like this: |dc="fqdn.of.your.dc" port=636 user="ldapuser at ldapdomain.tld" pass="ldapuserpassword" searchbase="DC=sub,DC=domain,DC=tld" ldapsearch -x -LLL -E pr=200/noprompt -H ldaps://${dc}:${port} -D "${user}" -w "${pass}" -b "$searchbase" dn cn mail memberOf | After ldapsearch succeeded, Zendto worked fine, too. *I did not have to change any defaults in /etc/openldap/ldap.conf to get it working on CentOS7!* Greets Peter On 19/05/2020 22:41, Ken Etter via ZendTo wrote: > Doing some more digging into this and not making much progress.? I was > working on moving ZendTo ldap authentication from port 389 to port 636 > (SSL).? Something wasn't working right, but now my account is locked > out of ZendTo.? Doing a trace from my LDAP server shows that I don't > even get a request from ZendTo.? ZendTo is working for all accounts > except mine.? Is there anything at all within ZendTo that might give > me a clue as to what is going on? > > *Ken Etter*, System Administrator > Architectural Group > 260.432.9337|msktd.com > > > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMAGE_2.png Type: image/png Size: 18080 bytes Desc: not available URL: From Jules at Zend.To Tue Jun 2 10:17:58 2020 From: Jules at Zend.To (Jules) Date: Tue, 2 Jun 2020 10:17:58 +0100 Subject: [ZendTo] SAML Auth In-Reply-To: References: Message-ID: <4c6bd13a-8ce3-124e-133e-a276c4091add@Zend.To> Daniel, Ah, yes. That will be because I forgot to publish it. :-( You should find the package there now! Sorry about that, Jules. On 01/06/2020 23:51, Daniel Bird via ZendTo wrote: > > Evening all, > > I?ve just ?upgraded? to version 6 (fresh install, and moved over some > configs and drop offs) from version 4 and I have it working as per our > previous install, using LDAP auth. Great stuff! ? > > I was planning on having a go at getting SAML auth against ADFS up and > running, but It appears I am stumbling at the first hurdle, and the > SAML ?RPM packages ?are missing? > > https://zend.to/saml#packages > > FYI; CentOS 8. > > Any pointers? > > ----------- > > #> rpm --import https://zend.to/files/zendto.gpg.asc > > #> rpm -Uvh https://zend.to/files/zendto-repo.rpm > > > #> yum install zendto-saml > > Last metadata expiration check: 0:06:37 ago on Mon 01 Jun 2020 > 23:25:08 BST. > > No match for argument: zendto-saml > > Error: Unable to find a match: zendto-saml > > # yum search zendto > > Last metadata expiration check: 0:06:46 ago on Mon 01 Jun 2020 > 23:25:08 BST. > > ======================================================================================= > Name Exactly Matched: zendto > ======================================================================================= > > zendto.noarch : Web-based File Transfer and Storage System > > zendto.noarch : Web-based File Transfer and Storage System > > ====================================================================================== > Name & Summary Matched: zendto > ====================================================================================== > > zendto-repo.noarch : Yum Repository Setup for ZendTo > > Or even > > #> curl -O https://zend.to/files/zendto-saml_version.rpm > > > #> curl -O https://zend.to/files/zendto-saml_6.0-1.rpm > > > #> file zendto-saml_6.0-1.rpm > > zendto-saml_6.0-1.rpm: HTML document, ASCII text > > #> more zendto-saml_6.0-1.rpm > > > > > > 404 Not Found > > > >

Not Found

> >

The requested URL /files/zendto-saml_6.0-1.rpm was not found on > this server.

> >

Additionally, a 404 Not Found > > error was encountered while trying to use an ErrorDocument to handle > the request.

> > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Science is an integral part of culture. It's not this foreign thing, done by an arcane priesthood. It's one of the glories of human intellectual tradition.' - Stephen Jay Gould www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglagm at gmail.com Tue Jun 2 10:34:25 2020 From: douglagm at gmail.com (Gregg Douglas) Date: Tue, 2 Jun 2020 11:34:25 +0200 Subject: [ZendTo] ANNOUNCE: Version 6 released In-Reply-To: References: Message-ID: Hey Jules, Great set of new features and a job well done. Can't wait to get my hands dirty with all these new features Regards Gregg On Sun, May 31, 2020 at 11:41 AM Jules via ZendTo wrote: > Hi folks! > > Major new release today. Version 6.0 has landed. > > The major features since version 5.23 are: > > * Login via OAuth, Yubikeys etc with SAML-based authentication. > * Uploaded files are now sent in small chunks ('maxChunkSize'), and are > automatically retried on failure, to attempt to avoid problems with network > security appliances and the Great Firewall of China. > * Recipients can be made to read and acknowledge some legal text (or > instructions) before being able to download files. > * Users can set the lifetime of a drop-off (within limits) allowing much > shorter-lived drop-offs for sensitive data. > * Now ships in 13 languages. > * Improved automation ability with new "autolist" command that dumps all > drop-off metadata as JSON. > * Admin logins can be restricted to local IP addresses. > * internaldomains.conf can now list individual email addresses as well > as entire domains, so you can give usage permission to someone with a @ > gmail.com address, for example. > > There have been lots of other improvements and fixes since 5.23, for more > information on those see the Change Log for all the 5.24 beta releases: > zend.to/changelog > > I've updated all the repositories, so you should be able to just yum/apt > upgrade. > After updating, run > /opt/zendto/bin/upgrade > and then, especially if you are using yum or are on a RPM-based system, > check the /opt/zendto/templates directory for any *.rpmnew files, and > rename them over the top of your old ones. This will be needed if you have > edited any of the template files. > > If you need to change the text in any of the templates, **please** avoid > editing the templates (*.tpl) directly as it makes upgrades awkward for > you. > There's a better way: read > zend.to/translators > and it will explain how to do it so that future upgrades are smooth, and > without editing the *.tpl files themselves. > > Please report bugs and so on straight away. > > Cheers, > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Gaze not into the abyss, lest you become recognised as an abyss > domain expert, and they expect you to keep gazing into the damn thing.' > - @nickm_tor > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbird at sgul.ac.uk Tue Jun 2 13:48:17 2020 From: dbird at sgul.ac.uk (Daniel Bird) Date: Tue, 2 Jun 2020 12:48:17 +0000 Subject: [ZendTo] SAML Auth In-Reply-To: References: <4c6bd13a-8ce3-124e-133e-a276c4091add@Zend.To> Message-ID: Many thanks Jules, I?ll test it out this evening. All the best Dan From: Jules Sent: 02 June 2020 10:18 To: ZendTo Users Cc: Daniel Bird Subject: Re: [ZendTo] SAML Auth Daniel, Ah, yes. That will be because I forgot to publish it. :-( You should find the package there now! Sorry about that, Jules. On 01/06/2020 23:51, Daniel Bird via ZendTo wrote: Evening all, I?ve just ?upgraded? to version 6 (fresh install, and moved over some configs and drop offs) from version 4 and I have it working as per our previous install, using LDAP auth. Great stuff! ? I was planning on having a go at getting SAML auth against ADFS up and running, but It appears I am stumbling at the first hurdle, and the SAML RPM packages are missing? https://zend.to/saml#packages FYI; CentOS 8. Any pointers? ----------- #> rpm --import https://zend.to/files/zendto.gpg.asc #> rpm -Uvh https://zend.to/files/zendto-repo.rpm #> yum install zendto-saml Last metadata expiration check: 0:06:37 ago on Mon 01 Jun 2020 23:25:08 BST. No match for argument: zendto-saml Error: Unable to find a match: zendto-saml # yum search zendto Last metadata expiration check: 0:06:46 ago on Mon 01 Jun 2020 23:25:08 BST. ======================================================================================= Name Exactly Matched: zendto ======================================================================================= zendto.noarch : Web-based File Transfer and Storage System zendto.noarch : Web-based File Transfer and Storage System ====================================================================================== Name & Summary Matched: zendto ====================================================================================== zendto-repo.noarch : Yum Repository Setup for ZendTo Or even #> curl -O https://zend.to/files/zendto-saml_version.rpm #> curl -O https://zend.to/files/zendto-saml_6.0-1.rpm #> file zendto-saml_6.0-1.rpm zendto-saml_6.0-1.rpm: HTML document, ASCII text #> more zendto-saml_6.0-1.rpm 404 Not Found

Not Found

The requested URL /files/zendto-saml_6.0-1.rpm was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

_______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Science is an integral part of culture. It's not this foreign thing, done by an arcane priesthood. It's one of the glories of human intellectual tradition.' - Stephen Jay Gould www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Sallee at umhb.edu Tue Jun 2 14:59:49 2020 From: Jake.Sallee at umhb.edu (Sallee, Jake) Date: Tue, 2 Jun 2020 13:59:49 +0000 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 References: Message-ID: I made a bone headed mistake and did not check to see if v6 was tested on ubuntu 20.04 LTS before I did the upgrade. Now when users visit the site they get an http 500 error and in the logs I get this: ==> /var/log/apache2/zendto_error.log <== [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 I'm continuing to look into it but any guidance you can provide would be very helpful. Jake Sallee Godfather of Bandwidth System Engineer and Security Specialist University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 From zend.to at neilzone.co.uk Tue Jun 2 15:07:53 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 2 Jun 2020 15:07:53 +0100 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> Message-ID: > On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo wrote: > > ==> /var/log/apache2/zendto_error.log <== > [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 Do you have sqlite installed for your version of php? (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Sallee at umhb.edu Tue Jun 2 15:36:21 2020 From: Jake.Sallee at umhb.edu (Sallee, Jake) Date: Tue, 2 Jun 2020 14:36:21 +0000 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> References: , <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> Message-ID: Sorry! My initial reply went to the wrong address: Neil, you're a genius! While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: => /var/log/apache2/zendto_error.log <== [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973()\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 Any ideas? I'm going to hit google as soon as I hit send on this : ) Jake Sallee Godfather of Bandwidth System Engineer and Security Specialist University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: zend.to at neilzone.co.uk Sent: Tuesday, June 2, 2020 9:07 AM To: ZendTo Users Cc: Sallee, Jake Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 EXTERNAL Exercise Caution On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: ==> /var/log/apache2/zendto_error.log <== [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 Do you have sqlite installed for your version of php? (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) Neil __________ From zend.to at neilzone.co.uk Tue Jun 2 15:45:57 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Tue, 2 Jun 2020 15:45:57 +0100 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> <7C219763-0AA2-4E80-9E88-C3FDC7357BE8@neilzone.co.uk> Message-ID: > On 2 Jun 2020, at 15:36, Sallee, Jake via ZendTo wrote: > > => /var/log/apache2/zendto_error.log <== > [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973( > )\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 > > Any ideas? I?d have thought it?s linked with the same issue as the previous error ? that you don?t have the correct php modules installed. Looking at the install script, you need the following modules: common,cli,sqlite3,mysql,readline,ldap,gd,curl,json,xml,intl,enchant,imap,mbstring,sodium I?m guessing the missing one here is php7.x-mbstring. Best wishes Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jun 2 15:50:13 2020 From: Jules at Zend.To (Jules) Date: Tue, 2 Jun 2020 15:50:13 +0100 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> Message-ID: <5c7c673a-251b-8de7-3130-54324bce498b@Zend.To> Jake, I did test it out on Ubuntu 20.04, but I started from a minimal server install and let the ZendTo Installer set everything up for me. That worked fine for me. There is a "mbstring" module for PHP, which you appear to be missing. Like the sqlite module, it will be in a package named php7.x-mbstring where "x" is usually 2, 3 or 4 depending on your version of php (php --version will tell you that). You should end up with these php packages installed (I got this list from dpkg -l | grep php libapache2-mod-php7.4 php-common php7.4 php7.4-cli php7.4-common php7.4-curl php7.4-enchant php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-ldap php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-sqlite3 php7.4-xml Installing it on a fresh Ubuntu 20.04LTS server installed PHP 7.4. Cheers, Jules. On 02/06/2020 15:36, Sallee, Jake via ZendTo wrote: > Sorry! My initial reply went to the wrong address: > > Neil, you're a genius! > > While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: > > => /var/log/apache2/zendto_error.log <== > [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973()\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 > > Any ideas? I'm going to hit google as soon as I hit send on this : ) > > > Jake Sallee > Godfather of Bandwidth > System Engineer and Security Specialist > University of Mary Hardin-Baylor > WWW.UMHB.EDU > > 900 College St. > Belton, Texas > 76513 > > Fone: 254-295-4658 > Phax: 254-295-4221 > > ________________________________________ > From: zend.to at neilzone.co.uk > Sent: Tuesday, June 2, 2020 9:07 AM > To: ZendTo Users > Cc: Sallee, Jake > Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 > > EXTERNAL Exercise Caution > > > On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: > > ==> /var/log/apache2/zendto_error.log <== > [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 > > Do you have sqlite installed for your version of php? > > (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) > > Neil > > __________ > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Is the Holocaust an aberration, or a reflection of who we really are?' - Holocaust Museum, Berlin www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Novogradac at utoronto.ca Tue Jun 2 15:55:22 2020 From: Brian.Novogradac at utoronto.ca (Brian Novogradac) Date: Tue, 2 Jun 2020 14:55:22 +0000 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: , <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> Message-ID: You are missing the mbstring php package as well -----Original Message----- From: ZendTo On Behalf Of Sallee, Jake via ZendTo Sent: Tuesday, June 2, 2020 10:36 AM To: ZendTo Users Cc: Sallee, Jake Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 EXTERNAL EMAIL: Treat content with extra caution. Sorry! My initial reply went to the wrong address: Neil, you're a genius! While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: => /var/log/apache2/zendto_error.log <== [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973( )\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 Any ideas? I'm going to hit google as soon as I hit send on this : ) Jake Sallee Godfather of Bandwidth System Engineer and Security Specialist University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: zend.to at neilzone.co.uk Sent: Tuesday, June 2, 2020 9:07 AM To: ZendTo Users Cc: Sallee, Jake Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 EXTERNAL Exercise Caution On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: ==> /var/log/apache2/zendto_error.log <== [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 Do you have sqlite installed for your version of php? (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) Neil __________ _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto From Jules at Zend.To Tue Jun 2 15:56:08 2020 From: Jules at Zend.To (Jules) Date: Tue, 2 Jun 2020 15:56:08 +0100 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: Message-ID: <253d915c-e00c-0ec9-1b57-fd4669b0eb38@Zend.To> Jake, What version of ZendTo was running on this 20.04LTS box before you upgraded? Or was it Ubuntu you upgraded? If so, what from? And don't forget to run ??? /opt/zendto/bin/upgrade as well, if you haven't already since you upgraded. Cheers, Jules. On 02/06/2020 14:59, Sallee, Jake via ZendTo wrote: > I made a bone headed mistake and did not check to see if v6 was tested on ubuntu 20.04 LTS before I did the upgrade. > > Now when users visit the site they get an http 500 error and in the logs I get this: > > ==> /var/log/apache2/zendto_error.log <== > [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 > > I'm continuing to look into it but any guidance you can provide would be very helpful. > > Jake Sallee > Godfather of Bandwidth > System Engineer and Security Specialist > University of Mary Hardin-Baylor > WWW.UMHB.EDU > > 900 College St. > Belton, Texas > 76513 > > Fone: 254-295-4658 > Phax: 254-295-4221 > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'I've heard that it's possible to grow up. I've just never met anyone who's actually done it.' - Meredith Grey, Grey's Anatomy www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbe2 at lehigh.edu Tue Jun 2 17:28:08 2020 From: kbe2 at lehigh.edu (Keith Erekson) Date: Tue, 2 Jun 2020 12:28:08 -0400 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> <5c7c673a-251b-8de7-3130-54324bce498b@Zend.To> Message-ID: Note that Ubuntu (and Debian) have metapackages for all the php packages, just called php-mbstring, php-ldap, php-sqlite3, etc. Installing these will track the relevant specific versions of the php7.3-whatever, php7.4-whatever, etc., as you upgrade Ubuntu/Debian versions. Saves a lot of headaches, and also makes documentation easier. ~Keith On 6/2/20 10:50 AM, Jules via ZendTo wrote: > Jake, > > I did test it out on Ubuntu 20.04, but I started from a minimal server > install and let the ZendTo Installer set everything up for me. That > worked fine for me. > > There is a "mbstring" module for PHP, which you appear to be missing. > Like the sqlite module, it will be in a package named > php7.x-mbstring > where "x" is usually 2, 3 or 4 depending on your version of php (php > --version will tell you that). > > You should end up with these php packages installed (I got this list > from dpkg -l | grep php > libapache2-mod-php7.4 > php-common > php7.4 > php7.4-cli > php7.4-common > php7.4-curl > php7.4-enchant > php7.4-gd > php7.4-imap > php7.4-intl > php7.4-json > php7.4-ldap > php7.4-mbstring > php7.4-mysql > php7.4-opcache > php7.4-readline > php7.4-sqlite3 > php7.4-xml > > Installing it on a fresh Ubuntu 20.04LTS server installed PHP 7.4. > > Cheers, > Jules. > > On 02/06/2020 15:36, Sallee, Jake via ZendTo wrote: >> Sorry! My initial reply went to the wrong address: >> >> Neil, you're a genius! >> >> While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: >> >> => /var/log/apache2/zendto_error.log <== >> [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973()\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 >> >> Any ideas? I'm going to hit google as soon as I hit send on this : ) >> >> >> Jake Sallee >> Godfather of Bandwidth >> System Engineer and Security Specialist >> University of Mary Hardin-Baylor >> WWW.UMHB.EDU >> >> 900 College St. >> Belton, Texas >> 76513 >> >> Fone: 254-295-4658 >> Phax: 254-295-4221 >> >> ________________________________________ >> From: zend.to at neilzone.co.uk >> Sent: Tuesday, June 2, 2020 9:07 AM >> To: ZendTo Users >> Cc: Sallee, Jake >> Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 >> >> EXTERNAL Exercise Caution >> >> >> On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: >> >> ==> /var/log/apache2/zendto_error.log <== >> [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 >> >> Do you have sqlite installed for your version of php? >> >> (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) >> >> Neil >> >> __________ >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Is the Holocaust an aberration, or a reflection of who we really are?' > - Holocaust Museum, Berlin > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jun 2 17:31:54 2020 From: Jules at Zend.To (Jules) Date: Tue, 2 Jun 2020 17:31:54 +0100 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> <5c7c673a-251b-8de7-3130-54324bce498b@Zend.To> Message-ID: <6db02bd7-b93d-0846-7027-153e805916b9@Zend.To> Keith, I knew they existed, I didn't realise they would version-track too. That's handy! *Feels a tweak to stage 2 of the Ubuntu Installer code coming on* What happens if you just install a bunch of metapackages when there isn't a PHP on the system to start with? What version does it try to install? Thanks! Jules. On 02/06/2020 17:28, Keith Erekson via ZendTo wrote: > > Note that Ubuntu (and Debian) have metapackages for all the php > packages, just called php-mbstring, php-ldap, php-sqlite3, etc. > > Installing these will track the relevant specific versions of the > php7.3-whatever, php7.4-whatever, etc., as you upgrade Ubuntu/Debian > versions. > > Saves a lot of headaches, and also makes documentation easier. > > ~Keith > > On 6/2/20 10:50 AM, Jules via ZendTo wrote: >> Jake, >> >> I did test it out on Ubuntu 20.04, but I started from a minimal >> server install and let the ZendTo Installer set everything up for me. >> That worked fine for me. >> >> There is a "mbstring" module for PHP, which you appear to be missing. >> Like the sqlite module, it will be in a package named >> php7.x-mbstring >> where "x" is usually 2, 3 or 4 depending on your version of php (php >> --version will tell you that). >> >> You should end up with these php packages installed (I got this list >> from dpkg -l | grep php >> libapache2-mod-php7.4 >> php-common >> php7.4 >> php7.4-cli >> php7.4-common >> php7.4-curl >> php7.4-enchant >> php7.4-gd >> php7.4-imap >> php7.4-intl >> php7.4-json >> php7.4-ldap >> php7.4-mbstring >> php7.4-mysql >> php7.4-opcache >> php7.4-readline >> php7.4-sqlite3 >> php7.4-xml >> >> Installing it on a fresh Ubuntu 20.04LTS server installed PHP 7.4. >> >> Cheers, >> Jules. >> >> On 02/06/2020 15:36, Sallee, Jake via ZendTo wrote: >>> Sorry! My initial reply went to the wrong address: >>> >>> Neil, you're a genius! >>> >>> While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: >>> >>> => /var/log/apache2/zendto_error.log <== >>> [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973()\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 >>> >>> Any ideas? I'm going to hit google as soon as I hit send on this : ) >>> >>> >>> Jake Sallee >>> Godfather of Bandwidth >>> System Engineer and Security Specialist >>> University of Mary Hardin-Baylor >>> WWW.UMHB.EDU >>> >>> 900 College St. >>> Belton, Texas >>> 76513 >>> >>> Fone: 254-295-4658 >>> Phax: 254-295-4221 >>> >>> ________________________________________ >>> From:zend.to at neilzone.co.uk >>> Sent: Tuesday, June 2, 2020 9:07 AM >>> To: ZendTo Users >>> Cc: Sallee, Jake >>> Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 >>> >>> EXTERNAL Exercise Caution >>> >>> >>> On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: >>> >>> ==> /var/log/apache2/zendto_error.log <== >>> [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 >>> >>> Do you have sqlite installed for your version of php? >>> >>> (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) >>> >>> Neil >>> >>> __________ >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'Is the Holocaust an aberration, or a reflection of who we really are?' >> - Holocaust Museum, Berlin >> >> www.Zend.To >> Twitter: @JulesFM >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'When a man points a finger at someone else, he should remember that four of his fingers are pointing at himself.' - Louis Nizer www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbe2 at lehigh.edu Tue Jun 2 18:30:17 2020 From: kbe2 at lehigh.edu (Keith Erekson) Date: Tue, 2 Jun 2020 13:30:17 -0400 Subject: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 In-Reply-To: References: <1497337A-0975-4480-88A5-987C5175B953@neilzone.co.uk> <70849a2a420a499a9a74d94521486659@umhb.edu> <5c7c673a-251b-8de7-3130-54324bce498b@Zend.To> <6db02bd7-b93d-0846-7027-153e805916b9@Zend.To> Message-ID: It will install whatever is in the official distro package for your Ubuntu version. You can tell which version that would be by looking at the package version number or the "provided by" lines: https://packages.ubuntu.com/search?keywords=php-sqlite3 ~Keith On 6/2/20 12:31 PM, Jules via ZendTo wrote: > Keith, > > I knew they existed, I didn't realise they would version-track too. > That's handy! > *Feels a tweak to stage 2 of the Ubuntu Installer code coming on* > > What happens if you just install a bunch of metapackages when there > isn't a PHP on the system to start with? > What version does it try to install? > > Thanks! > Jules. > > On 02/06/2020 17:28, Keith Erekson via ZendTo wrote: >> >> Note that Ubuntu (and Debian) have metapackages for all the php >> packages, just called php-mbstring, php-ldap, php-sqlite3, etc. >> >> Installing these will track the relevant specific versions of the >> php7.3-whatever, php7.4-whatever, etc., as you upgrade Ubuntu/Debian >> versions. >> >> Saves a lot of headaches, and also makes documentation easier. >> >> ~Keith >> >> On 6/2/20 10:50 AM, Jules via ZendTo wrote: >>> Jake, >>> >>> I did test it out on Ubuntu 20.04, but I started from a minimal >>> server install and let the ZendTo Installer set everything up for >>> me. That worked fine for me. >>> >>> There is a "mbstring" module for PHP, which you appear to be missing. >>> Like the sqlite module, it will be in a package named >>> php7.x-mbstring >>> where "x" is usually 2, 3 or 4 depending on your version of php (php >>> --version will tell you that). >>> >>> You should end up with these php packages installed (I got this list >>> from dpkg -l | grep php >>> libapache2-mod-php7.4 >>> php-common >>> php7.4 >>> php7.4-cli >>> php7.4-common >>> php7.4-curl >>> php7.4-enchant >>> php7.4-gd >>> php7.4-imap >>> php7.4-intl >>> php7.4-json >>> php7.4-ldap >>> php7.4-mbstring >>> php7.4-mysql >>> php7.4-opcache >>> php7.4-readline >>> php7.4-sqlite3 >>> php7.4-xml >>> >>> Installing it on a fresh Ubuntu 20.04LTS server installed PHP 7.4. >>> >>> Cheers, >>> Jules. >>> >>> On 02/06/2020 15:36, Sallee, Jake via ZendTo wrote: >>>> Sorry! My initial reply went to the wrong address: >>>> >>>> Neil, you're a genius! >>>> >>>> While that didn't completely fix the issue it did get rid of the HTTP 500 error, now in the log I get this: >>>> >>>> => /var/log/apache2/zendto_error.log <== >>>> [Tue Jun 02 09:27:40.094119 2020] [php7:error] [pid 31158] [client 10.11.0.54:48300] PHP Fatal error: Uncaught Error: Call to undefined function mb_convert_encoding() in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php:350\nStack trace:\n#0 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed5319145bc90_56686873()\n#1 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#2 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(216): Smarty_Template_Compiled->render()\n#3 /opt/zendto/lib/smarty/sysplugins/smarty_internal_template.php(385): Smarty_Internal_Template->render()\n#4 /var/zendto/templates_c/6589cea3d6fc662e66e11280f00e023cec6383d2_0.file.main_menu.tpl.php(28): Smarty_Internal_Template->_subTemplateRender()\n#5 /opt/zendto/lib/smarty/sysplugins/smarty_template_resource_base.php(123): content_5ed531913fcdb0_07262973()\n#6 /opt/zendto/lib/smarty/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()\n#7 /opt/zendt in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.php on line 350 >>>> >>>> Any ideas? I'm going to hit google as soon as I hit send on this : ) >>>> >>>> >>>> Jake Sallee >>>> Godfather of Bandwidth >>>> System Engineer and Security Specialist >>>> University of Mary Hardin-Baylor >>>> WWW.UMHB.EDU >>>> >>>> 900 College St. >>>> Belton, Texas >>>> 76513 >>>> >>>> Fone: 254-295-4658 >>>> Phax: 254-295-4221 >>>> >>>> ________________________________________ >>>> From: zend.to at neilzone.co.uk >>>> Sent: Tuesday, June 2, 2020 9:07 AM >>>> To: ZendTo Users >>>> Cc: Sallee, Jake >>>> Subject: Re: [ZendTo] Error after upgrade to v6 AND ubuntu 20.04 >>>> >>>> EXTERNAL Exercise Caution >>>> >>>> >>>> On 2 Jun 2020, at 14:59, Sallee, Jake via ZendTo > wrote: >>>> >>>> ==> /var/log/apache2/zendto_error.log <== >>>> [Tue Jun 02 08:11:16.382445 2020] [php7:error] [pid 14685] [client 123.123.123.123:46880] PHP Fatal error: Cannot declare class Sql, because the name is already in use in /opt/zendto/lib/SQLite3.php on line 29 >>>> >>>> Do you have sqlite installed for your version of php? >>>> >>>> (If not, perhaps apt-get install php7.x-sqlite will fix it, replacing x with your php7 sub-version.) >>>> >>>> Neil >>>> >>>> __________ >>>> >>>> >>>> _______________________________________________ >>>> ZendTo mailing list >>>> ZendTo at zend.to >>>> http://jul.es/mailman/listinfo/zendto >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> 'Is the Holocaust an aberration, or a reflection of who we really are?' >>> - Holocaust Museum, Berlin >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'When a man points a finger at someone else, he should remember > that four of his fingers are pointing at himself.' - Louis Nizer > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Wed Jun 3 13:10:26 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 3 Jun 2020 13:10:26 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> Message-ID: I upgraded to the latest version, running on Debian 10, and tried to transfer a file. It hung before the checksumming screen appeared. tail -f zendto.log Error: Opening temp file /nbqahgNJZaUn975PiRvsystWjzES5ket.1 for appending failed tail -f /var/log/apache2/ssl_error.log Got error 'PHP message: PHP Warning: fopen(/sbkqXGFPxfHT3xhb7BGxiwu8HoDRoyZc.1): failed to open stream: Permission denied in /opt/zendto/www/savechunk.php on line 117\n' In preferences.php, I changed: // To completely disable sending files in chunks, set this to 0. 'uploadChunkSize' => 0, // 50 MB as an example From 50000 to 0, to disable sending in chunks, and restarted the webserver. It then worked. I cannot say, sadly, whether it was the config change or the restart of the webserver which did it. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 14:25:30 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 14:25:30 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> Message-ID: Neil, This means that ini_get('upload_tmp_dir') returned an empty string (or NULL). Please can you run this command ??? php -i | grep upload_tmp_dir The upload_tmp_dir setting should resolve to /var/zendto/incoming. If it doesn't, we need to find why. The relevant php.ini file should be in ??? /etc/php/7./x//apache2/php.ini If you have moved to a new version of PHP at the same time, it's quite possible that the correct php.ini hasn't had any of ZendTo's changes applied to it. When you find one that has been modified for ZendTo, there should be a php.ini.zendto in the same directory. php.ini.zendto is what was there before ZendTo touched it, so a quick diff will show you the differences you need. Alternatively, running stage 5 of the ZendTo Installer on its own will re-apply the php.ini settings. Cheers, Jules. On 03/06/2020 13:10, Neil via ZendTo wrote: > I upgraded to the latest version, running on Debian 10, and tried to > transfer a file. > > It hung before the checksumming screen appeared. > > tail -f zendto.log > Error: Opening temp file /nbqahgNJZaUn975PiRvsystWjzES5ket.1 for > appending failed > > > tail -f /var/log/apache2/ssl_error.log > ?Got error 'PHP message: PHP Warning: > ?fopen(/sbkqXGFPxfHT3xhb7BGxiwu8HoDRoyZc.1): failed to open stream: > Permission denied in /opt/zendto/www/savechunk.php on line 117\n' > > ?In preferences.php, I changed: > > ?// To completely disable sending files in chunks, set this to 0. > 'uploadChunkSize' => 0, // 50 MB as an example > > From 50000 to 0, to disable sending in chunks, and restarted the > webserver. > > It then worked. > > I cannot say, sadly, whether it was the config change or the restart > of the webserver which did it. > > > Neil > > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'We are such stuff as dreams are made on. And our little life is rounded with a sleep.' - Starfleet Admiral Jean-Luc Picard (retired) www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Wed Jun 3 15:36:32 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 3 Jun 2020 15:36:32 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> Message-ID: > On 3 Jun 2020, at 14:25, Jules wrote: Thanks Jules > > Please can you run this command > php -i | grep upload_tmp_dir > The upload_tmp_dir setting should resolve to /var/zendto/incoming. I get this: upload_tmp_dir => /var/zendto/incoming => /var/zendto/incoming Perhaps that?s a double reference? Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 15:44:44 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 15:44:44 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> Message-ID: That's exactly what mine says. Check the php.ini under /etc/php7.*/apache2/php.ini. I just realised that running "php -i" from the command-line will show you the cli settings, not the apache2 settings. My bad. On 03/06/2020 15:36, zend.to at neilzone.co.uk wrote: > > >> On 3 Jun 2020, at 14:25, Jules > >> wrote: > > Thanks Jules >> >> Please can you run this command >> ??? php -i | grep upload_tmp_dir >> Theupload_tmp_dirsetting should resolve to/var/zendto/incoming. > > I get this: > > upload_tmp_dir => /var/zendto/incoming => /var/zendto/incoming > > Perhaps that?s a double reference? > > Neil > > __________ > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Adversity is like a strong wind. I don't mean just that it holds us back from places we might otherwise go. It also tears away from us all but the things that cannot be torn, so that afterward we see ourselves as we really are, and not merely as we might like to be.' - Arthur Golden www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 15:47:30 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 15:47:30 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> Message-ID: <30063c90-240f-2b87-c000-7e48cf67acbe@Zend.To> And I have just added a bit of extra error checking and logging (for this symptom0 to www/savechunk.php. It will be in the next release, but feel free to try the attached. Cheers, Jules. On 03/06/2020 15:36, zend.to at neilzone.co.uk wrote: > > >> On 3 Jun 2020, at 14:25, Jules > >> wrote: > > Thanks Jules >> >> Please can you run this command >> ??? php -i | grep upload_tmp_dir >> Theupload_tmp_dirsetting should resolve to/var/zendto/incoming. > > I get this: > > upload_tmp_dir => /var/zendto/incoming => /var/zendto/incoming > > Perhaps that?s a double reference? > > Neil > > __________ > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Adversity is like a strong wind. I don't mean just that it holds us back from places we might otherwise go. It also tears away from us all but the things that cannot be torn, so that afterward we see ourselves as we really are, and not merely as we might like to be.' - Arthur Golden www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: savechunk.php.zip Type: application/zip Size: 2596 bytes Desc: not available URL: From zend.to at neilzone.co.uk Wed Jun 3 15:54:40 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 3 Jun 2020 15:54:40 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> Message-ID: > On 3 Jun 2020, at 15:44, Jules wrote: > > Check the php.ini under /etc/php7.*/apache2/php.ini. It looks correct: upload_tmp_dir = /var/zendto/incoming (I also have a php.ini.zendto in that directory.) Neil __________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 15:58:28 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 15:58:28 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> Message-ID: That's odd. In your /opt/zendto/www directory, create a file called i.php and put this in it (barring the SNIP lines) -- SNIP -- -- SNIP -- Then browse to /i.php on your ZendTo site. That should dump all the PHP configuration that Apache gets. Search that page for upload_tmp_dir and see what it says. (When you're done, clear up as you don't want to leave i.php publishing all the config setup of your web server to the world). On 03/06/2020 15:54, zend.to at neilzone.co.uk wrote: > > >> On 3 Jun 2020, at 15:44, Jules > >> wrote: >> >> Check the php.ini under /etc/php7.*/apache2/php.ini. > > It looks correct: > > upload_tmp_dir = /var/zendto/incoming > > (I also have a php.ini.zendto in that directory.) > > Neil > > __________ > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'That is the land of lost content, I see it shining plain, The happy highways where I went, And cannot come again.' - A.E. Houseman www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Wed Jun 3 16:26:11 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 3 Jun 2020 16:26:11 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> Message-ID: > On 3 Jun 2020, at 15:58, Jules wrote: > > Search that page for upload_tmp_dir and see what it says. ?no value? *However*, I wonder if the error is that the loaded config file is not: /etc/php/7.2/apache2/php.ini but: /etc/php/7.2/fpm/php.ini which does not have the ;upload_tmp_dir setting (it?s commented out). Best wishes Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 16:31:48 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 16:31:48 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> Message-ID: Well done, that will be it. I need to make the Installer spot fpm correctly, which it isn't at the moment. If you apply the same to the fpm version that were applied to the apache2 version ("diff php.ini.zendto php.ini" to find them), that should fix it. But as you're using fpm, then ??? systemctl restart apache2 won't help, you will need to ??? systemctl restart fpm to restart the PHP engine in Apache. Cheers, Jules. On 03/06/2020 16:26, zend.to at neilzone.co.uk wrote: > > >> On 3 Jun 2020, at 15:58, Jules > >> wrote: >> >> Search that page for upload_tmp_dir and see what it says. > > ?no value? > > *However*, I wonder if the error is that the loaded config file is not: > > /etc/php/7.2/apache2/php.ini > > but: > > /etc/php/7.2/fpm/php.ini > > which does not have the ;upload_tmp_dir setting (it?s commented out). > > Best wishes > > Neil > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM How to stop time: kiss. How to travel in time: read. How to escape time: music. How to feel time: write. How to release time: breathe. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 16:37:41 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 16:37:41 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> Message-ID: Neil, How did you end up with fpm installed? When I ran the Installer on a minimal Debian 10 box, I didn't get fpm installed. I get PHP 7.3 not 7.2, as well. But I'll add fpm to the list of dirs to search as well. Cheers, Jules. On 03/06/2020 16:26, zend.to at neilzone.co.uk wrote: > > >> On 3 Jun 2020, at 15:58, Jules > >> wrote: >> >> Search that page for upload_tmp_dir and see what it says. > > ?no value? > > *However*, I wonder if the error is that the loaded config file is not: > > /etc/php/7.2/apache2/php.ini > > but: > > /etc/php/7.2/fpm/php.ini > > which does not have the ;upload_tmp_dir setting (it?s commented out). > > Best wishes > > Neil > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Gaze not into the abyss, lest you become recognised as an abyss domain expert, and they expect you to keep gazing into the damn thing.' - @nickm_tor www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From TZimmerman at fsu.edu Wed Jun 3 17:56:45 2020 From: TZimmerman at fsu.edu (Travis Zimmerman) Date: Wed, 3 Jun 2020 16:56:45 +0000 Subject: [ZendTo] Missing login In-Reply-To: References: <8ABA4C20-7E5C-493C-A4B0-9731B50FF07B@fsu.edu> <3e6a13b7-48d1-caf9-6bd2-5e5913eb75ea@Zend.To> <5C8B099B-E163-4234-9FD9-1F4BC419F830@fsu.edu> <7338f2fb-0380-81c1-afaf-b4f20a1fe5dd@Zend.To> <3219A559-FACF-4572-BC7C-9FEA05E2D423@fsu.edu> Message-ID: I?ve gotten nearly all of our changes into zendto.po for en_US but one of our tweaks was some added HTML formatting to email_dropoff_html.tpl file, I?ve added it into the appropriate msgstr line but the email I get has the code listed literally instead of rendering the HTML tags. I see that you use it HTML tags in other language zendto.po files. Looking at the email source all the < and > are being turned into > or < as appropriate. Thanks for adding those ids to body, headers, and footers that will help us greatly. I?ve nudged my managers but have see what we can get since CoVid-19 is reducing our budget. ------------------------------------------------------ Travis Zimmerman tzimmerman at fsu.edu 850-645-8030 Linux Enterprise Applications & Systems its-linuxadmins at fsu.edu Information Technology Services, Florida State University On May 22, 2020, at 4:53 AM, Jules > wrote: Travis, On 21/05/2020 20:37, Travis Zimmerman wrote: That was it. Our web dev team had to touch a few of the template files to apply our university?s color scheme and we changed username to email in a couple places ( our students are on a different domain than the staff, so we use email for auth ). You should change any text in the /opt/zendto/config/locale/en_US/LC_MESSAGES/zendto.po file. After changing this file, run /opt/zendto/bin/makelanguages and then restart Apache. This is all explained on https://zend.to/translators.php Then your customisations will survive upgrades and will not affect and upgrades to the template files. It may seem strange to be reading docs about translating it to another language. But effectively you are just customising the "en_US" translation. In that zendto.po file (it's just plain text), there are lots of "msgid" strings. This is the text that is in the template file for that phrase. Each one has a corresponding "msgstr" string, which contains the text that ZendTo actually serves up for that phrase. If the msgstr is empty (msgstr "") then it defaults back to serving up the msgid string. So, when translating to a new language (e.g. Welsh), the msgid would be the English version that is in the template file. The msgstr version would be the Welsh equivalent. But in your case the msgstr version is just the modified (English) text you want to display. Does that explain it? If you're not sure, send me an example and I will show you exactly what the relevant zendto.po entries look like. We use the local.css file to make any changes to the css code. Here?s what we touched, don?t know if this could be added ( or some similar way ) for helping with branding or did our web dev team miss something? Added an id to the body tag. header.tpl Done. Added an id to this td and removed the background color from its style. email_footer_html.tpl > wrote: Travis, My guess would be that you have modified a file or 2 in /opt/zendto/templates. If you did that, then the new versions will have ".rpmnew" (on CentOS/RedHat-based systems) or similar stuck on the end of their filename. You need to move the new ones into place, overwriting your modified ones. The same could be true of your /opt/zendto/www/css/swish2.css file. Also, make sure you have run /opt/zendto/bin/upgrade Hopefully 1 or more of those will be the cause! Cheers, Jules. On 21/05/2020 15:09, Travis Zimmerman via ZendTo wrote: We upgraded our ZendTo dev server to 5.23-4, initially I?m pretty sure everything was fine. But today when I looked at it there is no login on either the Home page or the Login page. I tried deleting the tpl.php files in templates_c but that didn?t fix it. Did I miss something in the Changelog or a new setting in the preferences.php? ------------------------------------------------------ Travis Zimmerman tzimmerman at fsu.edu 850-645-8030 Linux Enterprise Applications & Systems its-linuxadmins at fsu.edu Information Technology Services, Florida State University _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'I have lost friends, some by death ... others through sheer inability to cross the street.' - Virginia Woolf www.Zend.To Twitter: @JulesFM Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Faeroes: East 4 to 6 becoming cyclonic 5 to 7. Slight or moderate becoming moderate or rough, then very rough or high later. Fog banks then rain. Moderate, occasionally very poor at first. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Wed Jun 3 18:42:31 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Wed, 3 Jun 2020 18:42:31 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> <64ecd2bf-dd59-bc08-beb2-a00d2e7c3d59@Zend.To> <448CC91B-118D-430C-B2AC-FC524E50D151@neilzone.co.uk> Message-ID: > On 3 Jun 2020, at 16:46, Jules wrote: > > But more importantly, does it now work properly? Not yet, but I haven?t tried the fix you suggested ("If you apply the same to the fpm version that were applied to the apache2 version ("diff php.ini.zendto php.ini" to find them), that should fix it.?) yet. Hopefully this evening. Thanks, as always, for your help. Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpurcell at westga.edu Wed Jun 3 18:47:27 2020 From: mpurcell at westga.edu (Matt Purcell) Date: Wed, 3 Jun 2020 13:47:27 -0400 Subject: [ZendTo] LDAPS auth error help References: Message-ID: Hi, When trying to log in via LDAPS, the web interface gives 3 separate errors: -LDAP Error Connected to but could not start_tls, it said -LDAP Error Check User: Unable to connect to any of the authentication servers; could not authenticate user. Please notify the system administrator. -Authentication Error The username or password was incorrect. /var/log/httpd/zendto_error_log shows error: [php7:warn] [pid 1302] [client 160.10.211.97:57522] PHP Warning: ldap_start_tls(): Unable to start TLS: Can't contact LDAP server in /opt/zendto/lib/NSSADAuthenticator.php on line 583 Does this indicate an deficiency in AD config? Where should I begin troubleshooting? We've confirmed that a bind request did reach the LDAPS server. Thanks in advance for any help you might offer! -- *Matthew Purcell* *Systems Administrator * Information Technology Services *University of West Georgia * 1601 Maple Street, Carrollton, GA 30118 p: 678-839-5505 mpurcell at westga.edu westga.edu/its [image: University of West Georgia] This e-mail is intended solely for the addressee and may contain confidential information. If you are not the addressee please do not save, print, or retransmit, except to return to the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 19:34:32 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 19:34:32 +0100 Subject: [ZendTo] Missing login In-Reply-To: References: <8ABA4C20-7E5C-493C-A4B0-9731B50FF07B@fsu.edu> <3e6a13b7-48d1-caf9-6bd2-5e5913eb75ea@Zend.To> <5C8B099B-E163-4234-9FD9-1F4BC419F830@fsu.edu> <7338f2fb-0380-81c1-afaf-b4f20a1fe5dd@Zend.To> <3219A559-FACF-4572-BC7C-9FEA05E2D423@fsu.edu> Message-ID: <08e60c99-0402-a782-f124-4096b588175a@Zend.To> Travis, On 03/06/2020 17:56, Travis Zimmerman wrote: > I?ve gotten nearly all of our changes into zendto.po for en_US You should just be able to drop your zendto.po into /opt/zendto/config/locale/en_US/LC_MESSAGES and then run /opt/zendto/bin/makelanguages. It will fill everything else with the supplied defaults for you. /opt/zendto/config/locale/en_US/LC_MESSAGES/zendto.po wins over /opt/zendto/config/locale/supplied/en_US.zendto.po which wins over /opt/zendto/config/locale/zendto.pot when you run /opt/zendto/bin/makelanguages. > but one of our tweaks was some added HTML formatting to > email_dropoff_html.tpl file, I?ve added it into the appropriate msgstr > line but the email I get has the code listed literally instead of > rendering the HTML tags. > I see that you use it HTML tags in other language zendto.po files. > Looking at the email source all the < and > are being turned into > > or < as appropriate. All the languages work the same way. But only some of the text substitutions are done allowing HTML tags. Not most of them. Check what is really in a working zendto.po versus a non-working one. They are just text files. By default the {t} you see in *.tpl files escapes things like < and >. If I've put the "noescape" attribute in there, then you can put HTML tags in the msgstr line. > > Thanks for adding those ids to body, headers, and footers that will > help us greatly. Good. > > I?ve nudged my managers but have see what we can get since CoVid-19 is > reducing our budget. Thanks! Jules. > > ------------------------------------------------------ > Travis Zimmermantzimmerman at fsu.edu 850-645-8030 > Linux Enterprise Applications & Systemsits-linuxadmins at fsu.edu > > Information Technology Services, Florida State University > >> On May 22, 2020, at 4:53 AM, Jules > > wrote: >> >> Travis, >> >> On 21/05/2020 20:37, Travis Zimmerman wrote: >>> That was it. Our web dev team had to touch a few of the template >>> files to apply our university?s color scheme and we changed username >>> to email in a couple places ( our students are on a different domain >>> than the staff, so we use email for auth ). >> You should change any text in the >> /opt/zendto/config/locale/en_US/LC_MESSAGES/zendto.po file. >> After changing this file, run /opt/zendto/bin/makelanguages and then >> restart Apache. >> This is all explained on >> https://zend.to/translators.php >> >> Then your customisations will survive upgrades and will not affect >> and upgrades to the template files. >> >> It may seem strange to be reading docs about translating it to >> another language. But effectively you are just customising the >> "en_US" translation. >> >> In that zendto.po file (it's just plain text), there are lots of >> "msgid" strings. This is the text that is in the template file for >> that phrase. Each one has a corresponding "msgstr" string, which >> contains the text that ZendTo actually serves up for that phrase. If >> the msgstr is empty (msgstr "") then it defaults back to serving up >> the msgid string. >> >> So, when translating to a new language (e.g. Welsh), the msgid would >> be the English version that is in the template file. The msgstr >> version would be the Welsh equivalent. But in your case the msgstr >> version is just the modified (English) text you want to display. >> >> Does that explain it? >> If you're not sure, send me an example and I will show you exactly >> what the relevant zendto.po entries look like. >> >>> We use the local.css file to make any changes to the css code. >>> >>> Here?s what we touched, don?t know if this could be added ( or some >>> similar way ) for helping with branding or did our web dev team miss >>> something? >>> Added an id to the body tag. >>> header.tpl >>> >> Done. >>> >>> Added an id to this td and removed the background color from its style. >>> email_footer_html.tpl >>> > I've called it "email-footer". I've also named the corresponding >> header "email-header". >> >> There is now a bit of CSS in the email_header.tpl that sets the >> background-color for #email-header and #email-footer. The "local.css" >> is inserted just after this, so overrides it. >> >> That should fix it all for you. >> >>> As always, thanks for the help and making this product. >>> >> Many thanks for that! >> >> P.S. Please do feel free to ask your employer to either make a >> donation, or else to pay an invoice for development work or similar. >> >> Cheers, >> Jules. >> >> >>>> On May 21, 2020, at 10:58 AM, Jules >>> > wrote: >>>> >>>> Travis, >>>> >>>> My guess would be that you have modified a file or 2 in >>>> /opt/zendto/templates. >>>> If you did that, then the new versions will have ".rpmnew" (on >>>> CentOS/RedHat-based systems) or similar stuck on the end of their >>>> filename. You need to move the new ones into place, overwriting >>>> your modified ones. >>>> >>>> The same could be true of your /opt/zendto/www/css/swish2.css file. >>>> >>>> Also, make sure you have run >>>> ??? /opt/zendto/bin/upgrade >>>> >>>> Hopefully 1 or more of those will be the cause! >>>> >>>> Cheers, >>>> Jules. >>>> >>>> On 21/05/2020 15:09, Travis Zimmerman via ZendTo wrote: >>>>> We upgraded our ZendTo dev server to 5.23-4, initially I?m pretty >>>>> sure everything was fine. But today when I looked at it there is >>>>> no login on either the Home page or the Login page. >>>>> >>>>> I tried deleting the tpl.php files in templates_c but that didn?t >>>>> fix it. Did I miss something in the Changelog or a new setting in >>>>> the preferences.php? >>>>> >>>>> ------------------------------------------------------ >>>>> Travis Zimmermantzimmerman at fsu.edu >>>>> 850-645-8030 >>>>> Linux Enterprise Applications & Systemsits-linuxadmins at fsu.edu >>>>> >>>>> Information Technology Services, Florida State University >>>>> >>>>> >>>>> _______________________________________________ >>>>> ZendTo mailing list >>>>> ZendTo at zend.to >>>>> http://jul.es/mailman/listinfo/zendto >>>> >>>> Jules >>>> >>>> -- >>>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>>> >>>> 'I have lost friends, some by death ... others through sheer inability >>>> to cross the street.' - Virginia Woolf >>>> >>>> www.Zend.To >>>> Twitter: @JulesFM >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> The current UK shipping forecast: >> Faeroes: East 4 to 6 becoming cyclonic 5 to 7. Slight or moderate becoming >> moderate or rough, then very rough or high later. Fog banks then rain. >> Moderate, occasionally very poor at first. >> >> www.Zend.To >> Twitter: @JulesFM > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'The owls are not what they appear.' - David Lynch (indirectly) www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 3 19:37:37 2020 From: Jules at Zend.To (Jules) Date: Wed, 3 Jun 2020 19:37:37 +0100 Subject: [ZendTo] LDAPS auth error help In-Reply-To: References: Message-ID: <9b57b5b9-8c80-66c5-0da3-08ec3f54650a@Zend.To> Okay, so make sure for starters that the authenticator is set to 'AD' and not 'LDAP'. There are then some good troubleshooting tips on ??? zend.to/activedirectory You need to try to connect with "ldapsearch" and "openssl"s ssl client. Read the page above and it should point you in the right direction. Cheers, Jules. On 03/06/2020 18:47, Matt Purcell via ZendTo wrote: > Hi, When trying to log in via LDAPS, the web interface gives 3 > separate errors: > -LDAP Error > Connected to but could not start_tls, it said > -LDAP Error > Check User: Unable to connect to any of the authentication servers; > could not authenticate user. Please notify the system administrator. > -Authentication Error > The username or password was incorrect. > > /var/log/httpd/zendto_error_log shows error: > ?[php7:warn] [pid 1302] [client 160.10.211.97:57522 > ] PHP Warning: ?ldap_start_tls(): Unable > to start TLS: Can't contact LDAP server in > /opt/zendto/lib/NSSADAuthenticator.php on line 583 > > Does this indicate an deficiency?in AD config? Where should I begin > troubleshooting? We've confirmed that a bind request did reach the > LDAPS server. > > Thanks in advance for any help you might offer! > > -- > > *Matthew Purcell* > > /Systems Administrator / > Information Technology Services > * > * > *University of West Georgia * > 1601 Maple Street, Carrollton, GA ?30118 > p: 678-839-5505 > mpurcell at westga.edu > westga.edu/its > University of West Georgia > This e-mail is intended solely for the addressee and may contain > confidential information. If you are not the addressee please do not > save, print, or retransmit, except to return to the sender. > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Thu Jun 4 08:40:38 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Thu, 4 Jun 2020 08:40:38 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> Message-ID: In case it helps others, I did: cd /etc/php/7.2/fpm cp php.ini php.ini.bak diff -u php.ini ../apache2/php.ini.zendto > zendto.patch patch -u php.ini -i zendto.patch service php7.2-fpm restart The expected variables are now shown through phpinfo(). I then adjusted the chunk size in /opt/zendto/config/preferences.php back to 50000, and it seems to be working. Thanks for your help, Jules. Best wishes Neil > On 3 Jun 2020, at 16:31, Jules wrote: > > Well done, that will be it. > I need to make the Installer spot fpm correctly, which it isn't at the moment. > If you apply the same to the fpm version that were applied to the apache2 version ("diff php.ini.zendto php.ini" to find them), that should fix it. > > But as you're using fpm, then > systemctl restart apache2 > won't help, you will need to > systemctl restart fpm > to restart the PHP engine in Apache. > > Cheers, > Jules. > > On 03/06/2020 16:26, zend.to at neilzone.co.uk wrote: >> >> >>> On 3 Jun 2020, at 15:58, Jules > wrote: >>> >>> Search that page for upload_tmp_dir and see what it says. >> >> ?no value? >> >> *However*, I wonder if the error is that the loaded config file is not: >> >> /etc/php/7.2/apache2/php.ini >> >> but: >> >> /etc/php/7.2/fpm/php.ini >> >> which does not have the ;upload_tmp_dir setting (it?s commented out). >> >> Best wishes >> >> Neil >> >> >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > How to stop time: kiss. > How to travel in time: read. > How to escape time: music. > How to feel time: write. > How to release time: breathe. > > www.Zend.To > Twitter: @JulesFM Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Jun 4 09:18:26 2020 From: Jules at Zend.To (Jules) Date: Thu, 4 Jun 2020 09:18:26 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> Message-ID: Neil, Thanks for that. 50,000 bytes seems a *very* small chunk size to me. There is an overhead on the "cost" of each chunk compared to doing the entire file at once, and I can't imagine there are appliances/services out there that have a request size limit as small as that. My 50,000,000 bytes is based on its ability to get through the Great Firewall of China, but I might tweak that a bit yet. Any thoughts? Cheers, Jules. On 04/06/2020 08:40, zend.to at neilzone.co.uk wrote: > In case it helps others, I did: > > cd /etc/php/7.2/fpm > cp php.ini php.ini.bak > diff -u php.ini ../apache2/php.ini.zendto > zendto.patch > patch -u php.ini -i zendto.patch > service php7.2-fpm restart > > > The expected variables are now shown through phpinfo(). > > > I then adjusted the chunk size in /opt/zendto/config/preferences.php > back to 50000, and it seems to be working. > > > Thanks for your help, Jules. > > Best wishes > > Neil > >> On 3 Jun 2020, at 16:31, Jules > >> wrote: >> >> Well done, that will be it. >> I need to make the Installer spot fpm correctly, which it isn't at >> the moment. >> If you apply the same to the fpm version that were applied to the >> apache2 version ("diff php.ini.zendto php.ini" to find them), that >> should fix it. >> >> But as you're using fpm, then >> ??? systemctl restart apache2 >> won't help, you will need to >> ??? systemctl restart fpm >> to restart the PHP engine in Apache. >> >> Cheers, >> Jules. >> >> On 03/06/2020 16:26, zend.to at neilzone.co.uk wrote: >>> >>> >>>> On 3 Jun 2020, at 15:58, Jules >>> > wrote: >>>> >>>> Search that page for upload_tmp_dir and see what it says. >>> >>> ?no value? >>> >>> *However*, I wonder if the error is that the loaded config file is not: >>> >>> /etc/php/7.2/apache2/php.ini >>> >>> but: >>> >>> /etc/php/7.2/fpm/php.ini >>> >>> which does not have the ;upload_tmp_dir setting (it?s commented out). >>> >>> Best wishes >>> >>> Neil >>> >>> >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> How to stop time: kiss. >> How to travel in time: read. >> How to escape time: music. >> How to feel time: write. >> How to release time: breathe. >> >> www.Zend.To >> Twitter: @JulesFM > > > Neil > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All the art of living lies in a fine mingling of letting go, and holding on.' - Henry Ellis www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From zend.to at neilzone.co.uk Thu Jun 4 10:05:22 2020 From: zend.to at neilzone.co.uk (zend.to at neilzone.co.uk) Date: Thu, 4 Jun 2020 10:05:22 +0100 Subject: [ZendTo] Chunk error after upgrading to v6 In-Reply-To: References: <26C060A2-E186-4743-A901-5C06B0D258B0@neilzone.co.uk> <02174402-3A5F-47F6-BC48-04323394E86C@neilzone.co.uk> <7622C94E-593A-4207-B42B-707FEE7E3822@neilzone.co.uk> <35F0002B-541E-43C4-A09D-AFF564D6C4FD@neilzone.co.uk> Message-ID: > On 4 Jun 2020, at 09:18, Jules wrote: > > My 50,000,000 bytes is based on its ability to get through the Great Firewall of China, but I might tweak that a bit yet. > > Any thoughts? Yes. I got it wrong, and was aiming for the same setting as before! Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Jun 4 12:17:00 2020 From: Jules at Zend.To (Jules) Date: Thu, 4 Jun 2020 12:17:00 +0100 Subject: [ZendTo] ZendTo 6.0-2 released (bug-fixes) Message-ID: <13a15ec2-eefc-ba1b-6b6a-5378d351f4c3@Zend.To> Hi folks! A couple of the more intrepid ones amongst you have reported a few little bugs in ZendTo 6.0-1. So these are now fixed, and I have just released 6.0-2. So please do 'sudo apt update; sudo apt upgrade' or 'yum upgrade' to fetch the new release. Here are the only changes: - Updated Italian translation. Thanks Massimo! - Improved php.ini error checking and reporting. - Improved Installer to update php.ini for fpm as well as apache2 on ? Ubuntu/Debian based systems. - Fixed quoting issues with French translation. - Fixed bug where "days until drop-off expires" box was still visible ? despite setting preferences.php so it should not show. - Fixed template bug where login hint text on main menu was being ? over-escaped. Thanks for the bug reports! Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Do not go gentle into that good night, Old age should burn and rave at close of day; Rage, rage against the dying of the light. Though wise men at their end know dark is right, Because their words had forked no lightning they Do not go gentle into that good night. Good men, the last wave by, crying how bright Their frail deeds might have danced in a green bay, Rage, rage against the dying of the light. Wild men who caught and sang the sun in flight, And learn, too late, they grieved it on its way, Do not go gentle into that good night. Grave men, near death, who see with blinding sight Blind eyes could blaze like meteors and be gay, Rage, rage against the dying of the light. And you, my father, there on the sad height, Curse, bless, me now with your fierce tears, I pray. Do not go gentle into that good night. Rage, rage against the dying of the light.' - Dylan Thomas www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Jun 5 16:26:34 2020 From: Jules at Zend.To (Jules) Date: Fri, 5 Jun 2020 16:26:34 +0100 Subject: [ZendTo] ZendTo 6.01-1 released Message-ID: <8e737cc9-560d-83f2-8086-ecef092d3315@Zend.To> Hi folks! 2 new things in this: 1. The global list of drop-offs now has toggles for showing/hiding the columns available, and I have added the recipients and expiry date of each drop-off to data you can choose to show. 2. The "autolist" command should now be able to handle much bigger dumps of data about your drop-offs. If you like the toggles for showing/hiding the columns in the Global Drop-offs list, do let me know and I can add the same feature to the user's own "Inbox" and "Outbox" as well. Any problems, questions of suggestions, do let me know! Cheers, Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Making machines do what you want requires only two qualities: 1) Being slightly more stubborn that the computer, & 2) Remembering that computers are electrified rocks.' - @JediJeremy www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Fri Jun 5 19:53:22 2020 From: john.thurston at alaska.gov (John Thurston) Date: Fri, 5 Jun 2020 10:53:22 -0800 Subject: [ZendTo] Quietly not encrypting in V6 References: Message-ID: I'm looking at moving from V5 to V6. During testing, we turned up interesting behavior. While creating a drop-off, the authenticated customer was prompted for a passphrase. This was entered and accepted. Checksum was also requested. When the upload was complete, the 'Outbox' showed the files with an "X" in the encrypted column. When later performing the pickup, no passphrase was requested. When I later looked in the logs, I found: > Error: Should be encrypting files but failed to read the passphrase, so not encrypting. If this drop-off came from a request, the encoded passphrase in the request got corrupted! which I traced to line 2531 of NSSDropoff.php which is preceded with the comment block > // If we got the encryption passphrase from a request, but failed to > // be able to read it, the user won't have been prompted to enter one. > // So we have no way of finding it! So if that failed, don't encrypt > // at all. But this drop/pickup didn't originate with a 'request'. It was done by an interactive, authenticated user. The user requested encryption, supplied the phrase, and the application seems to have quietly failed to encrypt an otherwise acceptable (not too large) file. I'm unable to reproduce this failure. If the customer asks to encrypt an over-sized file, it is plainly refused. If encryption has been requested and can't be done for some other reason, shouldn't that be a blocking-situation? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska From Jules at Zend.To Sat Jun 6 11:15:42 2020 From: Jules at Zend.To (Jules) Date: Sat, 6 Jun 2020 11:15:42 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: <48b54b1b-9c6c-feda-037b-f8e87c9e9c2c@Zend.To> John, Start by checking that the upgrade has installed all the new /opt/zendto/templates files. That's often the source of weird problems. What exact database back-end are you using? As root, run /opt/zendto/sbin/cleanup.php /opt/zendto/config/preferences.php --no-warnings and check it doesn't produce any errors. Also, there should have been some quiet database schema upgrades in the background. Check that the schema of the "dropoff" table ('SHOW CREATE TABLE dropoff') contains a "lifeseconds" column. I've just tried creating an encrypted drop-off and I can't reproduce the fault. I made a little drop-off and encrypted it. It correctly demanded the right passphrase before I could download anything from it. But I will have a good dig through the code to see how this could possibly be happening. Cheers, Jules. On 05/06/2020 19:53, John Thurston via ZendTo wrote: > I'm looking at moving from V5 to V6. During testing, we turned up > interesting behavior. > > While creating a drop-off, the authenticated customer was prompted for > a passphrase. This was entered and accepted. Checksum was also requested. > > When the upload was complete, the 'Outbox' showed the files with an > "X" in the encrypted column. When later performing the pickup, no > passphrase was requested. > > When I later looked in the logs, I found: >> Error: Should be encrypting files but failed to read the passphrase, >> so not encrypting. If this drop-off came from a request, the encoded >> passphrase in the request got corrupted! > > which I traced to line 2531 of NSSDropoff.php > which is preceded with the comment block > >> // If we got the encryption passphrase from a request, but failed to >> // be able to read it, the user won't have been prompted to enter one. >> // So we have no way of finding it! So if that failed, don't encrypt >> // at all. > > But this drop/pickup didn't originate with a 'request'. It was done by > an interactive, authenticated user. The user requested encryption, > supplied the phrase, and the application seems to have quietly failed > to encrypt an otherwise acceptable (not too large) file. > > I'm unable to reproduce this failure. > > If the customer asks to encrypt an over-sized file, it is plainly > refused. If encryption has been requested and can't be done for some > other reason, shouldn't that be a blocking-situation? > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'It's very unlikely indeed he will ever recover consciousness, and if he does he won't be the Julian you knew.' - A hospital consultant I proved very wrong in 2007 :-) www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jun 6 11:25:05 2020 From: Jules at Zend.To (Jules) Date: Sat, 6 Jun 2020 11:25:05 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: John, If you are using MyySQL as the back-end, the output from "SHOW CREATE TABLE dropoff" should be this: ? `rowID` int(11) NOT NULL AUTO_INCREMENT, ? `claimID` varchar(16) NOT NULL, ? `claimPasscode` varchar(16) DEFAULT NULL, ? `authorizedUser` varchar(255) NOT NULL, ? `senderName` varchar(32) NOT NULL, ? `senderOrganization` varchar(32) NOT NULL, ? `senderEmail` varchar(255) NOT NULL, ? `confirmDelivery` tinyint(1) NOT NULL DEFAULT '0', ? `senderIP` varchar(256) NOT NULL, ? `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, ? `note` text NOT NULL, ? `lifeseconds` int(11) NOT NULL DEFAULT '0', ? PRIMARY KEY (`rowID`), ? KEY `claimID` (`claimID`) The length of the "senderIP" field should be at least 256. If that field is shorter, that could (don't ask!) explain it. Cheers, Jules. On 05/06/2020 19:53, John Thurston via ZendTo wrote: > I'm looking at moving from V5 to V6. During testing, we turned up > interesting behavior. > > While creating a drop-off, the authenticated customer was prompted for > a passphrase. This was entered and accepted. Checksum was also requested. > > When the upload was complete, the 'Outbox' showed the files with an > "X" in the encrypted column. When later performing the pickup, no > passphrase was requested. > > When I later looked in the logs, I found: >> Error: Should be encrypting files but failed to read the passphrase, >> so not encrypting. If this drop-off came from a request, the encoded >> passphrase in the request got corrupted! > > which I traced to line 2531 of NSSDropoff.php > which is preceded with the comment block > >> // If we got the encryption passphrase from a request, but failed to >> // be able to read it, the user won't have been prompted to enter one. >> // So we have no way of finding it! So if that failed, don't encrypt >> // at all. > > But this drop/pickup didn't originate with a 'request'. It was done by > an interactive, authenticated user. The user requested encryption, > supplied the phrase, and the application seems to have quietly failed > to encrypt an otherwise acceptable (not too large) file. > > I'm unable to reproduce this failure. > > If the customer asks to encrypt an over-sized file, it is plainly > refused. If encryption has been requested and can't be done for some > other reason, shouldn't that be a blocking-situation? > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Once is happenstance, twice is coincidence, three times is enemy action.' - Ian Fleming www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jun 6 14:03:07 2020 From: Jules at Zend.To (Jules) Date: Sat, 6 Jun 2020 14:03:07 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: Can anyone reproduce this? The only way you can reach the bit of code that generates the log message is if there is a form input called "req" which is used to hold the 9-digit number (or string of 3 words) that make up the request code. And "req" must have a non-empty value. Unless you're responding to a request, this form input is always empty. John ? One final question: During the upgrade, did it tell you to generate a better cookieSecret? And did you do so? Changing the cookieSecret while it is in use can also break things for users who happen to be logged in and interacting with the website at the time you change cookieSecret. On 05/06/2020 19:53, John Thurston via ZendTo wrote: > I'm looking at moving from V5 to V6. During testing, we turned up > interesting behavior. > > While creating a drop-off, the authenticated customer was prompted for > a passphrase. This was entered and accepted. Checksum was also requested. > > When the upload was complete, the 'Outbox' showed the files with an > "X" in the encrypted column. When later performing the pickup, no > passphrase was requested. > > When I later looked in the logs, I found: >> Error: Should be encrypting files but failed to read the passphrase, >> so not encrypting. If this drop-off came from a request, the encoded >> passphrase in the request got corrupted! > > which I traced to line 2531 of NSSDropoff.php > which is preceded with the comment block > >> // If we got the encryption passphrase from a request, but failed to >> // be able to read it, the user won't have been prompted to enter one. >> // So we have no way of finding it! So if that failed, don't encrypt >> // at all. > > But this drop/pickup didn't originate with a 'request'. It was done by > an interactive, authenticated user. The user requested encryption, > supplied the phrase, and the application seems to have quietly failed > to encrypt an otherwise acceptable (not too large) file. > > I'm unable to reproduce this failure. > > If the customer asks to encrypt an over-sized file, it is plainly > refused. If encryption has been requested and can't be done for some > other reason, shouldn't that be a blocking-situation? > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'It's very unlikely indeed he will ever recover consciousness, and if he does he won't be the Julian you knew.' - A hospital consultant I proved very wrong in 2007 :-) www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at pcfreak.de Sat Jun 6 16:35:32 2020 From: mailinglists at pcfreak.de (Mailing Lists) Date: Sat, 6 Jun 2020 17:35:32 +0200 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: <2DFAEC3F-B7EC-4F11-BF4C-278B0CBFD9CD@pcfreak.de> Message-ID: maybe a password manager autofills the field without notice? via Smartphone > Am 06.06.2020 um 15:03 schrieb Jules via ZendTo : > > ? Can anyone reproduce this? > > The only way you can reach the bit of code that generates the log message is if there is a form input called "req" which is used to hold the 9-digit number (or string of 3 words) that make up the request code. And "req" must have a non-empty value. > > Unless you're responding to a request, this form input is always empty. > > John ? One final question: During the upgrade, did it tell you to generate a better cookieSecret? And did you do so? Changing the cookieSecret while it is in use can also break things for users who happen to be logged in and interacting with the website at the time you change cookieSecret. > > On 05/06/2020 19:53, John Thurston via ZendTo wrote: >> I'm looking at moving from V5 to V6. During testing, we turned up interesting behavior. >> >> While creating a drop-off, the authenticated customer was prompted for a passphrase. This was entered and accepted. Checksum was also requested. >> >> When the upload was complete, the 'Outbox' showed the files with an "X" in the encrypted column. When later performing the pickup, no passphrase was requested. >> >> When I later looked in the logs, I found: >>> Error: Should be encrypting files but failed to read the passphrase, so not encrypting. If this drop-off came from a request, the encoded passphrase in the request got corrupted! >> >> which I traced to line 2531 of NSSDropoff.php >> which is preceded with the comment block >> >>> // If we got the encryption passphrase from a request, but failed to >>> // be able to read it, the user won't have been prompted to enter one. >>> // So we have no way of finding it! So if that failed, don't encrypt >>> // at all. >> >> But this drop/pickup didn't originate with a 'request'. It was done by an interactive, authenticated user. The user requested encryption, supplied the phrase, and the application seems to have quietly failed to encrypt an otherwise acceptable (not too large) file. >> >> I'm unable to reproduce this failure. >> >> If the customer asks to encrypt an over-sized file, it is plainly refused. If encryption has been requested and can't be done for some other reason, shouldn't that be a blocking-situation? >> >> >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'It's very unlikely indeed he will ever recover consciousness, and > if he does he won't be the Julian you knew.' > - A hospital consultant I proved very wrong in 2007 :-) > > www.Zend.To > Twitter: @JulesFM > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sun Jun 7 10:09:39 2020 From: Jules at Zend.To (Jules) Date: Sun, 7 Jun 2020 10:09:39 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: <2DFAEC3F-B7EC-4F11-BF4C-278B0CBFD9CD@pcfreak.de> Message-ID: <4b1943bf-95dd-9470-6b1b-67308cb71b40@Zend.To> I would certainly hope a password manager isn't auto-filling a hidden input called "req"!! If there's something that's doing that, we're all doomed. Password managers are usually written to avoid "over-filling" forms, so as not to give away passwords to sneaky forms that have a field for it but disguise the fact. But I've been trying to break it again this morning, and I still can't. Cheers, Jules. On 06/06/2020 16:35, Mailing Lists via ZendTo wrote: > maybe a password manager autofills the field without notice? > > via Smartphone > >> Am 06.06.2020 um 15:03 schrieb Jules via ZendTo : >> >> ? Can anyone reproduce this? >> >> The only way you can reach the bit of code that generates the log >> message is if there is a form input called "req" which is used to >> hold the 9-digit number (or string of 3 words) that make up the >> request code. And "req" must have a non-empty value. >> >> Unless you're responding to a request, this form input is always empty. >> >> John ? One final question: During the upgrade, did it tell you to >> generate a better cookieSecret? And did you do so? Changing the >> cookieSecret while it is in use can also break things for users who >> happen to be logged in and interacting with the website at the time >> you change cookieSecret. >> >> On 05/06/2020 19:53, John Thurston via ZendTo wrote: >>> I'm looking at moving from V5 to V6. During testing, we turned up >>> interesting behavior. >>> >>> While creating a drop-off, the authenticated customer was prompted >>> for a passphrase. This was entered and accepted. Checksum was also >>> requested. >>> >>> When the upload was complete, the 'Outbox' showed the files with an >>> "X" in the encrypted column. When later performing the pickup, no >>> passphrase was requested. >>> >>> When I later looked in the logs, I found: >>>> Error: Should be encrypting files but failed to read the >>>> passphrase, so not encrypting. If this drop-off came from a >>>> request, the encoded passphrase in the request got corrupted! >>> >>> which I traced to line 2531 of NSSDropoff.php >>> which is preceded with the comment block >>> >>>> // If we got the encryption passphrase from a request, but failed to >>>> // be able to read it, the user won't have been prompted to enter one. >>>> // So we have no way of finding it! So if that failed, don't encrypt >>>> // at all. >>> >>> But this drop/pickup didn't originate with a 'request'. It was done >>> by an interactive, authenticated user. The user requested >>> encryption, supplied the phrase, and the application seems to have >>> quietly failed to encrypt an otherwise acceptable (not too large) file. >>> >>> I'm unable to reproduce this failure. >>> >>> If the customer asks to encrypt an over-sized file, it is plainly >>> refused. If encryption has been requested and can't be done for some >>> other reason, shouldn't that be a blocking-situation? >>> >>> >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'It's very unlikely indeed he will ever recover consciousness, and >> if he does he won't be the Julian you knew.' >> - A hospital consultant I proved very wrong in 2007 :-) >> >> www.Zend.To >> Twitter: @JulesFM >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Gaze not into the abyss, lest you become recognised as an abyss domain expert, and they expect you to keep gazing into the damn thing.' - @nickm_tor www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Jun 8 11:17:23 2020 From: Jules at Zend.To (Jules) Date: Mon, 8 Jun 2020 11:17:23 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: <02f8b8b0-fcc5-21e7-468f-8593105570b4@Zend.To> John, I have made this situation block, so the user uploading the drop-off will see an error message, and the drop-off attempt will be rejected. This will be in the very next release. I will be interested to see if anyone ever sees the error message! Cheers, Jules. On 05/06/2020 19:53, John Thurston via ZendTo wrote: > I'm looking at moving from V5 to V6. During testing, we turned up > interesting behavior. > > While creating a drop-off, the authenticated customer was prompted for > a passphrase. This was entered and accepted. Checksum was also requested. > > When the upload was complete, the 'Outbox' showed the files with an > "X" in the encrypted column. When later performing the pickup, no > passphrase was requested. > > When I later looked in the logs, I found: >> Error: Should be encrypting files but failed to read the passphrase, >> so not encrypting. If this drop-off came from a request, the encoded >> passphrase in the request got corrupted! > > which I traced to line 2531 of NSSDropoff.php > which is preceded with the comment block > >> // If we got the encryption passphrase from a request, but failed to >> // be able to read it, the user won't have been prompted to enter one. >> // So we have no way of finding it! So if that failed, don't encrypt >> // at all. > > But this drop/pickup didn't originate with a 'request'. It was done by > an interactive, authenticated user. The user requested encryption, > supplied the phrase, and the application seems to have quietly failed > to encrypt an otherwise acceptable (not too large) file. > > I'm unable to reproduce this failure. > > If the customer asks to encrypt an over-sized file, it is plainly > refused. If encryption has been requested and can't be done for some > other reason, shouldn't that be a blocking-situation? > > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Science is an integral part of culture. It's not this foreign thing, done by an arcane priesthood. It's one of the glories of human intellectual tradition.' - Stephen Jay Gould www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Mon Jun 8 18:31:19 2020 From: john.thurston at alaska.gov (John Thurston) Date: Mon, 8 Jun 2020 09:31:19 -0800 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: Jules, we've been beating on this. We are unable to reproduce the failure, regardless of how we twist or hold our tongues. It is in the log, so it happened once. We just can't make it happen again. If it never occurs again, that's fine. If it does occur and blocks, that's fine too. re: your earlier questions (GMT -9 here) + We're using sqlite3 + /opt/zendto/sbin/cleanup.php produced nothing of interest. + 'dropoff' table schema contains "lifeseconds" and "senderIP" is varchar(256) + I did generate a new cookieSecret, but that was done in the days prior to performing the test which failed. I don't think it's related, but if we need an explanation on which to hang our hat, that might be the only thing we have. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska On 6/6/2020 5:03 AM, Jules wrote: > Can anyone reproduce this? > > The only way you can reach the bit of code that generates the log > message is if there is a form input called "req" which is used to hold > the 9-digit number (or string of 3 words) that make up the request code. > And "req" must have a non-empty value. > > Unless you're responding to a request, this form input is always empty. > > John ? One final question: During the upgrade, did it tell you to > generate a better cookieSecret? And did you do so? Changing the > cookieSecret while it is in use can also break things for users who > happen to be logged in and interacting with the website at the time you > change cookieSecret. > > On 05/06/2020 19:53, John Thurston via ZendTo wrote: >> I'm looking at moving from V5 to V6. During testing, we turned up >> interesting behavior. >> >> While creating a drop-off, the authenticated customer was prompted for >> a passphrase. This was entered and accepted. Checksum was also requested. >> >> When the upload was complete, the 'Outbox' showed the files with an >> "X" in the encrypted column. When later performing the pickup, no >> passphrase was requested. >> >> When I later looked in the logs, I found: >>> Error: Should be encrypting files but failed to read the passphrase, >>> so not encrypting. If this drop-off came from a request, the encoded >>> passphrase in the request got corrupted! >> >> which I traced to line 2531 of NSSDropoff.php >> which is preceded with the comment block >> >>> // If we got the encryption passphrase from a request, but failed to >>> // be able to read it, the user won't have been prompted to enter one. >>> // So we have no way of finding it! So if that failed, don't encrypt >>> // at all. >> >> But this drop/pickup didn't originate with a 'request'. It was done by >> an interactive, authenticated user. The user requested encryption, >> supplied the phrase, and the application seems to have quietly failed >> to encrypt an otherwise acceptable (not too large) file. >> >> I'm unable to reproduce this failure. >> >> If the customer asks to encrypt an over-sized file, it is plainly >> refused. If encryption has been requested and can't be done for some >> other reason, shouldn't that be a blocking-situation? >> >> >> > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'It's very unlikely indeed he will ever recover consciousness, and > if he does he won't be the Julian you knew.' > - A hospital consultant I proved very wrong in 2007 :-) > > www.Zend.To > Twitter: @JulesFM > From Jules at Zend.To Mon Jun 8 19:19:15 2020 From: Jules at Zend.To (Jules) Date: Mon, 8 Jun 2020 19:19:15 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: <635e4ddc-ff5b-e733-7fe1-ddbe4618244a@Zend.To> John, Cool. thanks for all of that. I'll put out an update in the morning (GMT+1 as it's apparently summer, not that anyone has told the weather forecasters that) in which it will log exactly as it did, but also spit an error at the user and reject the upload. Many thanks for your time trying to reproduce it, that's much appreciated. Cheers, Jules. On 08/06/2020 18:31, John Thurston via ZendTo wrote: > Jules, we've been beating on this. We are unable to reproduce the > failure, regardless of how we twist or hold our tongues. It is in the > log, so it happened once. We just can't make it happen again. > > If it never occurs again, that's fine. > If it does occur and blocks, that's fine too. > > > re: your earlier questions (GMT -9 here) > > + We're using sqlite3 > > + /opt/zendto/sbin/cleanup.php produced nothing of interest. > > + 'dropoff' table schema contains "lifeseconds" > ?? and "senderIP" is varchar(256) > > + I did generate a new cookieSecret, but that was done in the days > prior to performing the test which failed. I don't think it's related, > but if we need an explanation on which to hang our hat, that might be > the only thing we have. > > -- > Do things because you should, not just because you can. > > John Thurston??? 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > On 6/6/2020 5:03 AM, Jules wrote: >> Can anyone reproduce this? >> >> The only way you can reach the bit of code that generates the log >> message is if there is a form input called "req" which is used to >> hold the 9-digit number (or string of 3 words) that make up the >> request code. And "req" must have a non-empty value. >> >> Unless you're responding to a request, this form input is always empty. >> >> John ? One final question: During the upgrade, did it tell you to >> generate a better cookieSecret? And did you do so? Changing the >> cookieSecret while it is in use can also break things for users who >> happen to be logged in and interacting with the website at the time >> you change cookieSecret. >> >> On 05/06/2020 19:53, John Thurston via ZendTo wrote: >>> I'm looking at moving from V5 to V6. During testing, we turned up >>> interesting behavior. >>> >>> While creating a drop-off, the authenticated customer was prompted >>> for a passphrase. This was entered and accepted. Checksum was also >>> requested. >>> >>> When the upload was complete, the 'Outbox' showed the files with an >>> "X" in the encrypted column. When later performing the pickup, no >>> passphrase was requested. >>> >>> When I later looked in the logs, I found: >>>> Error: Should be encrypting files but failed to read the >>>> passphrase, so not encrypting. If this drop-off came from a >>>> request, the encoded passphrase in the request got corrupted! >>> >>> which I traced to line 2531 of NSSDropoff.php >>> which is preceded with the comment block >>> >>>> // If we got the encryption passphrase from a request, but failed to >>>> // be able to read it, the user won't have been prompted to enter one. >>>> // So we have no way of finding it! So if that failed, don't encrypt >>>> // at all. >>> >>> But this drop/pickup didn't originate with a 'request'. It was done >>> by an interactive, authenticated user. The user requested >>> encryption, supplied the phrase, and the application seems to have >>> quietly failed to encrypt an otherwise acceptable (not too large) file. >>> >>> I'm unable to reproduce this failure. >>> >>> If the customer asks to encrypt an over-sized file, it is plainly >>> refused. If encryption has been requested and can't be done for some >>> other reason, shouldn't that be a blocking-situation? >>> >>> >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'It's very unlikely indeed he will ever recover consciousness, and >> ? if he does he won't be the Julian you knew.' >> ?? - A hospital consultant I proved very wrong in 2007 :-) >> >> www.Zend.To >> Twitter: @JulesFM >> > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Shannon: West or northwest 2 to 4 backing southwest 3 or 4. Slight or moderate in east, moderate throughout in west. Fair then rain. Good, occasionally moderate. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jun 9 11:03:37 2020 From: Jules at Zend.To (Jules) Date: Tue, 9 Jun 2020 11:03:37 +0100 Subject: [ZendTo] Quietly not encrypting in V6 In-Reply-To: References: Message-ID: <496db27e-ad5f-aaf7-6e10-36c501d6227e@Zend.To> John, I have just released 6.01-2 in which this occurrence now causes ZendTo to reject the upload attempt, with an error to the user and an error written to the log. I have just upgraded my own (University of Southampton "SafeSend") service to the new version and all appears to be working fine. Hopefully we can consider this one "closed". Cheers, Jules. On 08/06/2020 18:31, John Thurston via ZendTo wrote: > Jules, we've been beating on this. We are unable to reproduce the > failure, regardless of how we twist or hold our tongues. It is in the > log, so it happened once. We just can't make it happen again. > > If it never occurs again, that's fine. > If it does occur and blocks, that's fine too. > > > re: your earlier questions (GMT -9 here) > > + We're using sqlite3 > > + /opt/zendto/sbin/cleanup.php produced nothing of interest. > > + 'dropoff' table schema contains "lifeseconds" > ?? and "senderIP" is varchar(256) > > + I did generate a new cookieSecret, but that was done in the days > prior to performing the test which failed. I don't think it's related, > but if we need an explanation on which to hang our hat, that might be > the only thing we have. > > -- > Do things because you should, not just because you can. > > John Thurston??? 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > On 6/6/2020 5:03 AM, Jules wrote: >> Can anyone reproduce this? >> >> The only way you can reach the bit of code that generates the log >> message is if there is a form input called "req" which is used to >> hold the 9-digit number (or string of 3 words) that make up the >> request code. And "req" must have a non-empty value. >> >> Unless you're responding to a request, this form input is always empty. >> >> John ? One final question: During the upgrade, did it tell you to >> generate a better cookieSecret? And did you do so? Changing the >> cookieSecret while it is in use can also break things for users who >> happen to be logged in and interacting with the website at the time >> you change cookieSecret. >> >> On 05/06/2020 19:53, John Thurston via ZendTo wrote: >>> I'm looking at moving from V5 to V6. During testing, we turned up >>> interesting behavior. >>> >>> While creating a drop-off, the authenticated customer was prompted >>> for a passphrase. This was entered and accepted. Checksum was also >>> requested. >>> >>> When the upload was complete, the 'Outbox' showed the files with an >>> "X" in the encrypted column. When later performing the pickup, no >>> passphrase was requested. >>> >>> When I later looked in the logs, I found: >>>> Error: Should be encrypting files but failed to read the >>>> passphrase, so not encrypting. If this drop-off came from a >>>> request, the encoded passphrase in the request got corrupted! >>> >>> which I traced to line 2531 of NSSDropoff.php >>> which is preceded with the comment block >>> >>>> // If we got the encryption passphrase from a request, but failed to >>>> // be able to read it, the user won't have been prompted to enter one. >>>> // So we have no way of finding it! So if that failed, don't encrypt >>>> // at all. >>> >>> But this drop/pickup didn't originate with a 'request'. It was done >>> by an interactive, authenticated user. The user requested >>> encryption, supplied the phrase, and the application seems to have >>> quietly failed to encrypt an otherwise acceptable (not too large) file. >>> >>> I'm unable to reproduce this failure. >>> >>> If the customer asks to encrypt an over-sized file, it is plainly >>> refused. If encryption has been requested and can't be done for some >>> other reason, shouldn't that be a blocking-situation? >>> >>> >>> >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'It's very unlikely indeed he will ever recover consciousness, and >> ? if he does he won't be the Julian you knew.' >> ?? - A hospital consultant I proved very wrong in 2007 :-) >> >> www.Zend.To >> Twitter: @JulesFM >> > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: German Bight: Northwest 2 to 4 becoming variable 3 or less. Slight or moderate becoming slight. Showers. Good. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From it at dellconsultingllc.com Wed Jun 10 16:55:44 2020 From: it at dellconsultingllc.com (Michael Imlay) Date: Wed, 10 Jun 2020 15:55:44 +0000 Subject: [ZendTo] Expire Time Incorrect References: Message-ID: Hey, I have my ZendTo configured to send out a notification started 3 days prior to removing the files. On the site it shows correct, but the user who receives the e-mails gets something like this: This is a reminder about a drop-off sent to you, that no one has picked up. The drop-off will expire in 10911 days and 16 hours after which it will be automatically deleted. This is a reminder about a drop-off sent to you, that no one has picked up. The drop-off will expire in 10912 days and 16 hours after which it will be automatically deleted. This is a reminder about a drop-off sent to you, that no one has picked up. The drop-off will expire in 10913 days and 16 hours after which it will be automatically deleted. Any idea why this might be happening on just the reminder e-mails? Thanks, Michael Imlay [DELL LOGO] Michael Imlay IT & Telecommunications Designer 129 East Government Street Pensacola, FL 32502 Direct: 850-332-2084 Office: 850-332-5687 x117 Cell: 850-737-9219 IT at DellConsultingLLC.com This email and any files transmitted with it may contain PRIVILEGED or CONFIDENTIAL information and may be read or used only by the intended recipient. If you are not the intended recipient of the email or any of its attachments, please be advised that you have received this email in error and that any use, dissemination, distribution, forwarding, printing, or copying of this email or any attached files is strictly prohibited. If you have received this email in error, please immediately purge it and all attachments and notify the sender by reply email or contact the sender at the number listed. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9426 bytes Desc: image001.png URL: From Jules at Zend.To Wed Jun 10 17:11:19 2020 From: Jules at Zend.To (Jules) Date: Wed, 10 Jun 2020 17:11:19 +0100 Subject: [ZendTo] Expire Time Incorrect In-Reply-To: References: Message-ID: Michael, What version are you running? And what are you running it on? Jules. On 10/06/2020 16:55, Michael Imlay via ZendTo wrote: > > Hey, > > I have my ZendTo configured to send out a notification started 3 days > prior to removing the files. On the site it shows correct, but the > user who receives the e-mails gets something like this: > > *This is a reminder about a drop-off sent to you, that no one has > picked up.** > *The drop-off will expire in 10911 days and 16 hours after which it > will be automatically deleted.** > > ** > > *This is a reminder about a drop-off sent to you, that no one has > picked up.** > *The drop-off will expire in 10912 days and 16 hours after which it > will be automatically deleted.** > > ** > > *This is a reminder about a drop-off sent to you, that no one has > picked up.** > *The drop-off will expire in 10913 days and 16 hours after which it > will be automatically deleted.** > > ** > > Any idea why this might be happening on just the reminder e-mails? > > Thanks, > > Michael Imlay > > DELL LOGO > > Michael Imlay > > IT & Telecommunications Designer > > 129 East Government Street > > Pensacola, FL 32502 > > Direct:? 850-332-2084 > Office:? 850-332-5687 x117 > > Cell: ????? 850-737-9219 > > IT at DellConsultingLLC.com > > This email and any files transmitted with it may contain PRIVILEGED or > CONFIDENTIAL information and may be read or used only by the intended > recipient. If you are not the intended recipient of the email or any > of its attachments, please be advised that you have received this > email in error and that any use, dissemination, distribution, > forwarding, printing, or copying of this email or any attached files > is strictly prohibited. If you have received this email in error, > please immediately purge it and all attachments and notify the sender > by reply email or contact the sender at the number listed. > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'It's very unlikely indeed he will ever recover consciousness, and if he does he won't be the Julian you knew.' - A hospital consultant I proved very wrong in 2007 :-) www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9426 bytes Desc: not available URL: From marcel.richter at remondis.de Tue Jun 16 11:59:31 2020 From: marcel.richter at remondis.de (marcel.richter at remondis.de) Date: Tue, 16 Jun 2020 12:59:31 +0200 Subject: [ZendTo] Delete all droppoffs References: Message-ID: Hi Jules, I just cloned my ZendTo System because we want to update but had to test the new version.. Now in the clone (logicaly) there are all droppoffs in it. Is there maybe a way to delete all uploads at once as an admin? In our setup its not soooo important because we did not set warnDaysBeforeDeletion. Mit freundlichen Gr??en Marcel Richter Infrastructure // Network & Security REMONDIS IT Services GmbH & Co. KG Brunnenstr. 138 // 44536 L?nen // Deutschland T + 49 2306 106-8866 // F +49 2306 106-399-8866 marcel.richter at remondis.de // remondis-it.de Unsere Datenschutzhinweise entnehmen Sie bitte folgendem Link: https://www.remondis.de/datenverarbeitung REMONDIS IT Services GmbH & Co. KG // Brunnenstr. 138 // 44536 L?nen // Deutschland // Amtsgericht Dortmund, HRA 17891 // Pers?nlich haftende Gesellschafterin: REMONDIS IT Services Verwaltungs GmbH, 44536 L?nen, Amtsgericht Dortmund, HRB 26665 // Gesch?ftsf?hrer: Josef Br?sterhaus, Lars Karnowsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3280 bytes Desc: not available URL: From Jules at Zend.To Tue Jun 16 12:11:35 2020 From: Jules at Zend.To (Jules) Date: Tue, 16 Jun 2020 12:11:35 +0100 Subject: [ZendTo] Delete all droppoffs In-Reply-To: References: Message-ID: <537ccc54-5c15-dcdf-0b44-49d2634847a6@Zend.To> Marcel, If you physically delete the drop-off files, i.e. ??? rm -rf /var/zendto/dropoffs/* and then run ??? /opt/zendto/sbin/cleanup.php then you should find it clears out all the orphaned DB records for you. Just please make sure you're doing it on the clone and not your live one! Cheers, Jules. On 16/06/2020 11:59, Marcel Richter via ZendTo wrote: > Hi Jules, > > I just cloned my ZendTo System because we want to update but had to > test the new version.. Now in the clone (logicaly) there are all > droppoffs in it. > Is there maybe a way to delete all uploads at once as an admin? > > In our setup its not soooo important because we did not set > warnDaysBeforeDeletion. > > Mit freundlichen Gr??en > > Marcel Richter > Infrastructure // Network & Security > > REMONDIS IT Services GmbH & Co. KG > Brunnenstr. 138 // 44536 L?nen // Deutschland > T + 49 2306 106-8866?// F +49 2306 106-399-8866 > marcel.richter at remondis.de// remondis-it.de > > > > Unsere Datenschutzhinweise entnehmen Sie bitte folgendem Link: > https://www.remondis.de/datenverarbeitung > > > REMONDIS IT Services GmbH & Co. KG // Brunnenstr. 138 // 44536 L?nen > // Deutschland ?// Amtsgericht Dortmund, HRA 17891 // Pers?nlich > haftende Gesellschafterin: REMONDIS IT Services Verwaltungs GmbH, > 44536 L?nen, Amtsgericht Dortmund, HRB 26665 // Gesch?ftsf?hrer: Josef > Br?sterhaus, Lars Karnowsky > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nkefhghhgopmnepm.png Type: image/png Size: 3280 bytes Desc: not available URL: From john.thurston at alaska.gov Wed Jun 17 19:13:06 2020 From: john.thurston at alaska.gov (John Thurston) Date: Wed, 17 Jun 2020 10:13:06 -0800 Subject: [ZendTo] Current state of the art for reverse proxy? References: Message-ID: I run my ZendTo instance behind an Apache proxy. It works fine. We once tried to put it behind a Netscaler proxy. It was bad*. I want to move my ZendTo behind an F5 instance. Before I head bravely off into the wild, does anyone want to share any tips for ZendTo behind F5? Any gotchas? Any "don't forget to" tales to share? * I don't recall exactly why it was bad, just that we gave up on the effort and returned to the Apache. This was years ago. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska From Jules at Zend.To Wed Jun 17 19:23:19 2020 From: Jules at Zend.To (Jules) Date: Wed, 17 Jun 2020 19:23:19 +0100 Subject: [ZendTo] Current state of the art for reverse proxy? In-Reply-To: References: Message-ID: John, There's a preferences.php setting to tell it you're behind a load balancer, which you'll need to set to TRUE or else it will log everything as having come from the load balancer and not the real client IP (thanks to my friends at .mil for suggesting a config option for that). But at University of Southampton (my day job) we run behind F5's with no problem. Cheers, Jules. On 17/06/2020 19:13, John Thurston via ZendTo wrote: > I run my ZendTo instance behind an Apache proxy. It works fine. > > We once tried to put it behind a Netscaler proxy. It was bad*. > > I want to move my ZendTo behind an F5 instance. > > Before I head bravely off into the wild, does anyone want to share any > tips for ZendTo behind F5? Any gotchas? Any "don't forget to" tales to > share? > > > > > * I don't recall exactly why it was bad, just that we gave up on the > effort and returned to the Apache. This was years ago. > > > -- > Do things because you should, not just because you can. > > John Thurston??? 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'To see a World in a Grain of Sand And a Heaven in a Wild Flower Hold Infinity in the palm of your hand And Eternity in an hour' - William Blake www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Jun 19 17:22:45 2020 From: Jules at Zend.To (Jules) Date: Fri, 19 Jun 2020 17:22:45 +0100 Subject: [ZendTo] Feature Request custom string in subject per DropOff In-Reply-To: References: <72d61410dcb94e67a16481300a961282@City-Exch-DB1.cbj.local> <19accbbc-b2b1-241d-531d-a717fc8dc15a@Zend.To> <736600cebd8d4738999450bcac9783c1@City-Exch-DB1.cbj.local> Message-ID: <94ab92e3-d096-3c7d-a386-317df54a3525@Zend.To> Folks, This feature is now in the latest beta release, 6.02-1 which is available from the beta page on the website at ??? https://zend.to/beta When you create a new drop-off, the Subject line is shown next to the "From". *You can edit the Subject how you like. *The "EmailSubjectTag" from zendto.conf will still be added onto the start of the Subject before the emails are actually sent. If you would prefer that the EmailSubjectTag was included in the editable bit, so you can remove it, let me know. This has involved quite a major change in the HTML structure of the form, so if you see browsers where it doesn't display perfectly, please do tell me! Thanks! Jules. On 01/05/2019 10:03, Jules Field wrote: > > > On 30/04/2019 23:42, Kevin Miller via ZendTo wrote: >> >> I was thinking of something sort of along the lines of what Travis >> McDugald proposed: >> >> ? If (isset($messageID)) then $subject = [Zendto] . $messageID . >> $subject; else $subject = [Zendto] . $subject; >> >> although rather than an additional messageID I was envisioning just >> changing the prefix. >> > I am wary of allowing things like ticket numbers in the [] prefix, as > I bet some lousy ticketing systems out there will only spot the ticket > number if it has whitespace after it and not some bracket or other > punctuation. > >> I.e. I was thinking that [Zendto] would be a variable set in >> preferneces.php which could be customized.? Something like: >> >> ?Zendto_prefix? => ?[Zendto]?, >> >> which folks could simply change to what they wanted or leave it as >> the default.? I didn?t really explain it very clearly. >> >> We?re probably the outlier, but the powers that be upstream of me >> decided we?d call our system ?fileshare? rather than Zendto.? So in >> my case I?d change the prefix itself if such was available.? I can >> see the use case for what Travis, et. al. are proposing as well? >> > Greg has already answered that one for me. :-) > > Cheers, > Jules. > >> ...Kevin >> >> -- >> >> Kevin Miller >> >> Network/email Administrator, CBJ MIS Dept. >> >> 155 South Seward Street >> >> Juneau, Alaska 99801 >> >> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: >> 307357 >> >> *From:*ZendTo *On Behalf Of *Jules Field via >> ZendTo >> *Sent:* Tuesday, April 30, 2019 12:35 AM >> *To:* ZendTo Users >> *Cc:* Jules Field ; Kevin Miller >> *Subject:* Re: [ZendTo] [Feature Request custom string in subject per >> DropOff] >> >> Kevin, >> >> But in the case of a request, as much as possible is pre-filled for >> the customer dropping off files. >> All the other Subject lines generated are hard-coded (apart from >> translations). >> >> If you are thinking of either changing the [ZendTo] prefix to some >> other string, or adding something between the [ZendTo] prefix and the >> rest of the string, where and when is that going to be set? >> >> The "new dropoff" form needs to gain an extra "Message ID" (or >> whatever) box so people can put in their magic string. >> >> Are you saying the "send a request" form needs to gain it too? >> (And presumably if the answer to that is "yes", the "new dropoff" >> form would pre-fill the "Message ID" value from what was given in the >> request. And if that is the case, should the customer doing the >> dropoff be able to change the "Message ID" value at that point? I >> would suggest not.) >> >> I think we're all thinking about variations on either ticketing >> systems or people with multiple projects, where they need some magic >> value in the Subject line of *every* email message sent by ZendTo so >> that they can all be tracked and filed automatically. >> >> Cheers, >> Jules. >> >> On 29/04/2019 17:53, Kevin Miller via ZendTo wrote: >> >> Unless I?m misunderstand the conundrum, I?d say to let the >> requester enter the subject line, sans prefix, then prepend the >> system defined prefix at upload generation time.? I.e., if I was >> requesting a dropoff I?d put in ?My appropriate subject?.? The >> person that is actually doing the dropoff would see that, and >> probably won?t think twice about it.? Then, when the outgoing >> upload ?notification is actually complete, Zendto can prepend the >> system supplied prefix [Zendto] or [Whatever] and send that.? I >> don?t think folks are in the habit of hand coding prefixes, so >> it?s unlikely one would end up with dual prefixes. >> >> Maybe there?s coding issues with that that make it difficult? >> Anyway, my tuppence worth? >> >> ...Kevin >> >> -- >> >> Kevin Miller >> >> Network/email Administrator, CBJ MIS Dept. >> >> 155 South Seward Street >> >> Juneau, Alaska 99801 >> >> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User >> No: 307357 >> >> *From:*ZendTo >> *On Behalf Of *Jules Field via ZendTo >> *Sent:* Monday, April 29, 2019 6:19 AM >> *To:* ZendTo Users >> *Cc:* Jules Field >> *Subject:* Re: [ZendTo] [Feature Request custom string in subject >> per DropOff] >> >> Folks, >> >> I'm having a think about this one. >> >> The idea of the prefix is pretty simple, basically I would give >> you the "[ZendTo]" string (as an initial default value) in a >> "Subject" box in the new drop-off form. >> >> Whatever you end up putting in there gets used instead of >> [ZendTo] at the start of the email subject lines. >> >> However...... >> >> If you request a drop-off, you get to supply the whole Subject >> line for the email to the person you want to send you their files. >> Ideally, that same Subject line would be used in all >> notifications etc about that drop-off. >> But they have entered the *whole* Subject line, not just the >> prefix to it. >> If I use their whole Subject line as a prefix, it's going to look >> weird. >> >> So what do I do for the Subject prefix, when it was created as a >> result of a request which had the entire Subject line supplied? >> I clearly can't ask the person sending the request to supply 2 >> Subject entries ? both the current whole Subject line *and* the >> prefix to use ? as that would confuse the hell out of them. >> >> Any ideas please? >> >> Cheers, >> Jules. >> >> On 21/04/2019 14:29, Mailing Lists via ZendTo wrote: >> >> Hi Jules, >> >> yes it would be enough to allow 20 editable characters. >> >> via Smartphone >> >> >> Am 21.04.2019 um 15:13 schrieb Travis McDugald via ZendTo >> >: >> >> While no one has asked for this yet, I do see it?s >> usefulness. >> >> I do use custom strings in email subjects for some >> projects as well. ?Helps with sorting, searching, and >> filtering. >> >> Side note: great job on everything Jules, thank you. >> >> Sent from my iPad >> >> >> On Apr 21, 2019, at 7:40 AM, Jules via ZendTo >> > wrote: >> >> Peter, >> >> You effectively just want to allow senders to >> customise the "[ZENDTO]" subject line tag in each >> drop-off, correct? >> >> Does anyone else need to do this too? >> >> Cheers, >> Jules. >> >> On 21/02/2019 2:21 pm, Der PCFreak via ZendTo wrote: >> >> Hi Jules, hi all. >> >> I have a strange request from our ZendTo users. >> They asked if it would be possible to add a >> custom field when sending a DropOff >> that results in a custom text in all ZendTo email >> concerning this specific DropOff. >> >> Example current: >> >> [ZENDTO] One of the recipients has picked up your >> drop-off! >> >> Example requested: >> >> [ZENDTO] CUSTOM_STRING One of the recipients has >> picked up your drop-off! >> >> I asked a little bit about the purpose of their >> request and they told me that project teams sort >> their email by subject and >> consequently keep the project name >> (CUSTOM_STRING) in every subject of their emails >> concerning that specific project. >> So later they could sort by project name >> (CUSTOM_STRING) within Outlook to be able to >> verify when they sent a specific DropOff. >> >> Question: >> Is it possible to implement such a feature? >> >> I know that I could handcraft it but I don't want >> to make big changes to the source and always have >> to keep track of them when upgrading. >> >> I am currently not on the latest version of >> ZendTo, so if such a feature is maybe already >> present in the latest version, feel free >> to tell me. >> >> Thanks in advance. >> >> Peter >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> >> >> >> >> >> Jules >> >> >> >> -- >> >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> >> >> 'Once is happenstance, twice is coincidence, three times is enemy >> >> action.' - Ian Fleming >> >> >> >> www.Zend.To >> >> Twitter: @JulesFM >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> >> >> >> >> >> _______________________________________________ >> >> ZendTo mailing list >> >> ZendTo at zend.to >> >> http://jul.es/mailman/listinfo/zendto >> >> >> >> >> Jules >> >> >> >> -- >> >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> >> >> 'Find a place inside where there's joy, and the joy will burn out >> >> the pain.' - Joseph Campbell >> >> >> >> www.Zend.To >> >> Twitter: @JulesFM >> >> >> >> _______________________________________________ >> >> ZendTo mailing list >> >> ZendTo at zend.to >> >> http://jul.es/mailman/listinfo/zendto >> >> >> >> Jules >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait >> www.Zend.To >> Twitter: @JulesFM >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Making machines do what you want requires only two qualities: > 1) Being slightly more stubborn that the computer, & > 2) Remembering that computers are electrified rocks.' - @JediJeremy > > www.Zend.To > Twitter: @JulesFM Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'In Flanders fields the poppies blow Between the crosses, row on row, That mark our place: and in the sky The larks still bravely singing fly Scarce heard amid the guns below. We are the dead: Short days ago, We lived, felt dawn, saw sunset glow, Loved and were loved: and now we lie In Flanders fields! Take up our quarrel with the foe To you, from failing hands, we throw The torch: be yours to hold it high If ye break faith with us who die, We shall not sleep, though poppies grow In Flanders fields.' Lieutenant Colonel John McCrae Composed at the battlefront on May 3, 1915 during the second battle of Ypres, Belgium www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglagm at gmail.com Sat Jun 20 13:30:22 2020 From: douglagm at gmail.com (Gregg Douglas) Date: Sat, 20 Jun 2020 14:30:22 +0200 Subject: [ZendTo] Feature Request custom string in subject per DropOff In-Reply-To: References: <72d61410dcb94e67a16481300a961282@City-Exch-DB1.cbj.local> <19accbbc-b2b1-241d-531d-a717fc8dc15a@Zend.To> <736600cebd8d4738999450bcac9783c1@City-Exch-DB1.cbj.local> <94ab92e3-d096-3c7d-a386-317df54a3525@Zend.To> Message-ID: Hi, Great new feature, can the autolist be updated to include searching using this new field? Regards Gregg On Fri, Jun 19, 2020 at 6:23 PM Jules via ZendTo wrote: > Folks, > > This feature is now in the latest beta release, 6.02-1 which is available > from the beta page on the website at > https://zend.to/beta > > When you create a new drop-off, the Subject line is shown next to the > "From". > > > *You can edit the Subject how you like. *The "EmailSubjectTag" from > zendto.conf will still be added onto the start of the Subject before the > emails are actually sent. > If you would prefer that the EmailSubjectTag was included in the editable > bit, so you can remove it, let me know. > > This has involved quite a major change in the HTML structure of the form, > so if you see browsers where it doesn't display perfectly, please do tell > me! > > Thanks! > Jules. > > On 01/05/2019 10:03, Jules Field wrote: > > > > On 30/04/2019 23:42, Kevin Miller via ZendTo wrote: > > I was thinking of something sort of along the lines of what Travis > McDugald proposed: > > If (isset($messageID)) then $subject = [Zendto] . $messageID . $subject; > else $subject = [Zendto] . $subject; > > although rather than an additional messageID I was envisioning just > changing the prefix. > > I am wary of allowing things like ticket numbers in the [] prefix, as I > bet some lousy ticketing systems out there will only spot the ticket number > if it has whitespace after it and not some bracket or other punctuation. > > > > I.e. I was thinking that [Zendto] would be a variable set in > preferneces.php which could be customized. Something like: > > ?Zendto_prefix? => ?[Zendto]?, > > which folks could simply change to what they wanted or leave it as the > default. I didn?t really explain it very clearly. > > > > We?re probably the outlier, but the powers that be upstream of me decided > we?d call our system ?fileshare? rather than Zendto. So in my case I?d > change the prefix itself if such was available. I can see the use case for > what Travis, et. al. are proposing as well? > > Greg has already answered that one for me. :-) > > Cheers, > Jules. > > > > ...Kevin > > -- > > Kevin Miller > > Network/email Administrator, CBJ MIS Dept. > > 155 South Seward Street > > Juneau, Alaska 99801 > > Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 > > > > *From:* ZendTo *On > Behalf Of *Jules Field via ZendTo > *Sent:* Tuesday, April 30, 2019 12:35 AM > *To:* ZendTo Users > *Cc:* Jules Field ; Kevin Miller > > *Subject:* Re: [ZendTo] [Feature Request custom string in subject per > DropOff] > > > > Kevin, > > But in the case of a request, as much as possible is pre-filled for the > customer dropping off files. > All the other Subject lines generated are hard-coded (apart from > translations). > > If you are thinking of either changing the [ZendTo] prefix to some other > string, or adding something between the [ZendTo] prefix and the rest of the > string, where and when is that going to be set? > > The "new dropoff" form needs to gain an extra "Message ID" (or whatever) > box so people can put in their magic string. > > Are you saying the "send a request" form needs to gain it too? > (And presumably if the answer to that is "yes", the "new dropoff" form > would pre-fill the "Message ID" value from what was given in the request. > And if that is the case, should the customer doing the dropoff be able to > change the "Message ID" value at that point? I would suggest not.) > > I think we're all thinking about variations on either ticketing systems or > people with multiple projects, where they need some magic value in the > Subject line of *every* email message sent by ZendTo so that they can all > be tracked and filed automatically. > > Cheers, > Jules. > > On 29/04/2019 17:53, Kevin Miller via ZendTo wrote: > > Unless I?m misunderstand the conundrum, I?d say to let the requester enter > the subject line, sans prefix, then prepend the system defined prefix at > upload generation time. I.e., if I was requesting a dropoff I?d put in ?My > appropriate subject?. The person that is actually doing the dropoff would > see that, and probably won?t think twice about it. Then, when the outgoing > upload notification is actually complete, Zendto can prepend the system > supplied prefix [Zendto] or [Whatever] and send that. I don?t think folks > are in the habit of hand coding prefixes, so it?s unlikely one would end up > with dual prefixes. > > > > Maybe there?s coding issues with that that make it difficult? Anyway, my > tuppence worth? > > > > ...Kevin > > -- > > Kevin Miller > > Network/email Administrator, CBJ MIS Dept. > > 155 South Seward Street > > Juneau, Alaska 99801 > > Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357 > > > > *From:* ZendTo *On > Behalf Of *Jules Field via ZendTo > *Sent:* Monday, April 29, 2019 6:19 AM > *To:* ZendTo Users > *Cc:* Jules Field > *Subject:* Re: [ZendTo] [Feature Request custom string in subject per > DropOff] > > > > Folks, > > I'm having a think about this one. > > The idea of the prefix is pretty simple, basically I would give you the > "[ZendTo]" string (as an initial default value) in a "Subject" box in the > new drop-off form. > > Whatever you end up putting in there gets used instead of [ZendTo] at the > start of the email subject lines. > > However...... > > If you request a drop-off, you get to supply the whole Subject line for > the email to the person you want to send you their files. > Ideally, that same Subject line would be used in all notifications etc > about that drop-off. > But they have entered the *whole* Subject line, not just the prefix to it. > If I use their whole Subject line as a prefix, it's going to look weird. > > So what do I do for the Subject prefix, when it was created as a result of > a request which had the entire Subject line supplied? > I clearly can't ask the person sending the request to supply 2 Subject > entries ? both the current whole Subject line *and* the prefix to use ? as > that would confuse the hell out of them. > > Any ideas please? > > Cheers, > Jules. > > On 21/04/2019 14:29, Mailing Lists via ZendTo wrote: > > Hi Jules, > > > > yes it would be enough to allow 20 editable characters. > > via Smartphone > > > Am 21.04.2019 um 15:13 schrieb Travis McDugald via ZendTo >: > > While no one has asked for this yet, I do see it?s usefulness. > > I do use custom strings in email subjects for some projects as well. > Helps with sorting, searching, and filtering. > > > > Side note: great job on everything Jules, thank you. > > > > Sent from my iPad > > > On Apr 21, 2019, at 7:40 AM, Jules via ZendTo wrote: > > Peter, > > You effectively just want to allow senders to customise the "[ZENDTO]" > subject line tag in each drop-off, correct? > > Does anyone else need to do this too? > > Cheers, > Jules. > > On 21/02/2019 2:21 pm, Der PCFreak via ZendTo wrote: > > Hi Jules, hi all. > > I have a strange request from our ZendTo users. They asked if it would be > possible to add a custom field when sending a DropOff > that results in a custom text in all ZendTo email concerning this specific > DropOff. > > Example current: > > [ZENDTO] One of the recipients has picked up your drop-off! > > Example requested: > > [ZENDTO] CUSTOM_STRING One of the recipients has picked up your drop-off! > > I asked a little bit about the purpose of their request and they told me > that project teams sort their email by subject and > consequently keep the project name (CUSTOM_STRING) in every subject of > their emails concerning that specific project. > So later they could sort by project name (CUSTOM_STRING) within Outlook to > be able to verify when they sent a specific DropOff. > > Question: > Is it possible to implement such a feature? > > I know that I could handcraft it but I don't want to make big changes to > the source and always have to keep track of them when upgrading. > > I am currently not on the latest version of ZendTo, so if such a feature > is maybe already present in the latest version, feel free > to tell me. > > Thanks in advance. > > Peter > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Once is happenstance, twice is coincidence, three times is enemy > > action.' - Ian Fleming > > > > www.Zend.To > > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Find a place inside where there's joy, and the joy will burn out > > the pain.' - Joseph Campbell > > > > www.Zend.To > > Twitter: @JulesFM > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait > > > > www.Zend.To > > Twitter: @JulesFM > > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Making machines do what you want requires only two qualities: > 1) Being slightly more stubborn that the computer, & > 2) Remembering that computers are electrified rocks.' - @JediJeremy > www.Zend.To > Twitter: @JulesFM > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'In Flanders fields the poppies blow > Between the crosses, row on row, > That mark our place: and in the sky > The larks still bravely singing fly > Scarce heard amid the guns below. > > We are the dead: Short days ago, > We lived, felt dawn, saw sunset glow, > Loved and were loved: and now we lie > In Flanders fields! > > Take up our quarrel with the foe > To you, from failing hands, we throw > The torch: be yours to hold it high > If ye break faith with us who die, > We shall not sleep, though poppies grow > In Flanders fields.' Lieutenant Colonel John McCrae > > Composed at the battlefront on May 3, 1915 > during the second battle of Ypres, Belgium > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jun 20 15:00:20 2020 From: Jules at Zend.To (Jules) Date: Sat, 20 Jun 2020 15:00:20 +0100 Subject: [ZendTo] Feature Request custom string in subject per DropOff In-Reply-To: References: <72d61410dcb94e67a16481300a961282@City-Exch-DB1.cbj.local> <19accbbc-b2b1-241d-531d-a717fc8dc15a@Zend.To> <736600cebd8d4738999450bcac9783c1@City-Exch-DB1.cbj.local> <94ab92e3-d096-3c7d-a386-317df54a3525@Zend.To> Message-ID: <3655272c-0eb3-6c35-6644-ee06d74f6218@Zend.To> Thanks for reminding me about that. Short answer: yes. :-) Cheers, Jules. On 20/06/2020 13:30, Gregg Douglas via ZendTo wrote: > Hi, > > Great new feature, can the autolist be updated to include searching > using this new field? > > Regards > Gregg > > > On Fri, Jun 19, 2020 at 6:23 PM Jules via ZendTo > wrote: > > Folks, > > This feature is now in the latest beta release, 6.02-1 which is > available from the beta page on the website at > https://zend.to/beta > > When you create a new drop-off, the Subject line is shown next to > the "From". > *You can edit the Subject how you like. > > *The "EmailSubjectTag" from zendto.conf will still be added onto > the start of the Subject before the emails are actually sent. > If you would prefer that the EmailSubjectTag was included in the > editable bit, so you can remove it, let me know. > > This has involved quite a major change in the HTML structure of > the form, so if you see browsers where it doesn't display > perfectly, please do tell me! > > Thanks! > Jules. > > On 01/05/2019 10:03, Jules Field wrote: >> >> >> On 30/04/2019 23:42, Kevin Miller via ZendTo wrote: >>> >>> I was thinking of something sort of along the lines of what >>> Travis McDugald proposed: >>> >>> ? If (isset($messageID)) then $subject = [Zendto] . $messageID . >>> $subject; else $subject = [Zendto] . $subject; >>> >>> although rather than an additional messageID I was envisioning >>> just changing the prefix. >>> >> I am wary of allowing things like ticket numbers in the [] >> prefix, as I bet some lousy ticketing systems out there will only >> spot the ticket number if it has whitespace after it and not some >> bracket or other punctuation. >> >>> I.e. I was thinking that [Zendto] would be a variable set in >>> preferneces.php which could be customized. Something like: >>> >>> ?Zendto_prefix? => ?[Zendto]?, >>> >>> which folks could simply change to what they wanted or leave it >>> as the default.? I didn?t really explain it very clearly. >>> >>> We?re probably the outlier, but the powers that be upstream of >>> me decided we?d call our system ?fileshare? rather than Zendto.? >>> So in my case I?d change the prefix itself if such was >>> available.? I can see the use case for what Travis, et. al. are >>> proposing as well? >>> >> Greg has already answered that one for me. :-) >> >> Cheers, >> Jules. >> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User >>> No: 307357 >>> >>> *From:*ZendTo >>> *On Behalf Of *Jules Field via >>> ZendTo >>> *Sent:* Tuesday, April 30, 2019 12:35 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field ; Kevin >>> Miller >>> *Subject:* Re: [ZendTo] [Feature Request custom string in >>> subject per DropOff] >>> >>> Kevin, >>> >>> But in the case of a request, as much as possible is pre-filled >>> for the customer dropping off files. >>> All the other Subject lines generated are hard-coded (apart from >>> translations). >>> >>> If you are thinking of either changing the [ZendTo] prefix to >>> some other string, or adding something between the [ZendTo] >>> prefix and the rest of the string, where and when is that going >>> to be set? >>> >>> The "new dropoff" form needs to gain an extra "Message ID" (or >>> whatever) box so people can put in their magic string. >>> >>> Are you saying the "send a request" form needs to gain it too? >>> (And presumably if the answer to that is "yes", the "new >>> dropoff" form would pre-fill the "Message ID" value from what >>> was given in the request. And if that is the case, should the >>> customer doing the dropoff be able to change the "Message ID" >>> value at that point? I would suggest not.) >>> >>> I think we're all thinking about variations on either ticketing >>> systems or people with multiple projects, where they need some >>> magic value in the Subject line of *every* email message sent by >>> ZendTo so that they can all be tracked and filed automatically. >>> >>> Cheers, >>> Jules. >>> >>> On 29/04/2019 17:53, Kevin Miller via ZendTo wrote: >>> >>> Unless I?m misunderstand the conundrum, I?d say to let the >>> requester enter the subject line, sans prefix, then prepend >>> the system defined prefix at upload generation time.? I.e., >>> if I was requesting a dropoff I?d put in ?My appropriate >>> subject?.? The person that is actually doing the dropoff >>> would see that, and probably won?t think twice about it.? >>> Then, when the outgoing upload ?notification is actually >>> complete, Zendto can prepend the system supplied prefix >>> [Zendto] or [Whatever] and send that.? I don?t think folks >>> are in the habit of hand coding prefixes, so it?s unlikely >>> one would end up with dual prefixes. >>> >>> Maybe there?s coding issues with that that make it >>> difficult?? Anyway, my tuppence worth? >>> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux >>> User No: 307357 >>> >>> *From:*ZendTo >>> *On Behalf Of *Jules Field >>> via ZendTo >>> *Sent:* Monday, April 29, 2019 6:19 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field >>> *Subject:* Re: [ZendTo] [Feature Request custom string in >>> subject per DropOff] >>> >>> Folks, >>> >>> I'm having a think about this one. >>> >>> The idea of the prefix is pretty simple, basically I would >>> give you the "[ZendTo]" string (as an initial default value) >>> in a "Subject" box in the new drop-off form. >>> >>> Whatever you end up putting in there gets used instead of >>> [ZendTo] at the start of the email subject lines. >>> >>> However...... >>> >>> If you request a drop-off, you get to supply the whole >>> Subject line for the email to the person you want to send >>> you their files. >>> Ideally, that same Subject line would be used in all >>> notifications etc about that drop-off. >>> But they have entered the *whole* Subject line, not just the >>> prefix to it. >>> If I use their whole Subject line as a prefix, it's going to >>> look weird. >>> >>> So what do I do for the Subject prefix, when it was created >>> as a result of a request which had the entire Subject line >>> supplied? >>> I clearly can't ask the person sending the request to supply >>> 2 Subject entries ? both the current whole Subject line >>> *and* the prefix to use ? as that would confuse the hell out >>> of them. >>> >>> Any ideas please? >>> >>> Cheers, >>> Jules. >>> >>> On 21/04/2019 14:29, Mailing Lists via ZendTo wrote: >>> >>> Hi Jules, >>> >>> yes it would be enough to allow 20 editable characters. >>> >>> via Smartphone >>> >>> >>> Am 21.04.2019 um 15:13 schrieb Travis McDugald via >>> ZendTo >: >>> >>> While no one has asked for this yet, I do see it?s >>> usefulness. >>> >>> I do use custom strings in email subjects for some >>> projects as well.? Helps with sorting, searching, >>> and filtering. >>> >>> Side note: great job on everything Jules, thank you. >>> >>> Sent from my iPad >>> >>> >>> On Apr 21, 2019, at 7:40 AM, Jules via ZendTo >>> > wrote: >>> >>> Peter, >>> >>> You effectively just want to allow senders to >>> customise the "[ZENDTO]" subject line tag in >>> each drop-off, correct? >>> >>> Does anyone else need to do this too? >>> >>> Cheers, >>> Jules. >>> >>> On 21/02/2019 2:21 pm, Der PCFreak via ZendTo wrote: >>> >>> Hi Jules, hi all. >>> >>> I have a strange request from our ZendTo >>> users. They asked if it would be possible to >>> add a custom field when sending a DropOff >>> that results in a custom text in all ZendTo >>> email concerning this specific DropOff. >>> >>> Example current: >>> >>> [ZENDTO] One of the recipients has picked up >>> your drop-off! >>> >>> Example requested: >>> >>> [ZENDTO] CUSTOM_STRING One of the recipients >>> has picked up your drop-off! >>> >>> I asked a little bit about the purpose of >>> their request and they told me that project >>> teams sort their email by subject and >>> consequently keep the project name >>> (CUSTOM_STRING) in every subject of their >>> emails concerning that specific project. >>> So later they could sort by project name >>> (CUSTOM_STRING) within Outlook to be able to >>> verify when they sent a specific DropOff. >>> >>> Question: >>> Is it possible to implement such a feature? >>> >>> I know that I could handcraft it but I don't >>> want to make big changes to the source and >>> always have to keep track of them when >>> upgrading. >>> >>> I am currently not on the latest version of >>> ZendTo, so if such a feature is maybe >>> already present in the latest version, feel >>> free >>> to tell me. >>> >>> Thanks in advance. >>> >>> Peter >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Once is happenstance, twice is coincidence, three times is enemy >>> >>> action.' - Ian Fleming >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Find a place inside where there's joy, and the joy will burn out >>> >>> the pain.' - Joseph Campbell >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'Making machines do what you want requires only two qualities: >> 1) Being slightly more stubborn that the computer, & >> 2) Remembering that computers are electrified rocks.' - @JediJeremy >> >> www.Zend.To >> Twitter: @JulesFM > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'In Flanders fields the poppies blow > Between the crosses, row on row, > That mark our place: and in the sky > The larks still bravely singing fly > Scarce heard amid the guns below. > > We are the dead: Short days ago, > We lived, felt dawn, saw sunset glow, > Loved and were loved: and now we lie > In Flanders fields! > > Take up our quarrel with the foe > To you, from failing hands, we throw > The torch: be yours to hold it high > If ye break faith with us who die, > We shall not sleep, though poppies grow > In Flanders fields.' Lieutenant Colonel John McCrae > > Composed at the battlefront on May 3, 1915 > during the second battle of Ypres, Belgium > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'A committee is a group of the unwilling, chosen from the unfit, to do the unnecessary.' - Anon www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jun 20 16:53:50 2020 From: Jules at Zend.To (Jules) Date: Sat, 20 Jun 2020 16:53:50 +0100 Subject: [ZendTo] Feature Request custom string in subject per DropOff In-Reply-To: References: <72d61410dcb94e67a16481300a961282@City-Exch-DB1.cbj.local> <19accbbc-b2b1-241d-531d-a717fc8dc15a@Zend.To> <736600cebd8d4738999450bcac9783c1@City-Exch-DB1.cbj.local> <94ab92e3-d096-3c7d-a386-317df54a3525@Zend.To> Message-ID: Gregg, I have added that. It will be in 6.02-2 which I'll probably release tomorrow. I have also added the column visibility toggles to the user's Inbox and Outbox view too. Previously they were only on the admin's "Global List of Drop-offs" page. Next thing for those pages will be a CSV export of some sort, but I've got to find a decent way of doing it first without DataTable's ugly buttons. If there are any examples of using "autolist | jq" to do any useful queries, to add some examples to the autolist documentation, please do let me know! "jq" isn't the most obvious syntax in the world. Cheers, Jules. On 20/06/2020 13:30, Gregg Douglas via ZendTo wrote: > Hi, > > Great new feature, can the autolist be updated to include searching > using this new field? > > Regards > Gregg > > > On Fri, Jun 19, 2020 at 6:23 PM Jules via ZendTo > wrote: > > Folks, > > This feature is now in the latest beta release, 6.02-1 which is > available from the beta page on the website at > https://zend.to/beta > > When you create a new drop-off, the Subject line is shown next to > the "From". > *You can edit the Subject how you like. > > *The "EmailSubjectTag" from zendto.conf will still be added onto > the start of the Subject before the emails are actually sent. > If you would prefer that the EmailSubjectTag was included in the > editable bit, so you can remove it, let me know. > > This has involved quite a major change in the HTML structure of > the form, so if you see browsers where it doesn't display > perfectly, please do tell me! > > Thanks! > Jules. > > On 01/05/2019 10:03, Jules Field wrote: >> >> >> On 30/04/2019 23:42, Kevin Miller via ZendTo wrote: >>> >>> I was thinking of something sort of along the lines of what >>> Travis McDugald proposed: >>> >>> ? If (isset($messageID)) then $subject = [Zendto] . $messageID . >>> $subject; else $subject = [Zendto] . $subject; >>> >>> although rather than an additional messageID I was envisioning >>> just changing the prefix. >>> >> I am wary of allowing things like ticket numbers in the [] >> prefix, as I bet some lousy ticketing systems out there will only >> spot the ticket number if it has whitespace after it and not some >> bracket or other punctuation. >> >>> I.e. I was thinking that [Zendto] would be a variable set in >>> preferneces.php which could be customized. Something like: >>> >>> ?Zendto_prefix? => ?[Zendto]?, >>> >>> which folks could simply change to what they wanted or leave it >>> as the default.? I didn?t really explain it very clearly. >>> >>> We?re probably the outlier, but the powers that be upstream of >>> me decided we?d call our system ?fileshare? rather than Zendto.? >>> So in my case I?d change the prefix itself if such was >>> available.? I can see the use case for what Travis, et. al. are >>> proposing as well? >>> >> Greg has already answered that one for me. :-) >> >> Cheers, >> Jules. >> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User >>> No: 307357 >>> >>> *From:*ZendTo >>> *On Behalf Of *Jules Field via >>> ZendTo >>> *Sent:* Tuesday, April 30, 2019 12:35 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field ; Kevin >>> Miller >>> *Subject:* Re: [ZendTo] [Feature Request custom string in >>> subject per DropOff] >>> >>> Kevin, >>> >>> But in the case of a request, as much as possible is pre-filled >>> for the customer dropping off files. >>> All the other Subject lines generated are hard-coded (apart from >>> translations). >>> >>> If you are thinking of either changing the [ZendTo] prefix to >>> some other string, or adding something between the [ZendTo] >>> prefix and the rest of the string, where and when is that going >>> to be set? >>> >>> The "new dropoff" form needs to gain an extra "Message ID" (or >>> whatever) box so people can put in their magic string. >>> >>> Are you saying the "send a request" form needs to gain it too? >>> (And presumably if the answer to that is "yes", the "new >>> dropoff" form would pre-fill the "Message ID" value from what >>> was given in the request. And if that is the case, should the >>> customer doing the dropoff be able to change the "Message ID" >>> value at that point? I would suggest not.) >>> >>> I think we're all thinking about variations on either ticketing >>> systems or people with multiple projects, where they need some >>> magic value in the Subject line of *every* email message sent by >>> ZendTo so that they can all be tracked and filed automatically. >>> >>> Cheers, >>> Jules. >>> >>> On 29/04/2019 17:53, Kevin Miller via ZendTo wrote: >>> >>> Unless I?m misunderstand the conundrum, I?d say to let the >>> requester enter the subject line, sans prefix, then prepend >>> the system defined prefix at upload generation time.? I.e., >>> if I was requesting a dropoff I?d put in ?My appropriate >>> subject?.? The person that is actually doing the dropoff >>> would see that, and probably won?t think twice about it.? >>> Then, when the outgoing upload ?notification is actually >>> complete, Zendto can prepend the system supplied prefix >>> [Zendto] or [Whatever] and send that.? I don?t think folks >>> are in the habit of hand coding prefixes, so it?s unlikely >>> one would end up with dual prefixes. >>> >>> Maybe there?s coding issues with that that make it >>> difficult?? Anyway, my tuppence worth? >>> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux >>> User No: 307357 >>> >>> *From:*ZendTo >>> *On Behalf Of *Jules Field >>> via ZendTo >>> *Sent:* Monday, April 29, 2019 6:19 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field >>> *Subject:* Re: [ZendTo] [Feature Request custom string in >>> subject per DropOff] >>> >>> Folks, >>> >>> I'm having a think about this one. >>> >>> The idea of the prefix is pretty simple, basically I would >>> give you the "[ZendTo]" string (as an initial default value) >>> in a "Subject" box in the new drop-off form. >>> >>> Whatever you end up putting in there gets used instead of >>> [ZendTo] at the start of the email subject lines. >>> >>> However...... >>> >>> If you request a drop-off, you get to supply the whole >>> Subject line for the email to the person you want to send >>> you their files. >>> Ideally, that same Subject line would be used in all >>> notifications etc about that drop-off. >>> But they have entered the *whole* Subject line, not just the >>> prefix to it. >>> If I use their whole Subject line as a prefix, it's going to >>> look weird. >>> >>> So what do I do for the Subject prefix, when it was created >>> as a result of a request which had the entire Subject line >>> supplied? >>> I clearly can't ask the person sending the request to supply >>> 2 Subject entries ? both the current whole Subject line >>> *and* the prefix to use ? as that would confuse the hell out >>> of them. >>> >>> Any ideas please? >>> >>> Cheers, >>> Jules. >>> >>> On 21/04/2019 14:29, Mailing Lists via ZendTo wrote: >>> >>> Hi Jules, >>> >>> yes it would be enough to allow 20 editable characters. >>> >>> via Smartphone >>> >>> >>> Am 21.04.2019 um 15:13 schrieb Travis McDugald via >>> ZendTo >: >>> >>> While no one has asked for this yet, I do see it?s >>> usefulness. >>> >>> I do use custom strings in email subjects for some >>> projects as well.? Helps with sorting, searching, >>> and filtering. >>> >>> Side note: great job on everything Jules, thank you. >>> >>> Sent from my iPad >>> >>> >>> On Apr 21, 2019, at 7:40 AM, Jules via ZendTo >>> > wrote: >>> >>> Peter, >>> >>> You effectively just want to allow senders to >>> customise the "[ZENDTO]" subject line tag in >>> each drop-off, correct? >>> >>> Does anyone else need to do this too? >>> >>> Cheers, >>> Jules. >>> >>> On 21/02/2019 2:21 pm, Der PCFreak via ZendTo wrote: >>> >>> Hi Jules, hi all. >>> >>> I have a strange request from our ZendTo >>> users. They asked if it would be possible to >>> add a custom field when sending a DropOff >>> that results in a custom text in all ZendTo >>> email concerning this specific DropOff. >>> >>> Example current: >>> >>> [ZENDTO] One of the recipients has picked up >>> your drop-off! >>> >>> Example requested: >>> >>> [ZENDTO] CUSTOM_STRING One of the recipients >>> has picked up your drop-off! >>> >>> I asked a little bit about the purpose of >>> their request and they told me that project >>> teams sort their email by subject and >>> consequently keep the project name >>> (CUSTOM_STRING) in every subject of their >>> emails concerning that specific project. >>> So later they could sort by project name >>> (CUSTOM_STRING) within Outlook to be able to >>> verify when they sent a specific DropOff. >>> >>> Question: >>> Is it possible to implement such a feature? >>> >>> I know that I could handcraft it but I don't >>> want to make big changes to the source and >>> always have to keep track of them when >>> upgrading. >>> >>> I am currently not on the latest version of >>> ZendTo, so if such a feature is maybe >>> already present in the latest version, feel >>> free >>> to tell me. >>> >>> Thanks in advance. >>> >>> Peter >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Once is happenstance, twice is coincidence, three times is enemy >>> >>> action.' - Ian Fleming >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Find a place inside where there's joy, and the joy will burn out >>> >>> the pain.' - Joseph Campbell >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> Jules >>> >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait >>> >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'Making machines do what you want requires only two qualities: >> 1) Being slightly more stubborn that the computer, & >> 2) Remembering that computers are electrified rocks.' - @JediJeremy >> >> www.Zend.To >> Twitter: @JulesFM > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'In Flanders fields the poppies blow > Between the crosses, row on row, > That mark our place: and in the sky > The larks still bravely singing fly > Scarce heard amid the guns below. > > We are the dead: Short days ago, > We lived, felt dawn, saw sunset glow, > Loved and were loved: and now we lie > In Flanders fields! > > Take up our quarrel with the foe > To you, from failing hands, we throw > The torch: be yours to hold it high > If ye break faith with us who die, > We shall not sleep, though poppies grow > In Flanders fields.' Lieutenant Colonel John McCrae > > Composed at the battlefront on May 3, 1915 > during the second battle of Ypres, Belgium > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Forties, Cromarty, Forth, Tyne, Dogger: Southwest 3 or 4, backing southeast 5 or 6. Slight, becoming moderate later. Mainly fair. Good, occasionally poor at first in Cromarty. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sun Jun 21 17:55:01 2020 From: Jules at Zend.To (Jules) Date: Sun, 21 Jun 2020 17:55:01 +0100 Subject: [ZendTo] New beta 6.02-2 released Message-ID: Folks, There is now an "Export as CSV" button on each of the Inbox, Outbox and "Global list of all drop-offs" page. All 3 pages now have a feature where you can show/hide each column. I'm afraid the "Export as CSV" button exports all columns, not just the visible ones. Sorry about that. This has involved a fair amount of CSS changes, and some HTML changes too. So please can you test it all looks okay on your favourite browser? Thanks! Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'There is silent poetry in the stillness of morning; in the calm, the cries & sighs of life sound like gentle music.' - @Astro_Wheels www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at pcfreak.de Tue Jun 23 07:30:45 2020 From: mailinglists at pcfreak.de (Der PCFreak) Date: Tue, 23 Jun 2020 08:30:45 +0200 Subject: [ZendTo] Feature Request custom string in subject per DropOff In-Reply-To: References: <72d61410dcb94e67a16481300a961282@City-Exch-DB1.cbj.local> <19accbbc-b2b1-241d-531d-a717fc8dc15a@Zend.To> <736600cebd8d4738999450bcac9783c1@City-Exch-DB1.cbj.local> <94ab92e3-d096-3c7d-a386-317df54a3525@Zend.To> <28165103-9fba-86c3-c9aa-557e3d64ece1@pcfreak.de> Message-ID: Hi, wonderful! Thank you Jules! Peter On 19/06/2020 18:22, Jules via ZendTo wrote: > Folks, > > This feature is now in the latest beta release, 6.02-1 which is > available from the beta page on the website at > https://zend.to/beta > > When you create a new drop-off, the Subject line is shown next to the > "From". > *You can edit the Subject how you like. > > *The "EmailSubjectTag" from zendto.conf will still be added onto the > start of the Subject before the emails are actually sent. > If you would prefer that the EmailSubjectTag was included in the > editable bit, so you can remove it, let me know. > > This has involved quite a major change in the HTML structure of the > form, so if you see browsers where it doesn't display perfectly, > please do tell me! > > Thanks! > Jules. > > On 01/05/2019 10:03, Jules Field wrote: >> >> >> On 30/04/2019 23:42, Kevin Miller via ZendTo wrote: >>> >>> I was thinking of something sort of along the lines of what Travis >>> McDugald proposed: >>> >>> ? If (isset($messageID)) then $subject = [Zendto] . $messageID . >>> $subject; else $subject = [Zendto] . $subject; >>> >>> although rather than an additional messageID I was envisioning just >>> changing the prefix. >>> >> I am wary of allowing things like ticket numbers in the [] prefix, as >> I bet some lousy ticketing systems out there will only spot the >> ticket number if it has whitespace after it and not some bracket or >> other punctuation. >> >>> I.e. I was thinking that [Zendto] would be a variable set in >>> preferneces.php which could be customized.? Something like: >>> >>> ?Zendto_prefix? => ?[Zendto]?, >>> >>> which folks could simply change to what they wanted or leave it as >>> the default.? I didn?t really explain it very clearly. >>> >>> We?re probably the outlier, but the powers that be upstream of me >>> decided we?d call our system ?fileshare? rather than Zendto.? So in >>> my case I?d change the prefix itself if such was available.? I can >>> see the use case for what Travis, et. al. are proposing as well? >>> >> Greg has already answered that one for me. :-) >> >> Cheers, >> Jules. >> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: >>> 307357 >>> >>> *From:*ZendTo *On Behalf Of *Jules Field >>> via ZendTo >>> *Sent:* Tuesday, April 30, 2019 12:35 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field ; Kevin Miller >>> >>> *Subject:* Re: [ZendTo] [Feature Request custom string in subject >>> per DropOff] >>> >>> Kevin, >>> >>> But in the case of a request, as much as possible is pre-filled for >>> the customer dropping off files. >>> All the other Subject lines generated are hard-coded (apart from >>> translations). >>> >>> If you are thinking of either changing the [ZendTo] prefix to some >>> other string, or adding something between the [ZendTo] prefix and >>> the rest of the string, where and when is that going to be set? >>> >>> The "new dropoff" form needs to gain an extra "Message ID" (or >>> whatever) box so people can put in their magic string. >>> >>> Are you saying the "send a request" form needs to gain it too? >>> (And presumably if the answer to that is "yes", the "new dropoff" >>> form would pre-fill the "Message ID" value from what was given in >>> the request. And if that is the case, should the customer doing the >>> dropoff be able to change the "Message ID" value at that point? I >>> would suggest not.) >>> >>> I think we're all thinking about variations on either ticketing >>> systems or people with multiple projects, where they need some magic >>> value in the Subject line of *every* email message sent by ZendTo so >>> that they can all be tracked and filed automatically. >>> >>> Cheers, >>> Jules. >>> >>> On 29/04/2019 17:53, Kevin Miller via ZendTo wrote: >>> >>> Unless I?m misunderstand the conundrum, I?d say to let the >>> requester enter the subject line, sans prefix, then prepend the >>> system defined prefix at upload generation time.? I.e., if I was >>> requesting a dropoff I?d put in ?My appropriate subject?.? The >>> person that is actually doing the dropoff would see that, and >>> probably won?t think twice about it.? Then, when the outgoing >>> upload ?notification is actually complete, Zendto can prepend >>> the system supplied prefix [Zendto] or [Whatever] and send >>> that.? I don?t think folks are in the habit of hand coding >>> prefixes, so it?s unlikely one would end up with dual prefixes. >>> >>> Maybe there?s coding issues with that that make it difficult?? >>> Anyway, my tuppence worth? >>> >>> ...Kevin >>> >>> -- >>> >>> Kevin Miller >>> >>> Network/email Administrator, CBJ MIS Dept. >>> >>> 155 South Seward Street >>> >>> Juneau, Alaska 99801 >>> >>> Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User >>> No: 307357 >>> >>> *From:*ZendTo >>> *On Behalf Of *Jules Field via ZendTo >>> *Sent:* Monday, April 29, 2019 6:19 AM >>> *To:* ZendTo Users >>> *Cc:* Jules Field >>> *Subject:* Re: [ZendTo] [Feature Request custom string in >>> subject per DropOff] >>> >>> Folks, >>> >>> I'm having a think about this one. >>> >>> The idea of the prefix is pretty simple, basically I would give >>> you the "[ZendTo]" string (as an initial default value) in a >>> "Subject" box in the new drop-off form. >>> >>> Whatever you end up putting in there gets used instead of >>> [ZendTo] at the start of the email subject lines. >>> >>> However...... >>> >>> If you request a drop-off, you get to supply the whole Subject >>> line for the email to the person you want to send you their files. >>> Ideally, that same Subject line would be used in all >>> notifications etc about that drop-off. >>> But they have entered the *whole* Subject line, not just the >>> prefix to it. >>> If I use their whole Subject line as a prefix, it's going to >>> look weird. >>> >>> So what do I do for the Subject prefix, when it was created as a >>> result of a request which had the entire Subject line supplied? >>> I clearly can't ask the person sending the request to supply 2 >>> Subject entries ? both the current whole Subject line *and* the >>> prefix to use ? as that would confuse the hell out of them. >>> >>> Any ideas please? >>> >>> Cheers, >>> Jules. >>> >>> On 21/04/2019 14:29, Mailing Lists via ZendTo wrote: >>> >>> Hi Jules, >>> >>> yes it would be enough to allow 20 editable characters. >>> >>> via Smartphone >>> >>> >>> Am 21.04.2019 um 15:13 schrieb Travis McDugald via ZendTo >>> >: >>> >>> While no one has asked for this yet, I do see it?s >>> usefulness. >>> >>> I do use custom strings in email subjects for some >>> projects as well. ?Helps with sorting, searching, and >>> filtering. >>> >>> Side note: great job on everything Jules, thank you. >>> >>> Sent from my iPad >>> >>> >>> On Apr 21, 2019, at 7:40 AM, Jules via ZendTo >>> > wrote: >>> >>> Peter, >>> >>> You effectively just want to allow senders to >>> customise the "[ZENDTO]" subject line tag in each >>> drop-off, correct? >>> >>> Does anyone else need to do this too? >>> >>> Cheers, >>> Jules. >>> >>> On 21/02/2019 2:21 pm, Der PCFreak via ZendTo wrote: >>> >>> Hi Jules, hi all. >>> >>> I have a strange request from our ZendTo users. >>> They asked if it would be possible to add a >>> custom field when sending a DropOff >>> that results in a custom text in all ZendTo >>> email concerning this specific DropOff. >>> >>> Example current: >>> >>> [ZENDTO] One of the recipients has picked up >>> your drop-off! >>> >>> Example requested: >>> >>> [ZENDTO] CUSTOM_STRING One of the recipients has >>> picked up your drop-off! >>> >>> I asked a little bit about the purpose of their >>> request and they told me that project teams sort >>> their email by subject and >>> consequently keep the project name >>> (CUSTOM_STRING) in every subject of their emails >>> concerning that specific project. >>> So later they could sort by project name >>> (CUSTOM_STRING) within Outlook to be able to >>> verify when they sent a specific DropOff. >>> >>> Question: >>> Is it possible to implement such a feature? >>> >>> I know that I could handcraft it but I don't >>> want to make big changes to the source and >>> always have to keep track of them when upgrading. >>> >>> I am currently not on the latest version of >>> ZendTo, so if such a feature is maybe already >>> present in the latest version, feel free >>> to tell me. >>> >>> Thanks in advance. >>> >>> Peter >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Once is happenstance, twice is coincidence, three times is enemy >>> >>> action.' - Ian Fleming >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> >>> Jules >>> >>> >>> >>> -- >>> >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> >>> >>> >>> 'Find a place inside where there's joy, and the joy will burn out >>> >>> the pain.' - Joseph Campbell >>> >>> >>> >>> www.Zend.To >>> >>> Twitter: @JulesFM >>> >>> >>> >>> _______________________________________________ >>> >>> ZendTo mailing list >>> >>> ZendTo at zend.to >>> >>> http://jul.es/mailman/listinfo/zendto >>> >>> >>> >>> Jules >>> -- >>> Julian Field MEng CEng CITP MBCS MIEEE MACM >>> 'Teach a man to reason, and he will think for a lifetime.' - Phil Plait >>> www.Zend.To >>> Twitter: @JulesFM >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'Making machines do what you want requires only two qualities: >> 1) Being slightly more stubborn that the computer, & >> 2) Remembering that computers are electrified rocks.' - @JediJeremy >> >> www.Zend.To >> Twitter: @JulesFM > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'In Flanders fields the poppies blow > Between the crosses, row on row, > That mark our place: and in the sky > The larks still bravely singing fly > Scarce heard amid the guns below. > > We are the dead: Short days ago, > We lived, felt dawn, saw sunset glow, > Loved and were loved: and now we lie > In Flanders fields! > > Take up our quarrel with the foe > To you, from failing hands, we throw > The torch: be yours to hold it high > If ye break faith with us who die, > We shall not sleep, though poppies grow > In Flanders fields.' Lieutenant Colonel John McCrae > > Composed at the battlefront on May 3, 1915 > during the second battle of Ypres, Belgium > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jun 23 17:48:51 2020 From: Jules at Zend.To (Jules) Date: Tue, 23 Jun 2020 17:48:51 +0100 Subject: [ZendTo] Speeding up Apache Message-ID: Folks, I've been working on some instructions to speed up Apache (and hopefully reduce its memory usage) by switching from the "prefork" model to the "worker" model, and using php-fpm instead of mod_php. I haven't got any ZendTo sites where the load difference would be very noticeable, but I suspect some of you do. I've worked out how to do it on Ubuntu/Debian (hopefully most recent versions!) and on CentOS/RedHat 7. If I write up the instructions as a couple of "How To" guides on the website, would you like to try them out? It's pretty straightforward, you don't need to know anything much about how Apache works. But the changes will affect *all* websites on the server/VM that runs your ZendTo site. So if you're sharing the server/VM between multiple services, tread carefully. Cheers, Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Thames, Dover, Wight, Portland, Plymouth: East or northeast 3 to 5. Smooth or slight at first in Thames and Dover, otherwise mainly slight or moderate, becoming rough later in west Plymouth. Fair. Good. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Tue Jun 23 18:16:27 2020 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 23 Jun 2020 09:16:27 -0800 Subject: [ZendTo] Speeding up Apache In-Reply-To: References: <0b49e871-73f2-daa6-b39c-0407709dd069@alaska.gov> Message-ID: On 6/23/2020 8:48 AM, Jules via ZendTo wrote: > I've been working on some instructions to speed up Apache (and hopefully > reduce its memory usage) by switching from the "prefork" model to the > "worker" model, and using php-fpm instead of mod_php. I hope this will be an option, rather than a straight-up change. It is my experience, albeit several years old, that gains from switching Apache to the threaded-handler ("worker") were strongly architecture-dependent. Our SPARC servers with +100 thread-handlers were screaming-fast with the threaded-handler. Our quad-core Intel servers performed no better with the "worker" than with the "prefork" handler. I have no idea how VMware (or other virtual server platforms) will affect this calculus. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska From Jules at Zend.To Wed Jun 24 09:57:10 2020 From: Jules at Zend.To (Jules) Date: Wed, 24 Jun 2020 09:57:10 +0100 Subject: [ZendTo] Speeding up Apache In-Reply-To: References: <0b49e871-73f2-daa6-b39c-0407709dd069@alaska.gov> Message-ID: <7bc9b69b-8b46-3a02-14e9-3ff4f5d4fd64@Zend.To> John, I was just going to publish it as guides on the website. I have no great intention to change the ZendTo Installer to the php-fpm model. I would need a lot more evidence from ZendTo site admins (i.e. you folks!) before I considered changing the Installer. How might we benchmark ZendTo to see the difference on various platforms? Cheers, Jules. On 23/06/2020 18:16, John Thurston via ZendTo wrote: > > On 6/23/2020 8:48 AM, Jules via ZendTo wrote: >> I've been working on some instructions to speed up Apache (and >> hopefully reduce its memory usage) by switching from the "prefork" >> model to the "worker" model, and using php-fpm instead of mod_php. > > I hope this will be an option, rather than a straight-up change. It is > my experience, albeit several years old, that gains from switching > Apache to the threaded-handler ("worker") were strongly > architecture-dependent. > > Our SPARC servers with +100 thread-handlers were screaming-fast with > the threaded-handler. Our quad-core Intel servers performed no better > with the "worker" than with the "prefork" handler. I have no idea how > VMware (or other virtual server platforms) will affect this calculus. > > > > -- > Do things because you should, not just because you can. > > John Thurston??? 907-465-8591 > John.Thurston at alaska.gov > Department of Administration > State of Alaska > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'All programs have a desire to be useful' - Tron, 1982 www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jun 24 14:46:31 2020 From: Jules at Zend.To (Jules) Date: Wed, 24 Jun 2020 14:46:31 +0100 Subject: [ZendTo] Speeding up Apache In-Reply-To: References: Message-ID: <7200f46f-4167-136a-fbc7-8d1d5dfe4777@Zend.To> Folks, If you take a look at ??? zend.to/phpfpm you will find my simple step-by-step guides for switching Apache to what may be a faster load-handling model on your system, and switching PHP over to php-fpm instead of the older mod_php. The steps are as short and simple as I think I can make them! Cheers, Jules. On 23/06/2020 17:48, Jules via ZendTo wrote: > Folks, > > I've been working on some instructions to speed up Apache (and > hopefully reduce its memory usage) by switching from the "prefork" > model to the "worker" model, and using php-fpm instead of mod_php. > > I haven't got any ZendTo sites where the load difference would be very > noticeable, but I suspect some of you do. > I've worked out how to do it on Ubuntu/Debian (hopefully most recent > versions!) and on CentOS/RedHat 7. > > If I write up the instructions as a couple of "How To" guides on the > website, would you like to try them out? > > It's pretty straightforward, you don't need to know anything much > about how Apache works. But the changes will affect *all* websites on > the server/VM that runs your ZendTo site. So if you're sharing the > server/VM between multiple services, tread carefully. > > Cheers, > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > The current UK shipping forecast: > Thames, Dover, Wight, Portland, Plymouth: East or northeast 3 to 5. Smooth or > slight at first in Thames and Dover, otherwise mainly slight or moderate, > becoming rough later in west Plymouth. Fair. Good. > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Adversity is like a strong wind. I don't mean just that it holds us back from places we might otherwise go. It also tears away from us all but the things that cannot be torn, so that afterward we see ourselves as we really are, and not merely as we might like to be.' - Arthur Golden www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Jun 25 16:05:22 2020 From: Jules at Zend.To (Jules) Date: Thu, 25 Jun 2020 16:05:22 +0100 Subject: [ZendTo] Final beta -- please test pages look okay Message-ID: <9e637d8b-fedf-436f-cbf4-aa192d0b0afc@Zend.To> People, I have just released 6.02-4 which will hopefully be the last beta before a new production release. The main new features are ??? - You can edit the "Subject:" line of new drop-offs ??? - You can export Inbox / Outbox / Global list of drop-offs to a CSV file ??? - You can choose what columns you want to see (and export) in those 3 lists of drop-offs Download from ??? zend.to/beta The code itself all appears to work fine. But I have had to do some fairly major tweaks to the "New Drop-off" form, as well as the Inbox / Outbox / Global list of drop-offs pages. So please can you just load them in different browsers on different platforms and check they all look okay? I've tested it fairly thoroughly (and IE is 1 pixel out, but I can't fix that), but a quick check on your own client browsers would be much appreciated. Thanks! Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'When I read Shakespeare I am struck with wonder That such trivial people should muse and thunder In such lovely language.' - D.H. Lawrence www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jun 30 16:41:32 2020 From: Jules at Zend.To (Jules) Date: Tue, 30 Jun 2020 16:41:32 +0100 Subject: [ZendTo] ANNOUNCE: ZendTo 6.03-1 production release Message-ID: <09ef52eb-b22a-e69e-249e-b8af706f0b84@Zend.To> Hi all! I have just made a new "production" release, version 6.03-1. The new features in this release are: * Users can now edit the Subject line of a new drop-off, to add project names or ticket numbers. * "Export as CSV" button added to Inbox, Outbox and "Global List of Drop-offs" pages. It exports the visible columns. * Those same pages now have toggles to show/hide each column, and one for all columns. - Improved logging of failed attempts to login to admin accounts. - "adduser" checks for "<" and ">" in usernames typed by people taking the syntax guidance too literally. - "autolist" improved to include pick-up information. - Bug fixed where incorrect expiry times were shown in reminder emails. Existing users can just upgrade using ??? sudo apt update ??? sudo apt upgrade zendto or ??? yum upgrade zendto depending on your flavour of Linux. New sites should use the ZendTo Installer, as described at ??? zend.to/downloads Any problems, questions, issues or comments are always welcome! Cheers, Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Making machines do what you want requires only two qualities: 1) Being slightly more stubborn that the computer, & 2) Remembering that computers are electrified rocks.' - @JediJeremy www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From KLE at msktd.com Tue Jun 30 21:53:21 2020 From: KLE at msktd.com (Ken Etter) Date: Tue, 30 Jun 2020 16:53:21 -0400 Subject: [ZendTo] ANNOUNCE: ZendTo 6.03-1 production release In-Reply-To: References: <09ef52eb-b22a-e69e-249e-b8af706f0b84@Zend.To> <5EFBA641020000130014590A@mail.msktd.com> Message-ID: Jules, Just an FYI for anyone use SLES (this may also be applicable to OpenSUSE). The upgrade command I use is "zypper update zendto" followed by running your script "/opt/zendto/bin/upgrade". Ken >>> Jules via ZendTo 6/30/2020 11:41 AM >>> Hi all! I have just made a new "production" release, version 6.03-1. The new features in this release are: * Users can now edit the Subject line of a new drop-off, to add project names or ticket numbers. * "Export as CSV" button added to Inbox, Outbox and "Global List of Drop-offs" pages. It exports the visible columns. * Those same pages now have toggles to show/hide each column, and one for all columns. - Improved logging of failed attempts to login to admin accounts. - "adduser" checks for "<" and ">" in usernames typed by people taking the syntax guidance too literally. - "autolist" improved to include pick-up information. - Bug fixed where incorrect expiry times were shown in reminder emails. Existing users can just upgrade using sudo apt update sudo apt upgrade zendto or yum upgrade zendto depending on your flavour of Linux. New sites should use the ZendTo Installer, as described at zend.to/downloads Any problems, questions, issues or comments are always welcome! Cheers, Jules-- Julian Field MEng CEng CITP MBCS MIEEE MACM'Making machines do what you want requires only two qualities: 1) Being slightly more stubborn that the computer, & 2) Remembering that computers are electrified rocks.' - @JediJeremywww.Zend.ToTwitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: