[ZendTo] 4.20-3 bug-fix release

Tue Jan 31 10:40:22 GMT 2017

Peter,

In-line comments below...

On 31/01/2017 09:56, Der PCFreak wrote:
> Hi Jules,
>
> many thanks for your work!
>
> Today I tried an update (cloned virtual machine) to the latest version
> on my 3 year old installation.
> My OS is CentOS6 (it was one of the downloadable preconfigured vms that
> were available some day from zendto homepage) with all available updates
> applied.
>
> First of all it worked quite well but I want to share my findings to
> maybe help others.
>
> # yum update (I was updating from 4.12-5.noarch)
> worked but gave the following warnings:
>
> warning: /opt/zendto/config/preferences.php created as
> /opt/zendto/config/preferences.php.rpmnew
> warning: /opt/zendto/config/zendto.conf created as
> /opt/zendto/config/zendto.conf.rpmnew
Those are entirely expected, as you noted below.
> warning: /opt/zendto/templates/about.tpl created as
> /opt/zendto/templates/about.tpl.rpmnew
> warning: /opt/zendto/templates/login.tpl created as
> /opt/zendto/templates/login.tpl.rpmnew
> warning: /opt/zendto/templates/new_dropoff.tpl created as
> /opt/zendto/templates/new_dropoff.tpl.rpmnew
See below.
>
> warning:    erase unlink of
> /opt/zendto/templates_c/This.Dir.Must.Be.Writeable.By.Apache failed: No
> such file or directory
> warning:    erase unlink of /opt/zendto/templates_c failed: No such file
> or directory
> warning:    erase unlink of
> /opt/zendto/myzendto.templates_c/This.Dir.Must.Be.Writeable.By.Apache
> failed: No such file or directory
> warning:    erase unlink of /opt/zendto/myzendto.templates_c failed: No
> such file or directory
> warning:    erase unlink of
> /opt/zendto/cache/This.Dir.Must.Be.Writeable.By.Apache failed: No such
> file or directory
> warning:    erase unlink of /opt/zendto/cache failed: No such file or
> directory
These are caused because I've moved the directories that need to be 
writable out of /opt/zendto into /var/zendto where they belong much 
better. /opt/zendto can now be totally read-only as far as the web 
server is concerned, which simplifies the SELinux configuration quite a 
lot. The "This.Dir.Must.Be.Writeable.By.Apache" files were created by 
the old post-install script in the RPM file, so the removal of them is a 
bit ugly in this version. Unfortunately there's not a whole lot I can do 
about that now, I should have thought better about what went where years 
ago. Isn't hindsight wonderful? :-)
>
> The ones about .rpmnew were normal and I diffed them all against my
> current configuration. It was a bit of work but no problem.
> One difference that came up was a missing "c" in line 57 of about.tpl.
> The only difference is this missing "c" (omputer -> computer) and this
> resulted in the .rpmnew. As far as I remember this typo was already in
> the previous releases. So if you could fix it, it might help all that
> already fixed the typo and all updaters will receive a corrected version.
I've just fixed that typo, many thanks!
>
> Another thing I changed (for security reasons) was in login.tpl
> I changed:
>         <td align="right"><b>Your password:</b></td>
>         <td><input type="password" id="passwordField" name="password"
> size="15" value=""/></td>
> to:
>         <td align="right"><b>Your Password:</b></td>
>         <td><input type="password" id="passwordField" name="password"
> size="15" value="" autocomplete="off"/></td>
>
> to avoid autocomplete for the password field. This is came up one day in
> the mailing list and for security reasons I thought I will disable
> autocomplete here.
That stops password managers from working properly. What some see as an 
improvement in security actually just results in users choosing a crappy 
password, as they can't have their password manager auto-fill something 
really long/random/secure. I discussed this with several of my 
colleagues who write web apps for a living, and they all agreed with me 
that stopping password managers is a very bad thing to do.

So personally, I would advise you revert the file to its original state 
(i.e. without the autocomplete=off bit).

>
> When trying the first dropoff I ran into the (known) error:
>       Fatal error: Call to undefined function mb_strimwidth() in
> /opt/zendto/lib/NSSDropoff.php on line 1332
> This could be easily fixed by installing "php-mbstring" and restarting
> Apache.
Yes, it now needs that extra PHP module on RedHat & CentOS (but not Ubuntu).
I've deliberately left out PHP from the "Requires" list for the ZendTo 
rpm, as otherwise the installer will end up wiping your old ZendTo 
installation off the face of the earth, if you run the "rebuild PHP" bit 
of it on a system that already has a working ZendTo on it. And you're 
going to need to do that when you update PHP.
And also, assuming you've rebuilt PHP, it has to be installed from your 
rebuilt set of PHP rpm files, so I can't "yum install" it and I don't 
know where your rebuild PHP rpms might happen to be.

What I could do, and hopefully will very soon, is put a little bit of 
code before the calls to mb_strimwidth that checks for the existence of 
the function, and produces a sane error message if it doesn't exist. 
It's just a call to function_exists("mb_strimwidth") and an "if" 
statement. :-)

I should have thought of that before! Thanks for the prompt on that 
one... :-)

>
> All my custom commands like 'dropls' to show current dropoffs from the
> command line also worked as before.
>
> I am not sure about the "erase unlink ..." warnings, but it seems, that
> my clone works and I will test a little bit and the update the live
> system with the same changes.
You no longer need
/opt/zendto/cache
/opt/zendto/templates_c
/opt/zendto/myzendto.templates_c
and those can be totally deleted. If you look in /var/zendto you should 
see their replacements.
>
> You mentioned that cleanup.php wasn't working in previous versions.
>
> Could you tell me how this daily job gets executed and how to verify it
> manually?
Via a tiny script /etc/cron.d/zendto which contains stuff automatically 
by cron.
To verify it manually, just take a look in that file and run the 
cleanup.php script without the redirects on the end, so something like 
this (as root):
/usr/bin/php /opt/zendto/sbin/cleanup.php /opt/zendto/config/preferences.php

>
> Thanks in advance and thanks for the wonderful product you created and
> your continous work to keep it up to date.
Glad you like it! (P.S. All donations welcome, there's usually something 
on my Amazon.co.uk wishlist :-)

Cheers,
Jules.

>
> Kind regards
>
> Peter
>
> On 30.01.2017 11:19, Jules wrote:
>> Folks,
>>
>> I discovered from reports that cleanup.php wasn't working at all. It's
>> run nightly to delete old drop-offs that have expired, and to send
>> warning emails to recipients that their dropoff is about to be deleted,
>> if no one has picked it up.
>>
>> This is now fixed.
>>
>> I have also changed how the IMAP authenticator works, so it should now
>> behave a lot better with Exchange and Office365 IMAP services.
>>
>> 4.20-3 is on the website and in the repositories.
>> Just do a
>>        yum upgrade zendto
>> or
>>        sudo apt-get upgrade zendto
>> to install it. There should be no need to restart any services at all.
>>
>> Cheers,
>>
>> Jules
>>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng MBCS CITP CEng

'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
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654