From Bryan.Jones at leesar.com Sun Jul 1 04:02:02 2018 From: Bryan.Jones at leesar.com (Bryan Jones) Date: Sun, 1 Jul 2018 03:02:02 +0000 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released References: <27144e54f2dc49859da6f86b795b5c2b@RSCEXDB01.leesar.com> Message-ID: I've identified a potential issue with the new file encryption function of 5.10-1. It is possible to deliver an encrypted file with a blank passphrase, that cannot be decrypted and downloaded by the recipient: Upon checking to box to "Encrypt every file", you're presented the dialog to provide a passphrase. It is possible to exit that box without supplying a passphrase. However the "Encrypt every file" option is still selected. At that point, you can upload files, and deliver them, and they are encrypted. Upon notification to the recipient, they see the file delivery, but upon attempting to download, they're prompted for a passphrase. However, no passphrase was originally supplied, and it is not possible to submit a blank passphrase. The files are therefore not retrievable. If the person dropping off the files exits the passphrase dialog box without supplying a passphrase, the "Encypt every file" selection should probably be reverted. This is an installation of 5.03-1 that was upgraded. -- Bryan Jones P.S. Love the tool... taking to my executive board of my non-profit on Monday for approval to deploy. We will be donating if this is accepted. Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sun Jul 1 12:11:41 2018 From: Jules at Zend.To (Jules) Date: Sun, 1 Jul 2018 12:11:41 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <27144e54f2dc49859da6f86b795b5c2b@RSCEXDB01.leesar.com> Message-ID: <8bfd6b43-fb25-2569-14a7-6b3659d6c0c1@Zend.To> Bryan, Check you /opt/zendto/templates directory for any *.rpmnew files. And make sure you have cleared your browser cache. It behaves correctly for me. (Feel free to try at https://dropoff.soton.ac.uk which I have just upgraded, you can send me a drop-off to Jules at ecs.soton.ac.uk if you like). If you exit the passphrase dialog without a non-empty passphrase, the tickbox should untick itself. Cheers, Jules. On 01/07/2018 4:02 am, Bryan Jones via ZendTo wrote: > I've identified a potential issue with the new file encryption > function of 5.10-1. > > It is possible to deliver an encrypted file with a blank passphrase, > that cannot be decrypted and downloaded by the recipient: > > Upon checking to box to "Encrypt every file", you're presented the > dialog to provide a passphrase. It is possible to exit that box > without supplying a passphrase. However the "Encrypt every file" > option is still selected. > At that point, you can upload files, and deliver them, and they are > encrypted. > Upon notification to the recipient, they see the file delivery, but > upon attempting to download, they're prompted for a passphrase. > However, no passphrase was originally supplied, and it is not possible > to submit a blank passphrase. > The files are therefore not retrievable. > > If the person dropping off the files exits the passphrase dialog box > without supplying a passphrase, the "Encypt every file" selection > should probably be reverted. > > This is an installation of 5.03-1 that was upgraded. > > -- > Bryan Jones > > P.S. Love the tool... taking to my executive board of my non-profit on > Monday for approval to deploy. We will be donating if this is accepted. > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and > others authorized to receive it. If you are not the recipient, you are > hereby notified that any disclosure, copying, distribution or taking > action in relation of the contents of this information is strictly > prohibited and may be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived. > > > > _______________________________________________ > 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kotuliak at gmail.com Sun Jul 1 15:02:12 2018 From: martin.kotuliak at gmail.com (Martin Kotuliak) Date: Sun, 01 Jul 2018 16:02:12 +0200 Subject: [ZendTo] Propblem uploading a file References: <1530453732.3113.153.camel@okto.kalm.sk> Message-ID: I have problems with some files, for example this one: https://drive.google.com/file/d/1mo2Fuww8HcjrCaZRWnfIEkerjDmTLH9H/view?usp=sharing After the uploading zendto shows only this: https://drive.google.com/file/d/1rFDGnLtO5r-vb8sS2dD2hHxAluF05v8W/view?usp=sharing I tried it on 5.01, 5.03, new install 5.03 (test server). I made a quick check in 5.10, seems the same, but there I have some other errors (libsodium support :-) ), apparently it is not correctly installed yet. So the system is Debian 8 (jessie) with the packages from debian repository. I tried to search older posts, but didn't find such behavior, but may be i was overlooked something. MK From Bryan.Jones at leesar.com Sun Jul 1 15:26:31 2018 From: Bryan.Jones at leesar.com (Bryan Jones) Date: Sun, 1 Jul 2018 14:26:31 +0000 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: There were no *rpmnew files created other than /opt/zendto/config/preferences.php.rpmnew and /opt/zendto /config/zendto.conf.rpmnew. I followed the steps documented to integrate those changes with existing files. However, I just cleared the browser cache and upon exiting the passphrase dialog, the "Encrypt every file" setting is cleared. Blindingly simple step I should have taken before. Thank you! Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrendon at gmail.com Sun Jul 1 20:44:12 2018 From: bbrendon at gmail.com (bbrendon at gmail.com) Date: Sun, 1 Jul 2018 12:44:12 -0700 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: Are you planning to add a way to disable encryption? On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo wrote: > There were no *rpmnew files created other than /opt/zendto/config/preferences.php.rpmnew > and /opt/zendto /config/zendto.conf.rpmnew. I followed the steps documented > to integrate those changes with existing files. > > However, I just cleared the browser cache and upon exiting the passphrase > dialog, the "Encrypt every file" setting is cleared. Blindingly simple step > I should have taken before. > > Thank you! > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived. > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrendon at gmail.com Sun Jul 1 21:04:49 2018 From: bbrendon at gmail.com (bbrendon at gmail.com) Date: Sun, 1 Jul 2018 13:04:49 -0700 Subject: [ZendTo] phpfpm and 5.10-2 References: Message-ID: Previously I was running 4.12 and didn't have any issues. I've updated to 5.10 and now I get errors about libsodium not being installed or enabled. I verified it was enabled but still get errors. For the moment I disabled encryption in the app as I don't need new features. I realize you don't test or run with phpfpm but just mentioning this in case you ever go there. -BB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Jul 2 09:10:58 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 2 Jul 2018 09:10:58 +0100 Subject: [ZendTo] Propblem uploading a file In-Reply-To: References: <1530453732.3113.153.camel@okto.kalm.sk> Message-ID: <9229d8f4-a78e-335d-0283-1970d7e75d90@Zend.To> Martin, Did you install it using the latest version of the ZendTo Installer? Using the ZendTo Installer will solve all sorts of things such as the libsodium support. Please also check what /var/zendto/zendto.log says, and the /var/log/apache2/ssl_error_log. Cheers, Jules. On 01/07/2018 15:02, Martin Kotuliak via ZendTo wrote: > I have problems with some files, for example this one: > > https://drive.google.com/file/d/1mo2Fuww8HcjrCaZRWnfIEkerjDmTLH9H/view?usp=sharing > > After the uploading zendto shows only this: > > https://drive.google.com/file/d/1rFDGnLtO5r-vb8sS2dD2hHxAluF05v8W/view?usp=sharing > > I tried it on 5.01, 5.03, new install 5.03 (test server). I made a quick > check in 5.10, seems the same, but there I have some other errors > (libsodium support :-) ), apparently it is not correctly installed yet. > > So the system is Debian 8 (jessie) with the packages from debian > repository. > > I tried to search older posts, but didn't find such behavior, but may be > i was overlooked something. > > MK > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Mon Jul 2 09:14:46 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 2 Jul 2018 09:14:46 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: There already is one. Just set the maximum bytes for encryption to 0 and the feature should disappear. Cheers, Jules. On 01/07/2018 20:44, bbrendon--- via ZendTo wrote: > Are you planning to add a way to disable encryption? > > On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo > wrote: > > There were no *rpmnew files created other than > /opt/zendto/config/preferences.php.rpmnew and /opt/zendto > /config/zendto.conf.rpmnew. I followed the steps documented to > integrate those changes with existing files. > > However, I just cleared the browser cache and upon exiting the > passphrase dialog, the "Encrypt every file" setting is cleared. > Blindingly simple step I should have taken before. > > Thank you! > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and > others authorized to receive it. If you are not the recipient, you > are hereby notified that any disclosure, copying, distribution or > taking action in relation of the contents of this information is > strictly prohibited and may be unlawful. > > This email has been scanned for viruses and malware, and may have > been automatically archived. > > > _______________________________________________ > 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 '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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Jul 2 09:17:22 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 2 Jul 2018 09:17:22 +0100 Subject: [ZendTo] phpfpm and 5.10-2 In-Reply-To: References: Message-ID: <5286ff82-b0ac-7f8a-42e8-f290ebe3a7ff@Zend.To> BB, To upgrade to 5.10, *please* use the ZendTo installer. This will upgrade your system pretty safely (grab your PHP settings first though, as it can't always avoid rewriting them from scratch), and install all the things you actually need. It pauses a lot along the way, and tells you what it's about to do, so you can always pause it while you go and check something out, before letting it continue. Cheers, Jules. On 01/07/2018 21:04, bbrendon--- via ZendTo wrote: > Previously I was running 4.12 and didn't have any issues. > > I've updated to 5.10 and now I get errors about libsodium not being > installed or enabled. I verified it was enabled but still get errors. > For the moment I disabled encryption in the app as I don't need new > features. > > I realize you don't test or run with phpfpm but just mentioning this > in case you ever go there. > -BB > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.venter1 at gmail.com Mon Jul 2 12:12:48 2018 From: chris.venter1 at gmail.com (Chris Venter) Date: Mon, 2 Jul 2018 12:12:48 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: Hi All 1. I have updated successfully (Ubuntu server 16.0.4 LTS) using the ZendTo Installer , and merged config files (preferences.php and zendto.conf) using the scripts supplied, but the Uploading "Popup" never closes when submitting a drop-off, I have tested with small and large files, turned off the virus scanning, set the UseRealProgressBar to false and tried on Chrome, Firefox and Internet Explorer. The email is submitted and delivered to the recipient and they can pickup the files etc.. but unless I click the home tab the Uploading "popup" stays on screen? 2. The email telling me the user has picked up the drop-off does not seem to work as well. Any ideas welcome? Thanks Chris On Mon, 2 Jul 2018 at 09:14, Jules Field via ZendTo wrote: > There already is one. Just set the maximum bytes for encryption to 0 and > the feature should disappear. > > Cheers, > Jules. > > On 01/07/2018 20:44, bbrendon--- via ZendTo wrote: > > Are you planning to add a way to disable encryption? > > On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo > wrote: > >> There were no *rpmnew files created other than >> /opt/zendto/config/preferences.php.rpmnew and /opt/zendto >> /config/zendto.conf.rpmnew. I followed the steps documented to integrate >> those changes with existing files. >> >> However, I just cleared the browser cache and upon exiting the passphrase >> dialog, the "Encrypt every file" setting is cleared. Blindingly simple step >> I should have taken before. >> >> Thank you! >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived. >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> >> > > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > 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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > _______________________________________________ > 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 Mon Jul 2 14:18:27 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 2 Jul 2018 14:18:27 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: <7765f009-3056-8b26-e06c-3d722c006c18@Zend.To> Chris, Check you haven't switched on "SMTPdebug" in preferences.php by mistake. The only place you can safely use "SMTPdebug => true" to test email sending is when *re*-sending a drop-off. Due to the page structure of other pages, it breaks them rather than do anything useful. So make sure that is set to false, then try sending a small, simple, drop-off. If it has problems sending the email, then check your logs (/var/zendto/zendto.log, /var/log/maillog, /var/log/apache2/ssl_error_log). To see the SMTP conversation that happens when it sends a message, go to your ZendTo Outbox. Then set SMTPdebug to true in preferences.php, then click on the "Re-send Drop-off" button. You will only have about 10 seconds to see the SMTP debug output before it returns you to the main menu, so I suggest you get ready to screenshot it as soon as it appears. Let me know how you get on. Cheers, Jules. On 02/07/2018 12:12, Chris Venter via ZendTo wrote: > Hi All > > 1. > I have updated successfully (Ubuntu server 16.0.4 LTS) using the > ZendTo Installer , and merged config files (preferences.php and > zendto.conf) using the scripts supplied, but the Uploading "Popup" > never closes when submitting a drop-off, I have tested with small and > large files, turned off the virus scanning, set the UseRealProgressBar > to false and tried on Chrome, Firefox and Internet Explorer. The email > is submitted and delivered to the recipient and they can pickup the > files etc.. but unless I click the home tab the Uploading "popup" > stays on screen? > > 2. > The email telling me the user has picked up the drop-off does not seem > to work as well. > > Any ideas welcome? > > Thanks > Chris > > On Mon, 2 Jul 2018 at 09:14, Jules Field via ZendTo > wrote: > > There already is one. Just set the maximum bytes for encryption to > 0 and the feature should disappear. > > Cheers, > Jules. > > On 01/07/2018 20:44, bbrendon--- via ZendTo wrote: >> Are you planning to add a way to disable encryption? >> >> On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo >> > wrote: >> >> There were no *rpmnew files created other than >> /opt/zendto/config/preferences.php.rpmnew and /opt/zendto >> /config/zendto.conf.rpmnew. I followed the steps documented >> to integrate those changes with existing files. >> >> However, I just cleared the browser cache and upon exiting >> the passphrase dialog, the "Encrypt every file" setting is >> cleared. Blindingly simple step I should have taken before. >> >> Thank you! >> >> >> *Disclaimer* >> >> The information contained in this communication from the >> sender is confidential. It is intended solely for use by the >> recipient and others authorized to receive it. If you are not >> the recipient, you are hereby notified that any disclosure, >> copying, distribution or taking action in relation of the >> contents of this information is strictly prohibited and may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may >> have been automatically archived. >> >> >> _______________________________________________ >> 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 > > '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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > _______________________________________________ > 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 'If I were a Brazilian without land or money or the means to feed my children, I would be burning the rain forest too.' - Sting www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Jul 2 16:50:33 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 2 Jul 2018 16:50:33 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <2c98ac71-5b8e-2c9d-4674-8399d82fcff4@Zend.To> <9231f075-0325-71d5-0182-779336c1dd27@alaska.gov> Message-ID: John, I have written that all up properly and put it on the ZendTo website at ??? http://zend.to/encryption.php If there is anything in that which you don't understand or aren't clear, or would like more detail on, please do let me know. There's nothing "magic" or remotely secret about how any of it works. Cheers, Jules. On 29/06/2018 17:33, John Thurston via ZendTo wrote: > > On 6/29/2018 8:03 AM, Jules Field via ZendTo wrote: >> I have just done the "production" release of ZendTo version 5.10. > > Thank you, again, for your time an effort. > >> >> ?1. Optional secure encryption and decryption of drop-offs, using a >> ??? passphrase set by the user. > > Do you have the time to describe this to us? > > Why was this added? > What business problem is it solving? > When in the flow are the bytes en/decrypted? > > I'm going to go look at the code and see if I can answer some of those > questions, but would like to know the author's view. > > -- > ?? 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 'Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll sit in a boat and drink beer all day.' - Anon www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From john.thurston at alaska.gov Mon Jul 2 19:15:28 2018 From: john.thurston at alaska.gov (John Thurston) Date: Mon, 2 Jul 2018 10:15:28 -0800 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <2c98ac71-5b8e-2c9d-4674-8399d82fcff4@Zend.To> <9231f075-0325-71d5-0182-779336c1dd27@alaska.gov> <4a40e76f-99ae-d7e0-313d-df98d62e2311@Zend.To> Message-ID: Excellent description and explanation, Jules. Thank you for taking the time to document the business need, as well as the implementation. I dug through the code last week, and observed: A) The Initialization Vector is built with the PHP7 function 'random_bytes'. B) To permit ZendTo to virus-scan and checksum, the uploaded file is written to the filesystem and subsequently replaced with the encrypted file. With respect to (A), my quick read indicates 'random_bytes' (on linux) uses the system function 'getrandom', which uses /dev/urandom. /dev/urandom should be a non-blocking call and should be able to deliver 16 bytes. I don't know about the CryptGenRandom used on windows. Nor do I know how either of these behave on virtualization platforms. Non-blocking should be non-blocking regardless of the platform, and (should entropy grow scarce) I suppose occasional pseudo-random numbers are good enough for the purpose for which these are being used. With respect to (B), this is a possible leak-point for the unencrypted file. Should the process die (or the machine be powered off), while the virus scan or encryption is happening, the unencrypted file will be left in the file system. There isn't much to do about this except perform those steps in memory before committing the file to disk. That would make a large memory footprint! Does ZendTo automatically clobber derelict files as part of the PHP initialization? This would at least limit the duration such things are left in the filesystem. Both A and B are my observations. I don't want to indicate I perceive them as problems. Any time we start talking about encryption, we should work hard to understand what we're getting, what it is protecting, and identify the edge cases. With my new understanding of what you've built for us, I'll be trying to ship this new version so my customers have the option of encryption. -- 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 bbrendon at gmail.com Mon Jul 2 23:10:25 2018 From: bbrendon at gmail.com (bbrendon at gmail.com) Date: Mon, 2 Jul 2018 15:10:25 -0700 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: That looks like it works. Thanks. I don't see that in the comments of the file or maybe I missed it? If not, it might be nice to add it. On Mon, Jul 2, 2018 at 1:14 AM, Jules Field wrote: > There already is one. Just set the maximum bytes for encryption to 0 and > the feature should disappear. > > Cheers, > Jules. > > > On 01/07/2018 20:44, bbrendon--- via ZendTo wrote: > > Are you planning to add a way to disable encryption? > > On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo > wrote: > >> There were no *rpmnew files created other than >> /opt/zendto/config/preferences.php.rpmnew and /opt/zendto >> /config/zendto.conf.rpmnew. I followed the steps documented to integrate >> those changes with existing files. >> >> However, I just cleared the browser cache and upon exiting the passphrase >> dialog, the "Encrypt every file" setting is cleared. Blindingly simple step >> I should have taken before. >> >> Thank you! >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived. >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> >> > > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > 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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrendon at gmail.com Mon Jul 2 23:28:04 2018 From: bbrendon at gmail.com (bbrendon at gmail.com) Date: Mon, 2 Jul 2018 15:28:04 -0700 Subject: [ZendTo] phpfpm and 5.10-2 In-Reply-To: References: <5286ff82-b0ac-7f8a-42e8-f290ebe3a7ff@Zend.To> Message-ID: I think you are crazy. That installer basically assumes you're running an entire VM just for zendto. I would vote the installer works like other LAMP apps. This script is like big brother. 1. apache - no thanks 2. mod_php. no thanks 3. ufw. no thanks 4. postfix. I like exim thanks. I understand you're trying to make it easy, but you're also making it harder for people like me. On Mon, Jul 2, 2018 at 1:17 AM, Jules Field wrote: > BB, > > To upgrade to 5.10, *please* use the ZendTo installer. This will upgrade > your system pretty safely (grab your PHP settings first though, as it can't > always avoid rewriting them from scratch), and install all the things you > actually need. > > It pauses a lot along the way, and tells you what it's about to do, so you > can always pause it while you go and check something out, before letting it > continue. > > Cheers, > Jules. > > > On 01/07/2018 21:04, bbrendon--- via ZendTo wrote: > > Previously I was running 4.12 and didn't have any issues. > > I've updated to 5.10 and now I get errors about libsodium not being > installed or enabled. I verified it was enabled but still get errors. For > the moment I disabled encryption in the app as I don't need new features. > > I realize you don't test or run with phpfpm but just mentioning this in > case you ever go there. > -BB > > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > 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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burnsr at william.jewell.edu Tue Jul 3 01:33:21 2018 From: burnsr at william.jewell.edu (Richard H. Burns) Date: Tue, 3 Jul 2018 00:33:21 +0000 Subject: [ZendTo] phpfpm and 5.10-2 In-Reply-To: References: <5286ff82-b0ac-7f8a-42e8-f290ebe3a7ff@Zend.To> , <57334617-4ECA-430F-943E-2A8391089513@william.jewell.edu> Message-ID: I respect people having different opinions but disparaging comments about someone who is providing the software free seems to be a bridge too far. If you don?t like the software or the way it works please don?t ruin it for the rest of us. I applaud Jules work and his always pleasant attitude. Speaking for myself, I most certainly do run a single VM for Zendto. I plan on keeping it that way. Richard Burns Server and Systems Administrator Office 816.415.7633 William Jewell College | www.jewell.edu [X] On Jul 2, 2018, at 5:28 PM, bbrendon--- via ZendTo > wrote: I think you are crazy. That installer basically assumes you're running an entire VM just for zendto. I would vote the installer works like other LAMP apps. This script is like big brother. 1. apache - no thanks 2. mod_php. no thanks 3. ufw. no thanks 4. postfix. I like exim thanks. I understand you're trying to make it easy, but you're also making it harder for people like me. On Mon, Jul 2, 2018 at 1:17 AM, Jules Field > wrote: BB, To upgrade to 5.10, *please* use the ZendTo installer. This will upgrade your system pretty safely (grab your PHP settings first though, as it can't always avoid rewriting them from scratch), and install all the things you actually need. It pauses a lot along the way, and tells you what it's about to do, so you can always pause it while you go and check something out, before letting it continue. Cheers, Jules. On 01/07/2018 21:04, bbrendon--- via ZendTo wrote: Previously I was running 4.12 and didn't have any issues. I've updated to 5.10 and now I get errors about libsodium not being installed or enabled. I verified it was enabled but still get errors. For the moment I disabled encryption in the app as I don't need new features. I realize you don't test or run with phpfpm but just mentioning this in case you ever go there. -BB _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrendon at gmail.com Tue Jul 3 02:30:32 2018 From: bbrendon at gmail.com (bbrendon at gmail.com) Date: Mon, 2 Jul 2018 18:30:32 -0700 Subject: [ZendTo] phpfpm and 5.10-2 In-Reply-To: <57334617-4ECA-430F-943E-2A8391089513@william.jewell.edu> References: <5286ff82-b0ac-7f8a-42e8-f290ebe3a7ff@Zend.To> <57334617-4ECA-430F-943E-2A8391089513@william.jewell.edu> Message-ID: You are right. Line out the " I think you are crazy. " part. On Mon, Jul 2, 2018 at 5:33 PM, Richard H. Burns wrote: > I respect people having different opinions but disparaging comments about > someone who is providing the software free seems to be a bridge too far. If > you don?t like the software or the way it works please don?t ruin it for > the rest of us. I applaud Jules work and his always pleasant attitude. > > Speaking for myself, I most certainly do run a single VM for Zendto. I > plan on keeping it that way. > > *Richard Burns* > > *Server and Systems Administrator* > > Office 816.415.7633 > > William Jewell College | www.jewell.edu > > > > On Jul 2, 2018, at 5:28 PM, bbrendon--- via ZendTo wrote: > > I think you are crazy. That installer basically assumes you're running an > entire VM just for zendto. I would vote the installer works like other LAMP > apps. This script is like big brother. > > 1. apache - no thanks > 2. mod_php. no thanks > 3. ufw. no thanks > 4. postfix. I like exim thanks. > > I understand you're trying to make it easy, but you're also making it > harder for people like me. > > > On Mon, Jul 2, 2018 at 1:17 AM, Jules Field wrote: > >> BB, >> >> To upgrade to 5.10, *please* use the ZendTo installer. This will upgrade >> your system pretty safely (grab your PHP settings first though, as it can't >> always avoid rewriting them from scratch), and install all the things you >> actually need. >> >> It pauses a lot along the way, and tells you what it's about to do, so >> you can always pause it while you go and check something out, before >> letting it continue. >> >> Cheers, >> Jules. >> >> >> On 01/07/2018 21:04, bbrendon--- via ZendTo wrote: >> >> Previously I was running 4.12 and didn't have any issues. >> >> I've updated to 5.10 and now I get errors about libsodium not being >> installed or enabled. I verified it was enabled but still get errors. For >> the moment I disabled encryption in the app as I don't need new features. >> >> I realize you don't test or run with phpfpm but just mentioning this in >> case you ever go there. >> -BB >> >> >> _______________________________________________ >> ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto >> >> >> 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 >> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 >> >> > _______________________________________________ > 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 Jul 3 09:22:27 2018 From: Jules at Zend.To (Jules Field) Date: Tue, 3 Jul 2018 09:22:27 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <6646d5ca574c4446aaa0d60813045414@RSCEXDB01.leesar.com> Message-ID: Oops, well spotted! Sorry, forgot to mention that in the comment. I will rectify that very shortly. Cheers, Jules. On 02/07/2018 23:10, bbrendon at gmail.com wrote: > That looks like it works. Thanks. I don't see that in the comments of > the file or maybe I missed it? If not, it might be nice to add it. > > On Mon, Jul 2, 2018 at 1:14 AM, Jules Field > wrote: > > There already is one. Just set the maximum bytes for encryption to > 0 and the feature should disappear. > > Cheers, > Jules. > > > On 01/07/2018 20:44, bbrendon--- via ZendTo wrote: >> Are you planning to add a way to disable encryption? >> >> On Sun, Jul 1, 2018 at 7:26 AM, Bryan Jones via ZendTo >> > wrote: >> >> There were no *rpmnew files created other than >> /opt/zendto/config/preferences.php.rpmnew and /opt/zendto >> /config/zendto.conf.rpmnew. I followed the steps documented >> to integrate those changes with existing files. >> >> However, I just cleared the browser cache and upon exiting >> the passphrase dialog, the "Encrypt every file" setting is >> cleared. Blindingly simple step I should have taken before. >> >> Thank you! >> >> >> *Disclaimer* >> >> The information contained in this communication from the >> sender is confidential. It is intended solely for use by the >> recipient and others authorized to receive it. If you are not >> the recipient, you are hereby notified that any disclosure, >> copying, distribution or taking action in relation of the >> contents of this information is strictly prohibited and may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may >> have been automatically archived. >> >> >> _______________________________________________ >> 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 > > '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 PGP footprint: > EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Intelligence is quickness to apprehend as distinct from ability, which is capacity to act wisely on the thing apprehended.' - Alfred North Whitehead www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Tue Jul 3 09:53:12 2018 From: Jules at Zend.To (Jules Field) Date: Tue, 3 Jul 2018 09:53:12 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <2c98ac71-5b8e-2c9d-4674-8399d82fcff4@Zend.To> <9231f075-0325-71d5-0182-779336c1dd27@alaska.gov> <4a40e76f-99ae-d7e0-313d-df98d62e2311@Zend.To> Message-ID: <5dfe465a-0c50-919e-60f5-f1c1fef385af@Zend.To> John, On 02/07/2018 19:15, John Thurston via ZendTo wrote: > Excellent description and explanation, Jules. Thank you for taking the > time to document the business need, as well as the implementation. I'm sure there are plenty of other situations which would call for the encryption/decryption feature. The one I documented is merely the one that was brought to my attention and hence got it implemented. > > I dug through the code last week, and observed: > A) The Initialization Vector is built with the PHP7 function > 'random_bytes'. > > B) To permit ZendTo to virus-scan and checksum, the uploaded file is > written to the filesystem and subsequently replaced with the encrypted > file. > > > With respect to (A), my quick read indicates 'random_bytes' (on linux) > uses the system function 'getrandom', which uses /dev/urandom. > /dev/urandom should be a non-blocking call and should be able to > deliver 16 bytes. I don't know about the CryptGenRandom used on > windows. Nor do I know how either of these behave on virtualization > platforms. Non-blocking should be non-blocking regardless of the > platform, and (should entropy grow scarce) I suppose occasional > pseudo-random numbers are good enough for the purpose for which these > are being used. I read up quite a bit on this aspect. Yes, you are quite right that entropy can be scarce in virtualised environments particularly. Sadly, no one appears to have much in the way of a better solution to the problem, beyond using specialised hardware to give a steady "supply" of entropy. The random_bytes() (i.e. getrandom()) function is as good as it gets. > > With respect to (B), this is a possible leak-point for the unencrypted > file. Should the process die (or the machine be powered off), while > the virus scan or encryption is happening, the unencrypted file will > be left in the file system. There isn't much to do about this except > perform those steps in memory before committing the file to disk. That > would make a large memory footprint! Does ZendTo automatically clobber > derelict files as part of the PHP initialization? This would at least > limit the duration such things are left in the filesystem. I cannot read the whole file into RAM, as you point out (anyone got 150GB RAM to put in their little ZendTo server? That's what one of you folks has the max file size set to!). And over-writing the unencrypted copy of the file just before deleting it would not actually help much either, as CoW (copy on write) filesystems are gradually taking over from journalling filesystems. With a CoW filesystem, you will just gain a bunch of zeroed blocks (which might well be compressed to nothing in a decent filestore) in addition to the untouched data from the unencrypted file. And with (effectively CoW for this aspect) devices such as SSDs, the same would happen. ZendTo doesn't automatically remove derelict files as part of the PHP initialisation, because there is really no such thing as "the PHP initialisation". I could add a cron job that deleted any files in /var/zendto/incoming which were more than a few hours old, but that's about it. If you would like to add that yourself, you just need to run a command like this every 4 hours: find /var/zendto/incoming -type f -mmin +240 -print0 | xargs -0 rm -f That should delete all files that were last modified more than 240 minutes (4 hours) ago. It will handle any and all nasty characters in the filenames, such as spaces, quotes, semi-colons or anything else that could be used to wreak havoc. > Both A and B are my observations. I don't want to indicate I perceive > them as problems. Any time we start talking about encryption, we > should work hard to understand what we're getting, what it is > protecting, and identify the edge cases. If anyone can come up with a better way of mitigating B, please do let me know. Otherwise I will add something very like this to the standard /etc/cron.d file that is installed. > > With my new understanding of what you've built for us, I'll be trying > to ship this new version so my customers have the option of encryption. 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Tue Jul 3 10:10:05 2018 From: Jules at Zend.To (Jules Field) Date: Tue, 3 Jul 2018 10:10:05 +0100 Subject: [ZendTo] phpfpm and 5.10-2 In-Reply-To: References: <5286ff82-b0ac-7f8a-42e8-f290ebe3a7ff@Zend.To> <57334617-4ECA-430F-943E-2A8391089513@william.jewell.edu> Message-ID: :-) Yes, you are absolutely correct, the installer does assume you are running an entire VM just for ZendTo. That's part of the beauty of having VMs where before we only had physical servers, where you could either use the whole server or none of it. A vast proportion of particularly small companies couldn't justify the cost of an entire server just to run ZendTo: most ZendTo servers spend most of their life idle, that's just the nature of the service ZendTo provides. But they can very cheaply spin up a VM (or merely a container) just to run ZendTo. So no longer do sysadmins have to cope with multiple web applications running simultaneously in the same filesystem with conflicting setups, different version requirements and so on. You can have 1 VM (or just 1 container) for each web application. No more conflicts between applications, each runs separately and so the ongoing support costs are a fraction of the total amount they were with multiple apps on the same host. I've been a professional Unix (and Windows and Mac) sysadmin since 1995. We wouldn't be able to operate now, the way we used to when the only option was running multiple apps directly on the same physical iron. Also, I switched away from providing a VM image "virtual appliance" for ZendTo to the Installer I provide now, because most large organisations now have pre-configured "template" VM images which contain their favourite Linux set up how they want it, with things like centralised logging, authentication, monitoring and so on already set up. It is far easier to run the Installer on top of a clone of the template, than it is to shoe-horn the centralised configs into an OS installation you had no control over. I hope that helps explain why I've gone the route I have. If you want to install it all manually, feel free. But take a look at the complexity of the Installer and work out exactly how sure you are that you won't miss something. P.S. The email sending is now done using PHPMailer, it doesn't usually use any underlying MTA at all (unless you forget to configure it in preferences.php, at which point it has no option). If you don't use PHPMailer, you don't get HTML email messages from ZendTo, only plain text ones. The old code that relies on the underlying MTA is simply there for the benefit of people who upgrade badly and so may be running with an ancient preferences.php that doesn't contain the PHPMailer settings. I don't intend anyone to *choose* to use the old code, which is partly why it only does plain text emails and not pretty HTML ones. Cheers, Jules. On 03/07/2018 02:30, bbrendon at gmail.com wrote: > You are right. Line out the " I think you are crazy.?" part. > > On Mon, Jul 2, 2018 at 5:33 PM, Richard H. Burns > > wrote: > > I respect people having different opinions but disparaging > comments about someone who is providing the software free seems to > be a bridge too far. If you don?t like the software or the way it > works please don?t ruin it for the rest of us. I applaud Jules > work and his always pleasant attitude. > > Speaking for myself, I most certainly do run a single VM for > Zendto. I plan on keeping it that way. > > *Richard Burns* > > */Server and Systems Administrator/* > > Office 816.415.7633 > > William Jewell College | www.jewell.edu > > > > On Jul 2, 2018, at 5:28 PM, bbrendon--- via ZendTo > wrote: > >> I think you are crazy. That installer basically assumes you're >> running an entire VM just for zendto. I would vote the installer >> works like other LAMP apps. This script is like big brother. >> >> 1. apache - no thanks >> 2. mod_php. no thanks >> 3. ufw. no thanks >> 4. postfix. I like exim thanks. >> >> I understand you're trying to make it easy, but you're also >> making it harder for people like me. >> >> >> On Mon, Jul 2, 2018 at 1:17 AM, Jules Field > > wrote: >> >> BB, >> >> To upgrade to 5.10, *please* use the ZendTo installer. This >> will upgrade your system pretty safely (grab your PHP >> settings first though, as it can't always avoid rewriting >> them from scratch), and install all the things you actually need. >> >> It pauses a lot along the way, and tells you what it's about >> to do, so you can always pause it while you go and check >> something out, before letting it continue. >> >> Cheers, >> Jules. >> >> >> On 01/07/2018 21:04, bbrendon--- via ZendTo wrote: >>> Previously I was running 4.12 and didn't have any issues. >>> >>> I've updated to 5.10 and now I get errors about libsodium >>> not being installed or enabled. I verified it was enabled >>> but still get errors. For the moment I disabled encryption >>> in the app as I don't need new features. >>> >>> I realize you don't test or run with phpfpm but just >>> mentioning this in case you ever go there. >>> -BB >>> >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >>> >> >> 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 >> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto >> > > 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Tue Jul 3 21:37:25 2018 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 3 Jul 2018 12:37:25 -0800 Subject: [ZendTo] Version number after update References: Message-ID: I've been playing with 5.10 on a test system. When updating from 5.02->5.10, the version number displayed in the web interface remains 5.02 and the ZTVERSION line in the config file remained unchanged. Is this by design? Am I looking in the wrong place? Am I just expected to ignore the request not to edit that line? -- 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 john.thurston at alaska.gov Tue Jul 3 21:56:05 2018 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 3 Jul 2018 12:56:05 -0800 Subject: [ZendTo] Version number after update In-Reply-To: References: Message-ID: Well silly me. It looks like I must manually update the config and preferences after using the installer to perform a version update: upgrade_preferences_php upgrade_zendto_conf If that instruction was part of the lengthy output from the installer, I missed it. . . . oh. Silly me. There it is the ssh buffer... > To help you, there are tools for upgrading the preferences.php > and zendto.conf files. > Simply run > /opt/zendto/bin/upgrade_preferences_php > and > /opt/zendto/bin/upgrade_zendto_conf > and they will show you how to use them. which appears to have been quickly pushed off the screen by the messages about merging translation files. How was I supposed to see those critical lines of instruction as they flew past? Was there a pause I happy-clicked through? -- 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 7/3/2018 12:37 PM, John Thurston via ZendTo wrote: > I've been playing with 5.10 on a test system. > > When updating from 5.02->5.10, the version number displayed in the web > interface remains 5.02 and the ZTVERSION line in the config file > remained unchanged. > > Is this by design? > Am I looking in the wrong place? > Am I just expected to ignore the request not to edit that line? > > From john.thurston at alaska.gov Tue Jul 3 22:43:23 2018 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 3 Jul 2018 13:43:23 -0800 Subject: [ZendTo] Authenticator after update References: Message-ID: Maybe this is old news to those who keep on top of their version updates. But since I've just invested an hour figuring it, I thought I'd stuff this into the archives so I can find it again in a couple of years. And maybe someone else will find it useful. The preferences.php.rpmnew available after an upgrade is box-stock. In my case, the important bit is it defined local authentication. Since I'm using ldap authorization, upgrade_preferences_php tells me it has removed all of my ldap specifications as "obsolete settings". It tells me all the settings it has removed, and I can put them all back. But that seems a long way round the barn. 'twould be better if my settings were just retained without me having to copy/paste/move them all. Reaching into preferences.php.rpmnew, commenting out: 'authenticator' => 'Local', and removing the comments from: 'authenticator' => 'LDAP', as well as the comments on the other ldap specifications I need means upgrade_preferences_php recognizes these as not-obsolete settings and will retain the values defined in my originating preferences.php The result is then a ready-to-use preferences file. -- 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 Jul 4 09:38:27 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 4 Jul 2018 09:38:27 +0100 Subject: [ZendTo] Version number after update In-Reply-To: References: Message-ID: <581ef3ef-529a-f75a-34d3-fa48d46e1195@Zend.To> John, Unfortunately that section of output all comes from the post-install scripts within the RPM/DEB packages. I can't put pauses in those. Maybe straight after the actual RPM/DEB package installation, I should tell the user again about the upgrade_* scripts and pause there for a good while? The version number is actually set in preferences.php. The "upgrade_preferences_php" updates it for you. Some organisations are very wary about giving away software version number information to outsiders, so I let you easily change it to any value you like if you are one of those types of organisation. Cheers, Jules. On 03/07/2018 21:56, John Thurston via ZendTo wrote: > Well silly me. > > It looks like I must manually update the config and preferences after > using the installer to perform a version update: > ? upgrade_preferences_php > ? upgrade_zendto_conf > > If that instruction was part of the lengthy output from the installer, > I missed it. . . . oh. Silly me. There it is the ssh buffer... > > >> To help you, there are tools for upgrading the preferences.php >> and zendto.conf files. >> Simply run >> ??? /opt/zendto/bin/upgrade_preferences_php >> and >> ??? /opt/zendto/bin/upgrade_zendto_conf >> and they will show you how to use them. > > which appears to have been quickly pushed off the screen by the > messages about merging translation files. > > How was I supposed to see those critical lines of instruction as they > flew past? Was there a pause I happy-clicked through? > > -- > ?? 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 7/3/2018 12:37 PM, John Thurston via ZendTo wrote: >> I've been playing with 5.10 on a test system. >> >> When updating from 5.02->5.10, the version number displayed in the >> web interface remains 5.02 and the ZTVERSION line in the config file >> remained unchanged. >> >> Is this by design? >> Am I looking in the wrong place? >> Am I just expected to ignore the request not to edit that line? >> >> > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'The best and most beautiful things in life cannot be seen or even touched; they must be felt with the heart.' - Helen Keller www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Wed Jul 4 09:40:54 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 4 Jul 2018 09:40:54 +0100 Subject: [ZendTo] Authenticator after update In-Reply-To: References: Message-ID: <3ec5343f-7cd8-136c-8f7b-aaedb15ccb04@Zend.To> John, Does this only happen because you use the LDAP authenticator? I use the AD one, and the upgrade_preferences_php does a perfect job for me. Curious... Jules. On 03/07/2018 22:43, John Thurston via ZendTo wrote: > Maybe this is old news to those who keep on top of their version > updates. But since I've just invested an hour figuring it, I thought > I'd stuff this into the archives so I can find it again in a couple of > years. And maybe someone else will find it useful. > > The preferences.php.rpmnew available after an upgrade is box-stock. In > my case, the important bit is it defined local authentication. Since > I'm using ldap authorization, upgrade_preferences_php tells me it has > removed all of my ldap specifications as "obsolete settings". It tells > me all the settings it has removed, and I can put them all back. But > that seems a long way round the barn. 'twould be better if my settings > were just retained without me having to copy/paste/move them all. > > Reaching into preferences.php.rpmnew, commenting out: > ? 'authenticator' => 'Local', > and removing the comments from: > ? 'authenticator'???????? => 'LDAP', > as well as the comments on the other ldap specifications I need > > means upgrade_preferences_php recognizes these as not-obsolete > settings and will retain the values defined in my originating > preferences.php > > The result is then a ready-to-use preferences file. > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'They went with songs to the battle, they were young. Straight of limb, true of eye, steady and aglow. They were staunch to the end against odds uncounted, They fell with their faces to the foe. They shall grow not old, as we that are left grow old: Age shall not weary them, nor the years condemn. At the going down of the sun and in the morning, We will remember them. They mingle not with their laughing comrades again; They sit no more at familiar tables of home; They have no lot in our labour of the day-time; They sleep beyond England's foam.' - Ode of Remembrance, Laurence Binyon www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From jamesmm1 at gmx.com Wed Jul 4 13:54:56 2018 From: jamesmm1 at gmx.com (Mr filesender) Date: Wed, 4 Jul 2018 14:54:56 +0200 Subject: [ZendTo] localIPSubnets o(r how to remove login box for externals) References: Message-ID: An HTML attachment was scrubbed... URL: From jamesmm1 at gmx.com Wed Jul 4 14:09:09 2018 From: jamesmm1 at gmx.com (Mr filesender) Date: Wed, 4 Jul 2018 15:09:09 +0200 Subject: [ZendTo] localIPSubnets o(r how to remove login box for externals) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jul 4 14:32:25 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 4 Jul 2018 14:32:25 +0100 Subject: [ZendTo] localIPSubnets o(r how to remove login box for externals) In-Reply-To: References: Message-ID: James, Agreed. As more functionality has gradually crept out of the core code and into the templates (more new JS, less new PHP), I am having to change the templates more between versions. That makes upgrading a lot harder if you have significantly modified the templates. So some sort of "Allow External Logins" switch in preferences.php is what you have in mind, yes? The other thing someone else has suggested today is removing the blue "Login" button from the main menu altogether if the "mini login box" is being shown at the top. It doesn't add any functionality in that situation, so is just clutter. Cheers, Jules. On 04/07/2018 14:09, Mr filesender via ZendTo wrote: > to pre-empt your reply, i see a post from 2012 about the same issue. > by editing the templates "login.tpl", "header.tpl" and "main_menu.tpl" > with {if $isLocalIP} it is possible to do this myself. > a switch in preferences would be nice for future versions tho ;) > thank you > *Sent:*?Wednesday, July 04, 2018 at 2:54 PM > *From:*?"Mr filesender via ZendTo" > *To:*?"ZendTo Users" > *Cc:*?"Mr filesender" > *Subject:*?[ZendTo] localIPSubnets o(r how to remove login box for > externals) > hello, > thank you again for your work on this wonderful application. i am > further testing and have a feature request (or to ask if this is > already possible in preferences). > I believe that the localIPSubnets feature that removes some prompts on > the homepage is too subtle to be of any use. i cannot see how the > difference between those coming from the localIPSubnets and those > outside is useful. > instead, i suggest that this be used to remove totally the login box. > I have a need that the only interaction from outside is with a request > code or dropoff code (ie: that dropoffs are always initiated from > inside localIPSubnets, and from outside its not possible to login, > only respond to request or access to dropoff) > maybe this is already possible? > thank you > _______________________________________________ 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 '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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesmm1 at gmx.com Wed Jul 4 15:46:31 2018 From: jamesmm1 at gmx.com (Mr filesender) Date: Wed, 4 Jul 2018 16:46:31 +0200 Subject: [ZendTo] localIPSubnets o(r how to remove login box for externals) References: Message-ID: An HTML attachment was scrubbed... URL: From jamesmm1 at gmx.com Wed Jul 4 16:32:32 2018 From: jamesmm1 at gmx.com (Mr filesender) Date: Wed, 4 Jul 2018 17:32:32 +0200 Subject: [ZendTo] Error on File Upload References: Message-ID: An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Thu Jul 5 18:53:40 2018 From: john.thurston at alaska.gov (John Thurston) Date: Thu, 5 Jul 2018 09:53:40 -0800 Subject: [ZendTo] Authenticator after update In-Reply-To: References: <3ec5343f-7cd8-136c-8f7b-aaedb15ccb04@Zend.To> Message-ID: I did a few tests. I don't have to uncomment the enabling line: 'authenticator' => 'LDAP' But I must uncomment only those ldap lines I have enabled in my 'old' config for upgrade_pref to do its job for me. If I uncomment all the ldap lines in the rpmnew config, the upgrade_pref adds values for any I did not have enabled in my 'old' config. If I switch the 'old' config to imap, the upgrade_pref does its job with the stock rpmnew file. -- 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 kbe2 at lehigh.edu Fri Jul 6 21:16:35 2018 From: kbe2 at lehigh.edu (Keith Erekson) Date: Fri, 6 Jul 2018 16:16:35 -0400 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <2c98ac71-5b8e-2c9d-4674-8399d82fcff4@Zend.To> <9231f075-0325-71d5-0182-779336c1dd27@alaska.gov> <4a40e76f-99ae-d7e0-313d-df98d62e2311@Zend.To> <5dfe465a-0c50-919e-60f5-f1c1fef385af@Zend.To> <35c62fb8-3700-a8fa-f8e1-c0d70ac6d7b3@lehigh.edu> Message-ID: fwiw, you can just pass "-delete" directly to the find command instead of -print0 ~Keith On 07/03/2018 04:53 AM, Jules Field via ZendTo wrote: > ZendTo doesn't automatically remove derelict files as part of the PHP > initialisation, because there is really no such thing as "the PHP > initialisation". I could add a cron job that deleted any files in > /var/zendto/incoming which were more than a few hours old, but that's > about it. If you would like to add that yourself, you just need to run > a command like this every 4 hours: > > find /var/zendto/incoming -type f -mmin +240 -print0 | xargs -0 rm -f From burnsr at william.jewell.edu Fri Jul 6 22:59:46 2018 From: burnsr at william.jewell.edu (Richard H. Burns) Date: Fri, 6 Jul 2018 21:59:46 +0000 Subject: [ZendTo] Issues with Zend.To 5.1 References: <9388C6B8-8ECF-4788-9F42-CFBF7809B3C3@contoso.com> Message-ID: Actually, this problem is really with 5.09.13. I did the upgrade to 5.10.2, and found that emails were no longer sending. I was getting ?SMTP Error: data not accepted. SMTP server error: DATA END command failed Detail: 5.7.60 SMTP; Client does not have permissions to send as this sender SMTP code: 550.? The problem is we use relay authentication for the Exchange connector and Exchange won?t allow you to authenticate as one user, and then send as another. From what I see in the change log, Zendto is now trying to send as the from user not the actual sender and so it fails. An option to disable this would be beneficial. Secondly, This line - 'authLDAPBaseDN1' => array('OU=group1,DC=part1,DC=part2,DC=part3', 'OU=group2,DC=part1,DC=part2,DC=part3'), Became this line after the upgrade script - 'authLDAPBaseDN1' => array('OU=group1,DC=part1,DC=part2,DC=part3',, 'OU=group2,DC=part1,DC=part2,DC=part3'), Note the second ?,? on the first line. This of course caused an error. It took a while to figure that one out. -- Richard Burns Server and Systems Administrator Office 816.415.7633 William Jewell College | www.jewell.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jul 7 17:32:55 2018 From: Jules at Zend.To (Jules) Date: Sat, 7 Jul 2018 17:32:55 +0100 Subject: [ZendTo] ANNOUNCE: Version 5.10-1 "production" released In-Reply-To: References: <2c98ac71-5b8e-2c9d-4674-8399d82fcff4@Zend.To> <9231f075-0325-71d5-0182-779336c1dd27@alaska.gov> <4a40e76f-99ae-d7e0-313d-df98d62e2311@Zend.To> <5dfe465a-0c50-919e-60f5-f1c1fef385af@Zend.To> <35c62fb8-3700-a8fa-f8e1-c0d70ac6d7b3@lehigh.edu> Message-ID: <5571aa85-5189-ef01-d92a-76f133f2a7bd@Zend.To> Keith, Another option of find I didn't know! Thanks for that, Jules. On 06/07/2018 9:16 pm, Keith Erekson via ZendTo wrote: > fwiw, you can just pass "-delete" directly to the find command instead > of -print0 > > ~Keith > > > On 07/03/2018 04:53 AM, Jules Field via ZendTo wrote: >> ZendTo doesn't automatically remove derelict files as part of the PHP >> initialisation, because there is really no such thing as "the PHP >> initialisation". I could add a cron job that deleted any files in >> /var/zendto/incoming which were more than a few hours old, but that's >> about it. If you would like to add that yourself, you just need to run >> a command like this every 4 hours: >> >> find /var/zendto/incoming -type f -mmin +240 -print0 | xargs -0 rm -f > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Bailey: South, veering west or southwest, 4 or 5, occasionally 6 at first. Moderate. Rain then showers. Moderate, becoming good. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Sat Jul 7 17:38:32 2018 From: Jules at Zend.To (Jules) Date: Sat, 7 Jul 2018 17:38:32 +0100 Subject: [ZendTo] Issues with Zend.To 5.1 In-Reply-To: References: <9388C6B8-8ECF-4788-9F42-CFBF7809B3C3@contoso.com> Message-ID: <3a7da2ae-5e65-2690-2a5c-34e6e5e26066@Zend.To> Richard, Did you split the contents of the array over more than 1 line? I can't tell from what you've pasted. If you did, that that would break my upgrader as it doesn't actually know anything about PHP at all. It just knows about ??? key => value, lines, comments, and the overall shape of the preferences.php file. It's language-agnostic. If you didn't split it, I'm going to need to do some digging as this doesn't happen to me. Cheers, Jules. On 06/07/2018 10:59 pm, Richard H. Burns via ZendTo wrote: > > Actually, this problem is really with 5.09.13. > > ??????????????? I did the upgrade to 5.10.2, and found that emails > were no longer sending. I was getting ?SMTP Error: data not accepted. > SMTP server error: DATA END command failed Detail: 5.7.60 SMTP; Client > does not have permissions to send as this sender SMTP code: 550.? The > problem is we use relay authentication for the Exchange connector and > Exchange won?t allow you to authenticate as one user, and then send as > another. From what I see in the change log, Zendto is now trying to > send as the from user not the actual sender and so it fails. An option > to disable this would be beneficial. > > Secondly, > > ??????????????? This line - 'authLDAPBaseDN1' ? ? ? ? ? => > array('OU=group1,DC=part1,DC=part2,DC=part3', > > 'OU=group2,DC=part1,DC=part2,DC=part3'), > > ??????????????? Became this line after the upgrade script - > 'authLDAPBaseDN1' ? ? ? ? ? => > array('OU=group1,DC=part1,DC=part2,DC=part3',, > > 'OU=group2,DC=part1,DC=part2,DC=part3'), > > Note the second ?,? on the first line. This of course caused an error. > > It took a while to figure that one out. > > -- > > Richard Burns > > Server and Systems Administrator > > Office 816.415.7633 > > William Jewell College | www.jewell.edu > > > > _______________________________________________ > 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From burnsr at william.jewell.edu Sat Jul 7 18:03:37 2018 From: burnsr at william.jewell.edu (Richard H. Burns) Date: Sat, 7 Jul 2018 17:03:37 +0000 Subject: [ZendTo] Issues with Zend.To 5.1 In-Reply-To: References: <9388C6B8-8ECF-4788-9F42-CFBF7809B3C3@contoso.com> <3a7da2ae-5e65-2690-2a5c-34e6e5e26066@Zend.To>, <592DFEC2-6B55-437C-9092-77422E1D0AB1@william.jewell.edu> Message-ID: It was split, so I assumed that was the issue. The only thing I would point out if the example a few lines above that is also split. So I was following the provided example. Richard Burns Server and Systems Administrator Office 816.415.7633 William Jewell College | www.jewell.edu [X] On Jul 7, 2018, at 11:38 AM, Jules > wrote: Richard, Did you split the contents of the array over more than 1 line? I can't tell from what you've pasted. If you did, that that would break my upgrader as it doesn't actually know anything about PHP at all. It just knows about key => value, lines, comments, and the overall shape of the preferences.php file. It's language-agnostic. If you didn't split it, I'm going to need to do some digging as this doesn't happen to me. Cheers, Jules. On 06/07/2018 10:59 pm, Richard H. Burns via ZendTo wrote: Actually, this problem is really with 5.09.13. I did the upgrade to 5.10.2, and found that emails were no longer sending. I was getting ?SMTP Error: data not accepted. SMTP server error: DATA END command failed Detail: 5.7.60 SMTP; Client does not have permissions to send as this sender SMTP code: 550.? The problem is we use relay authentication for the Exchange connector and Exchange won?t allow you to authenticate as one user, and then send as another. From what I see in the change log, Zendto is now trying to send as the from user not the actual sender and so it fails. An option to disable this would be beneficial. Secondly, This line - 'authLDAPBaseDN1' => array('OU=group1,DC=part1,DC=part2,DC=part3', 'OU=group2,DC=part1,DC=part2,DC=part3'), Became this line after the upgrade script - 'authLDAPBaseDN1' => array('OU=group1,DC=part1,DC=part2,DC=part3',, 'OU=group2,DC=part1,DC=part2,DC=part3'), Note the second ?,? on the first line. This of course caused an error. It took a while to figure that one out. -- Richard Burns Server and Systems Administrator Office 816.415.7633 William Jewell College | www.jewell.edu _______________________________________________ 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jul 7 18:27:23 2018 From: Jules at Zend.To (Jules) Date: Sat, 7 Jul 2018 18:27:23 +0100 Subject: [ZendTo] Issues with Zend.To 5.1 In-Reply-To: References: <9388C6B8-8ECF-4788-9F42-CFBF7809B3C3@contoso.com> Message-ID: <6001b744-af36-524f-08de-3b1a5476925f@Zend.To> Richard, On 06/07/2018 10:59 pm, Richard H. Burns via ZendTo wrote: > > Actually, this problem is really with 5.09.13. > > ??????????????? I did the upgrade to 5.10.2, and found that emails > were no longer sending. I was getting ?SMTP Error: data not accepted. > SMTP server error: DATA END command failed Detail: 5.7.60 SMTP; Client > does not have permissions to send as this sender SMTP code: 550.? The > problem is we use relay authentication for the Exchange connector and > Exchange won?t allow you to authenticate as one user, and then send as > another. From what I see in the change log, Zendto is now trying to > send as the from user not the actual sender and so it fails. An option > to disable this would be beneficial. > There will now be a switch at the end of the "SMTP" settings in preferences.php to control this. By default it will go back to its previous behaviour of *always* sending from the address set in zendto.conf. But if you want it to set the From to the same address as the Reply-To (i.e. the person who created the drop-off), and it won't cause any downstream delivery problems (think SPF+DMARC) you can change the setting. 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Sat Jul 7 18:35:11 2018 From: Jules at Zend.To (Jules) Date: Sat, 7 Jul 2018 18:35:11 +0100 Subject: [ZendTo] Issues with Zend.To 5.1 In-Reply-To: References: <9388C6B8-8ECF-4788-9F42-CFBF7809B3C3@contoso.com> <3a7da2ae-5e65-2690-2a5c-34e6e5e26066@Zend.To> <592DFEC2-6B55-437C-9092-77422E1D0AB1@william.jewell.edu> Message-ID: <58fdf0e9-8f84-7bf8-1c97-ce196c5a4a36@Zend.To> Richard, Once you've changed the value of a setting, the comments above that setting are kept when you upgrade_preferences_php, as you might have added some comments of your own. So I think the example you were looking at was probably an old one, as in the current file the example is definitely on 1 line. If you haven't changed a particular setting, then upgrade_preferences_php replaces the comment block with the new one, as (a) you probably haven't added any comments of your own, and (b) if you do ever change the setting in the future, you will have the most recent description of it. I have just added a note below the example to point out that settings mustn't be split across multiple lines. Sadly, of course, because you have changed that setting, you won't ever see my new note. Ho hum. :-/ Cheers, Jules. On 07/07/2018 6:03 pm, Richard H. Burns wrote: > It was split, so I assumed that was the issue. The only thing I would > point out if the example a few lines above that is also split. So I > was following the provided example. > > *Richard Burns* > > */Server and Systems Administrator/* > > Office 816.415.7633 > > William Jewell College | www.jewell.edu > > > > On Jul 7, 2018, at 11:38 AM, Jules > wrote: > >> Richard, >> >> Did you split the contents of the array over more than 1 line? >> I can't tell from what you've pasted. >> >> If you did, that that would break my upgrader as it doesn't actually >> know anything about PHP at all. It just knows about >> ??? key => value, >> lines, comments, and the overall shape of the preferences.php file. >> It's language-agnostic. >> >> If you didn't split it, I'm going to need to do some digging as this >> doesn't happen to me. >> >> Cheers, >> Jules. >> >> On 06/07/2018 10:59 pm, Richard H. Burns via ZendTo wrote: >>> >>> Actually, this problem is really with 5.09.13. >>> >>> ??????????????? I did the upgrade to 5.10.2, and found that emails >>> were no longer sending. I was getting ?SMTP Error: data not >>> accepted. SMTP server error: DATA END command failed Detail: 5.7.60 >>> SMTP; Client does not have permissions to send as this sender SMTP >>> code: 550.? The problem is we use relay authentication for the >>> Exchange connector and Exchange won?t allow you to authenticate as >>> one user, and then send as another. From what I see in the change >>> log, Zendto is now trying to send as the from user not the actual >>> sender and so it fails. An option to disable this would be beneficial. >>> >>> Secondly, >>> >>> ??????????????? This line - 'authLDAPBaseDN1' ? ? ? ? ? => >>> array('OU=group1,DC=part1,DC=part2,DC=part3', >>> >>> ? 'OU=group2,DC=part1,DC=part2,DC=part3'), >>> >>> ??????????????? Became this line after the upgrade script - >>> 'authLDAPBaseDN1' ? ? ? ? => >>> array('OU=group1,DC=part1,DC=part2,DC=part3',, >>> >>> ? 'OU=group2,DC=part1,DC=part2,DC=part3'), >>> >>> Note the second ?,? on the first line. This of course caused an error. >>> >>> It took a while to figure that one out. >>> >>> -- >>> >>> Richard Burns >>> >>> Server and Systems Administrator >>> >>> Office 816.415.7633 >>> >>> William Jewell College | www.jewell.edu >>> >>> >>> >>> _______________________________________________ >>> 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 >> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM IMPORTANT: This email is intended for the use of the individual addressee(s) named above and may contain information that is confidential, privileged or unsuitable for overly sensitive persons with low self-esteem, no sense of humour or irrational religious beliefs. If you are not the intended recipient, any dissemination, distribution or copying of this email is not authorised (either explicitly or implicitly) and constitutes an irritating social faux pas. Unless the word absquatulation has been used in its correct context somewhere other than in this warning, it does not have any legal or no grammatical use and may be ignored. No animals were harmed in the transmission of this email, although the kelpie next door is living on borrowed time, let me tell you. Those of you with an overwhelming fear of the unknown will be gratified to learn that there is no hidden message revealed by reading this warning backwards, so just ignore that Alert Notice from Microsoft. However, by pouring a complete circle of salt around yourself and your computer you can ensure that no harm befalls you and your pets. If you have received this email in error, please add some nutmeg and egg whites, whisk and place in a warm oven for 40 minutes. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Istyak.Ahmad at niit.com Mon Jul 9 04:49:26 2018 From: Istyak.Ahmad at niit.com (Istyak Ahmad) Date: Mon, 9 Jul 2018 03:49:26 +0000 Subject: [ZendTo] reCAPTCHA issue References: Message-ID: Dear Team, I have done the following settings in the preference.php file, but captcha verification is getting failed. Kindly help if you have any solutions to fix the captcha issue. 'captcha' => 'google', 'recaptchaPublicKey' => '6XXXXIUAAAAAFUzD4P-Zjk-DNRsT_AXXXXXXXXXX', 'recaptchaPrivateKey' => '6XXXX5mIUAAAAANxs8QYN-Afg-j8SVTFXXXXXXX-', [cid:image001.png at 01D41765.EA8AFCE0] Regards, Istyak Ahmad NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 Phone: +91 9654505787, 0124-4916544 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 155465 bytes Desc: image001.png URL: From m.a.young at durham.ac.uk Mon Jul 9 08:43:39 2018 From: m.a.young at durham.ac.uk (M A Young) Date: Mon, 9 Jul 2018 08:43:39 +0100 (BST) Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: Message-ID: On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: > I have done the following settings in the preference.php file, but captcha > verification is getting failed. Kindly help if you have any solutions to fix > the captcha issue. That message probably means the connection from your zendto server to google to verify the captcha is failing. I was seeing it last week on a test server until I worked out a way to persuade it to use a web proxy. Michael Young From Jules at Zend.To Mon Jul 9 09:26:26 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 9 Jul 2018 09:26:26 +0100 Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: Message-ID: Google now appear to do all the CAPTCHA stuff over https and no longer support proxies in the middle. Also, does your "private key" really end with a "-"? The 2 keys should be exactly the same length. Cheers, Jules. On 09/07/2018 08:43, M A Young via ZendTo wrote: > On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: > >> I have done the following settings in the preference.php file, but captcha >> verification is getting failed. Kindly help if you have any solutions to fix >> the captcha issue. > That message probably means the connection from your zendto server to > google to verify the captcha is failing. I was seeing it last week on a > test server until I worked out a way to persuade it to use a web proxy. > > Michael Young > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM South Utsire: Northwesterly 6 to gale 8 veering northerly 4 or 5 later. Moderate or rough. Fair. Good. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Istyak.Ahmad at niit.com Mon Jul 9 09:35:37 2018 From: Istyak.Ahmad at niit.com (Istyak Ahmad) Date: Mon, 9 Jul 2018 14:05:37 +0530 Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: Message-ID: Dear Jules, Yes, private key is end with a "-". I re-created the keys & tried, but getting the same issue. Regards,?????????????????????????????????????????????????????????????????????????????????????????????????????????? Istyak Ahmad NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 Phone: +91 9654505787, 0124-4916544 -----Original Message----- From: Jules Field Sent: Monday, July 9, 2018 1:56 PM To: ZendTo Users Cc: M A Young ; Istyak Ahmad Subject: Re: [ZendTo] reCAPTCHA issue Google now appear to do all the CAPTCHA stuff over https and no longer support proxies in the middle. Also, does your "private key" really end with a "-"? The 2 keys should be exactly the same length. Cheers, Jules. On 09/07/2018 08:43, M A Young via ZendTo wrote: > On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: > >> I have done the following settings in the preference.php file, but >> captcha verification is getting failed. Kindly help if you have any >> solutions to fix the captcha issue. > That message probably means the connection from your zendto server to > google to verify the captcha is failing. I was seeing it last week on > a test server until I worked out a way to persuade it to use a web proxy. > > Michael Young > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM South Utsire: Northwesterly 6 to gale 8 veering northerly 4 or 5 later. Moderate or rough. Fair. Good. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Visit us at: http://www.niit.com Follow us on: http://www.twitter.com/niitltd ------------------------------------------------------------------------------------------------------------- DISCLAIMER This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of the company shall be understood to be neither given nor endorsed by NIIT Ltd. Any information contained in this email, when addressed to Clients is subject to the terms and conditions in governing client contract. From Jules at Zend.To Mon Jul 9 09:56:36 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 9 Jul 2018 09:56:36 +0100 Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: Message-ID: <069cf0ce-0e9d-8e6a-63ce-58dcdd21fc4e@Zend.To> Istyak, Please make sure you have set 'recaptchaInvisible'?? => FALSE, in preferences.php. The "Invisible" one has some problems right now, sorry. Cheers, Jules. On 09/07/2018 09:35, Istyak Ahmad wrote: > Dear Jules, > Yes, private key is end with a "-". > I re-created the keys & tried, but getting the same issue. > > Regards, > > Istyak Ahmad > NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 > Phone: +91 9654505787, 0124-4916544 > > -----Original Message----- > From: Jules Field > Sent: Monday, July 9, 2018 1:56 PM > To: ZendTo Users > Cc: M A Young ; Istyak Ahmad > Subject: Re: [ZendTo] reCAPTCHA issue > > Google now appear to do all the CAPTCHA stuff over https and no longer support proxies in the middle. > > Also, does your "private key" really end with a "-"? > The 2 keys should be exactly the same length. > > Cheers, > Jules. > > On 09/07/2018 08:43, M A Young via ZendTo wrote: >> On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: >> >>> I have done the following settings in the preference.php file, but >>> captcha verification is getting failed. Kindly help if you have any >>> solutions to fix the captcha issue. >> That message probably means the connection from your zendto server to >> google to verify the captcha is failing. I was seeing it last week on >> a test server until I worked out a way to persuade it to use a web proxy. >> >> Michael Young >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > South Utsire: Northwesterly 6 to gale 8 veering northerly 4 or 5 later. > Moderate or rough. Fair. Good. > > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > Visit us at: http://www.niit.com > Follow us on: http://www.twitter.com/niitltd > > ------------------------------------------------------------------------------------------------------------- > > DISCLAIMER > This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of the company shall be understood to be neither given nor endorsed by NIIT Ltd. Any information contained in this email, when addressed to Clients is subject to the terms and conditions in governing client contract. 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Istyak.Ahmad at niit.com Mon Jul 9 10:09:03 2018 From: Istyak.Ahmad at niit.com (Istyak Ahmad) Date: Mon, 9 Jul 2018 09:09:03 +0000 Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: <069cf0ce-0e9d-8e6a-63ce-58dcdd21fc4e@Zend.To> Message-ID: Yes, it's false 'recaptchaInvisible' => FALSE, Regards,?????????????????????????????????????????????????????????????????????????????????????????????????????????? Istyak Ahmad NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 Phone: +91 9654505787, 0124-4916544 -----Original Message----- From: Jules Field Sent: Monday, July 9, 2018 2:27 PM To: Istyak Ahmad ; ZendTo Users Cc: M A Young Subject: Re: [ZendTo] reCAPTCHA issue Istyak, Please make sure you have set 'recaptchaInvisible'?? => FALSE, in preferences.php. The "Invisible" one has some problems right now, sorry. Cheers, Jules. On 09/07/2018 09:35, Istyak Ahmad wrote: > Dear Jules, > Yes, private key is end with a "-". > I re-created the keys & tried, but getting the same issue. > > Regards, > > Istyak Ahmad > NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 > Phone: +91 9654505787, 0124-4916544 > > -----Original Message----- > From: Jules Field > Sent: Monday, July 9, 2018 1:56 PM > To: ZendTo Users > Cc: M A Young ; Istyak Ahmad > > Subject: Re: [ZendTo] reCAPTCHA issue > > Google now appear to do all the CAPTCHA stuff over https and no longer support proxies in the middle. > > Also, does your "private key" really end with a "-"? > The 2 keys should be exactly the same length. > > Cheers, > Jules. > > On 09/07/2018 08:43, M A Young via ZendTo wrote: >> On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: >> >>> I have done the following settings in the preference.php file, but >>> captcha verification is getting failed. Kindly help if you have any >>> solutions to fix the captcha issue. >> That message probably means the connection from your zendto server to >> google to verify the captcha is failing. I was seeing it last week on >> a test server until I worked out a way to persuade it to use a web proxy. >> >> Michael Young >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > South Utsire: Northwesterly 6 to gale 8 veering northerly 4 or 5 later. > Moderate or rough. Fair. Good. > > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > Visit us at: http://www.niit.com > Follow us on: http://www.twitter.com/niitltd > > ---------------------------------------------------------------------- > --------------------------------------- > > DISCLAIMER > This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of the company shall be understood to be neither given nor endorsed by NIIT Ltd. Any information contained in this email, when addressed to Clients is subject to the terms and conditions in governing client contract. 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Mon Jul 9 10:23:18 2018 From: Jules at Zend.To (Jules Field) Date: Mon, 9 Jul 2018 10:23:18 +0100 Subject: [ZendTo] reCAPTCHA issue In-Reply-To: References: <069cf0ce-0e9d-8e6a-63ce-58dcdd21fc4e@Zend.To> Message-ID: Curious. Time for some serious debugging... Take a safe copy of the file /opt/zendto/www/verify.php. Edit it in your favourite text editor. Starting at about line 100 you will see a chunk of code like this: ??????????? // Old version 1 code. ??????????? // $resp = recaptcha_check_answer($reCaptchaPrivateKey, ??????????? // getClientIP(), ??????????? // $_POST["g-recaptcha-response"]); ??????????? $recaptcha = new \ReCaptcha\ReCaptcha($reCaptchaPrivateKey); ??????????? $rcresponse = $recaptcha->verify($_POST["g-recaptcha-response"], getClientIP()); ??????????? if ($rcresponse->isSuccess()) { ????????????? $resp = TRUE; ??????????? } ??????????? if (!$resp) { ????????????? foreach ($rcresponse->getErrorCodes() as $code) { ??????????????? if ($code == "missing-input-response") ????????????????? $code = gettext("I do not think you are a real person."); Look for the "Old version 1 code" comment and you'll soon find it. Immediately after this bit: ??????????? if ($rcresponse->isSuccess()) { ????????????? $resp = TRUE; ??????????? } add this extra line: ??????????? $theDropbox->writeToLog("reCAPTCHA text: " . $_POST["g-recaptcha-response"]); Save and exit the editor. Try the drop-off process again. This time, after it fails, do a ??? tail /var/zendto/zendto.log command and it will show you the last few lines of the log. What does that show on the line that starts "reCAPTCHA text"? Cheers, Jules. On 09/07/2018 10:09, Istyak Ahmad wrote: > Yes, it's false > > 'recaptchaInvisible' => FALSE, > > Regards, > > Istyak Ahmad > NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 > Phone: +91 9654505787, 0124-4916544 > > -----Original Message----- > From: Jules Field > Sent: Monday, July 9, 2018 2:27 PM > To: Istyak Ahmad ; ZendTo Users > Cc: M A Young > Subject: Re: [ZendTo] reCAPTCHA issue > > Istyak, > > Please make sure you have set > > 'recaptchaInvisible'?? => FALSE, > > in preferences.php. The "Invisible" one has some problems right now, sorry. > > Cheers, > Jules. > > On 09/07/2018 09:35, Istyak Ahmad wrote: >> Dear Jules, >> Yes, private key is end with a "-". >> I re-created the keys & tried, but getting the same issue. >> >> Regards, >> >> Istyak Ahmad >> NIIT Limited | A-24 Infocity, Sector 34, Gurgaon - 122004 >> Phone: +91 9654505787, 0124-4916544 >> >> -----Original Message----- >> From: Jules Field >> Sent: Monday, July 9, 2018 1:56 PM >> To: ZendTo Users >> Cc: M A Young ; Istyak Ahmad >> >> Subject: Re: [ZendTo] reCAPTCHA issue >> >> Google now appear to do all the CAPTCHA stuff over https and no longer support proxies in the middle. >> >> Also, does your "private key" really end with a "-"? >> The 2 keys should be exactly the same length. >> >> Cheers, >> Jules. >> >> On 09/07/2018 08:43, M A Young via ZendTo wrote: >>> On Mon, 9 Jul 2018, Istyak Ahmad via ZendTo wrote: >>> >>>> I have done the following settings in the preference.php file, but >>>> captcha verification is getting failed. Kindly help if you have any >>>> solutions to fix the captcha issue. >>> That message probably means the connection from your zendto server to >>> google to verify the captcha is failing. I was seeing it last week on >>> a test server until I worked out a way to persuade it to use a web proxy. >>> >>> Michael Young >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> South Utsire: Northwesterly 6 to gale 8 veering northerly 4 or 5 later. >> Moderate or rough. Fair. Good. >> >> www.Zend.To >> Twitter: @JulesFM >> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 >> >> >> Visit us at: http://www.niit.com >> Follow us on: http://www.twitter.com/niitltd >> >> ---------------------------------------------------------------------- >> --------------------------------------- >> >> DISCLAIMER >> This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of the company shall be understood to be neither given nor endorsed by NIIT Ltd. Any information contained in this email, when addressed to Clients is subject to the terms and conditions in governing client contract. > 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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'What happened in the past that was painful, has a great deal to do with what we are today.' - William Glasser www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Tue Jul 10 15:42:37 2018 From: Jules at Zend.To (Jules Field) Date: Tue, 10 Jul 2018 15:42:37 +0100 Subject: [ZendTo] ANNOUNCE: 5.11 released Message-ID: <7936e519-c799-595f-4beb-9d3dc16bb4e7@Zend.To> Folks, I have just released version 5.11 of ZendTo. Most of the changes are relatively minor, but fix a few requests from people who have been using 5.10. - Mail by default all comes from the address set in zendto.conf (as it did before 5.10). If you need to change this to the behaviour displayed by 5.10, there is a 'SMTPsetFromToSender' you can set to true. - All logins from non-local IP addresses can be disabled by setting 'allowExternalLogins' to false. - Your value for the "OrganizationShortType" in zendto.conf should now include "the" on the front. This is to make it much easier for a lot of organisations to customise the user interface without having to edit language strings in zendto.po files. - The main menu no longer shows the "Login" button if the mini login box is also showing. - The installer now fully supports installation of the crypto library on all supported platforms (SUSE and openSUSE were missing). Notes for upgrading: * If you are upgrading from 5.10, then yum/apt/zypper should do what you need, followed by the usual upgrade_preferences_php and upgrade_zendto_conf. * If you are upgrading from before 5.10, then please download and run the installer from ??? http://zend.to/downloads.php#installer * PLEASE remember to run upgrade_preferences_php and upgrade_zendto_conf as there are changes/additions in both files. Please let me know what you think! The full Change log is: - New preferences.php setting 'SMTPsetFromToSender' to control whether email ? messages sent by Zendto always come from the address in zendto.conf (false) ? or whether, where possible, the sender address should be set to the ? address of the person to whom replies would go (true). ? Before 5.10 this was always false, 5.10 changed the behaviour to true. ? The default is now false again, but you can set it yourselves as needed. ? Those using Exchange or Office365 as their SMTP server should leave this ? set to false, as Exchange doesn't let you send mail as anyone except ? addresses belonging to the username you logged in as (ie SMTPusername). - New preferences.php setting 'allowExternalLogins' (true by default). It ? can be used to stop people outside local IPs being able to login at all. ? Apparently a few sites need this. - Changed "OrganizationShortType" in zendto.conf so it includes "the" as ? well as the word "University" or "Company" or whatever you chose. ? YOU WILL NEED TO CHANGE YOUR zendto.conf FILE TO ADD "the". ? upgrade_zendto_conf will warn you about this. - For the LDAP authenticator, there is a new setting 'authLDAPEmailAttr' ? to be used if email addresses are not stored in the 'mail' attribute. - Added cron job every 4 hours to delete incoming files older than 4 hours. ? This should help to keep /var/zendto/incoming clean. - Installer now fully supports encryption/decryption on SUSE and openSUSE. - Added notes in preferences.php on how to disable the checksum and/or ? encryption features. - Added notes in preferences.php about when and how to use SMTPdebug ? correctly. - Removed big blue "Login" button from main menu "column of buttons" if ? the mini login box is also showing. - Improved wording under mini login box. - Updated copy of moment.js, used when sorting drop-offs by date. - Double-checked to ensure cookies are always https-only when using an ? https site (cookie_secure flag). Cheers, Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Viking, North Utsire, South Utsire, Forties: Northerly 3 or 4, occasionally 5 at first. Smooth or slight, occasionally moderate at first. Fair. Good. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From ricky.boone at gmail.com Thu Jul 12 16:30:47 2018 From: ricky.boone at gmail.com (Ricky Boone) Date: Thu, 12 Jul 2018 11:30:47 -0400 Subject: [ZendTo] Feature Request: Option to disable visible version strings References: Message-ID: I think it would be helpful to include an option that disables the visibility of the version, at least to non-administrators, that is normally rendered at the footer of every page. While there are absolutely other ways to secure a system, or ways that bad actors could determine what version you're potentially running, handing out information like the version string can be a risk if there is a zero day or other vulnerability. Several best practices related to securing a web server include disabling version strings or otherwise obfuscating the Server header in Apache httpd, for example: https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) For the time being, I'm just clearing out the parts of the footer.tpl template that include this, but I think this would be cleaner to do within the config. If I'm going about this the wrong way, let me know, however I'm still of the opinion that publicly announcing this level of detail is probably not the most secure option, either. From Jules at Zend.To Thu Jul 12 17:31:35 2018 From: Jules at Zend.To (Jules Field) Date: Thu, 12 Jul 2018 17:31:35 +0100 Subject: [ZendTo] Feature Request: Option to disable visible version strings In-Reply-To: References: Message-ID: Why not just set "ZTVERSION" in preferences.php to any other string you like? That's exactly why I let you set it. Just change it to "1" or something like that. Cheers, Jules. On 12/07/2018 16:30, Ricky Boone via ZendTo wrote: > I think it would be helpful to include an option that disables the > visibility of the version, at least to non-administrators, that is > normally rendered at the footer of every page. While there are > absolutely other ways to secure a system, or ways that bad actors > could determine what version you're potentially running, handing out > information like the version string can be a risk if there is a zero > day or other vulnerability. Several best practices related to > securing a web server include disabling version strings or otherwise > obfuscating the Server header in Apache httpd, for example: > > https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) > > For the time being, I'm just clearing out the parts of the footer.tpl > template that include this, but I think this would be cleaner to do > within the config. If I'm going about this the wrong way, let me > know, however I'm still of the opinion that publicly announcing this > level of detail is probably not the most secure option, either. > > _______________________________________________ > 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Fri Jul 13 15:31:07 2018 From: Jules at Zend.To (Jules Field) Date: Fri, 13 Jul 2018 15:31:07 +0100 Subject: [ZendTo] Feature Request: Option to disable visible version strings In-Reply-To: References: Message-ID: <3eba1ee4-1e33-8640-abc8-045e7d7167da@Zend.To> Ricky, The only way it will affect future upgrades (and/or upgrade_preferences_php) is that upgrade_preferences_php will always reset it to the version number given in the new preferences.php file. The value itself is *purely* cosmetic. No part of ZendTo or any accompanying script ever depends on the value it sees in there. Rather than edit the template, to get rid of it you should just customise the "translation" of the strings in the UI. This is described in ??? http://zend.to/translators.php If you've got preferences.php saying that 'language' => 'en_US', then look in /opt/zendto/config/locale/en_US/LC_MESSAGES In there, edit the "zendto.po" file. Search for the lines msgid "Version %1 has been developed by %2." and msgid "Version %1" Immediately under each line is the "msgstr" which is what the string is translated into. If the msgstr value is "" then the "msgid" value above it is used by default. But if you set something simple like msgstr "Developed by %2." and msgstr " " for them, then the "Version %1" text simply won't appear. Then run /opt/zendto/bin/makelanguages to compile all the .po files into .mo files. If a quick refresh of your browser doesn't show the new content, restart Apache as sometimes it caches stuff it shouldn't. That may sound more complicated than simply editing the template file. But..... When I change the template files in future versions, you won't have to re-apply your edit, or risk ending up with an out-of-date template because you missed the ".rpmnew" version that got created. Instead, your changes to the output for those 2 strings will survive, and the .po files automatically get all the new strings added to them whenever makelanguages is run (which happens as part of the rpm/deb install/upgrade process). This is described on ??? http://zend.to/translators.php and is now the more reliable method of changing the text in the UI to match your own requirements. Hope that helps, Jules. On 13/07/2018 15:16, Ricky Boone wrote: > I thought about that, but wasn't sure it wouldn't cause issues with > future upgrades (specifically with the config/preferences upgrade > scripts), and the intent was to completely remove the version string > from non-administrative users. > > Again, not a major issue, I have the option of changing ZTVERSION, as > well as modifying the template, just thought this could be something > that might be worth implementing at some point.? No worries.? :) > > Thanks for the quick reply. > > On Thu, Jul 12, 2018, 12:31 PM Jules Field > wrote: > > Why not just set "ZTVERSION" in preferences.php to any other > string you > like? > That's exactly why I let you set it. Just change it to "1" or > something > like that. > > Cheers, > Jules. > > On 12/07/2018 16:30, Ricky Boone via ZendTo wrote: > > I think it would be helpful to include an option that disables the > > visibility of the version, at least to non-administrators, that is > > normally rendered at the footer of every page.? While there are > > absolutely other ways to secure a system, or ways that bad actors > > could determine what version you're potentially running, handing out > > information like the version string can be a risk if there is a zero > > day or other vulnerability.? Several best practices related to > > securing a web server include disabling version strings or otherwise > > obfuscating the Server header in Apache httpd, for example: > > > > > https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002) > > > > > For the time being, I'm just clearing out the parts of the > footer.tpl > > template that include this, but I think this would be cleaner to do > > within the config.? If I'm going about this the wrong way, let me > > know, however I'm still of the opinion that publicly announcing this > > level of detail is probably not the most secure option, either. > > > > _______________________________________________ > > 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 > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Trafalgar: Northwesterly but cyclonic at first in southeast, and later in north, 4 or 5. Slight or moderate. Occasional rain. Good, occasionally moderate. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasonp at mwsco.com Thu Jul 19 18:24:18 2018 From: jasonp at mwsco.com (Jason Passow) Date: Thu, 19 Jul 2018 12:24:18 -0500 Subject: [ZendTo] Upgrade gone wrong References: <3012463193-34727@KMS.mwsco.com> Message-ID: I used apt to upgrade to the latest zendto 5.10. ?Now I have several problems. ?The first is it tells me I need libsodium support. ?php -v and php -i | grep sodium below ubuntu:~$ php -v PHP 7.2.7-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jun 22 2018 08:44:50) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies ? ? with Zend OPcache v7.2.7-1+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies ubuntu:~$ php -i |grep sodium sodium sodium support => enabled libsodium headers version => 1.0.16 Also and this may have occurred after the last upgrade but certainly still exists. All virus scans fail. Zend gives the error? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. ?Clam gives an error that this is "not a regular file" ?The file type is irrelevant. ?It happens with txt files, video files, etc. I have disabled scanning for now. ?? Jason Passow | Network Administrator o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com 5150 West 6th Street | Winona, MN?55987 www.mwsco.com ? ? Veteran Owned Small Business -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f3e94a3b-8721-4282-9a20-841ecdd272d6.png Type: image/png Size: 26725 bytes Desc: not available URL: From Jules at Zend.To Fri Jul 20 09:29:21 2018 From: Jules at Zend.To (Jules Field) Date: Fri, 20 Jul 2018 09:29:21 +0100 Subject: [ZendTo] Upgrade gone wrong In-Reply-To: References: <3012463193-34727@KMS.mwsco.com> Message-ID: Please download and run a fresh copy of the ZendTo installer. This should fix most of this lot for you. Upgrades to 5.10+ from anything before 5.09 should be done with the installer. It shouldn't do any harm, but should ensure things are setup correctly. The virus scan problem is *probably* a permissions / group membership problem. If you temporarily give the user www-data a shell of /bin/bash so that you can "su - www-data" (from root), can you then run "clamdscan --fdpass" on some files in /var/zendto/incoming and other places? Cheers, Jules. On 19/07/2018 18:24, Jason Passow via ZendTo wrote: > I used apt to upgrade to the latest zendto 5.10. ?Now I have several > problems. ?The first is it tells me I need libsodium support. ?php -v > and php -i | grep sodium below > ubuntu:~$ php -v > PHP 7.2.7-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jun 22 2018 > 08:44:50) ( NTS ) > Copyright (c) 1997-2018 The PHP Group > Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies > ? ? with Zend OPcache v7.2.7-1+ubuntu16.04.1+deb.sury.org+1, Copyright > (c) 1999-2018, by Zend Technologies > > ubuntu:~$ php -i |grep sodium > sodium > sodium support => enabled > libsodium headers version => 1.0.16 > > Also and this may have occurred after the last upgrade but certainly > still exists. All virus scans fail. Zend gives the error > Upload Error > > The attempt to virus-scan your drop-off failed. Please notify the > system administrator. > > ?Clam gives an error that this is "not a regular file" ?The file type > is irrelevant. ?It happens with txt files, video files, etc. I have > disabled scanning for now. > > *Jason Passow* | Network Administrator > > o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com > 5150 West 6^th Street | Winona, MN?55987 > www.mwsco.com > > > > > /**/ > > /*Veteran Owned Small Business*/ > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut.' - Ernest Hemingway www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f3e94a3b-8721-4282-9a20-841ecdd272d6.png Type: image/png Size: 26725 bytes Desc: not available URL: From jasonp at mwsco.com Fri Jul 20 14:46:03 2018 From: jasonp at mwsco.com (Jason Passow) Date: Fri, 20 Jul 2018 08:46:03 -0500 Subject: [ZendTo] Upgrade gone wrong In-Reply-To: References: <3085552216-5612@KMS.mwsco.com> Message-ID: I was able to download the installer and ran each of the set up scripts individually and things appear to be working except the Clam Anti-Virus. ?(FYI this was a 5.09 to 5.11 upgrade via apt.) www-data at ubuntu:/var/zendto/incoming$ clamdscan --fdpass phpPnYMPZ /var/zendto/incoming/phpPnYMPZ: OK ----------- SCAN SUMMARY ----------- Infected files: 0 Time: 4.663 sec (0 m 4 s) There was already a file in incoming so I used www-data in a bash shell and it was able to scan the file. ? What would be the next steps? ? I agree that it seems to be a permissions issue but I am not sure where. ?? Jason Passow | Network Administrator o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com 5150 West 6th Street | Winona, MN?55987 www.mwsco.com ? ? Veteran Owned Small Business From: Jules Field To: ZendTo Users Cc: Jason Passow Sent: 7/20/2018 3:29 AM Subject: Re: [ZendTo] Upgrade gone wrong Please download and run a fresh copy of the ZendTo installer. This should fix most of this lot for you. Upgrades to 5.10+ from anything before 5.09 should be done with the installer. It shouldn't do any harm, but should ensure things are setup correctly. The virus scan problem is *probably* a permissions / group membership problem. If you temporarily give the user www-data a shell of /bin/bash so that you can "su - www-data" (from root), can you then run "clamdscan --fdpass" on some files in /var/zendto/incoming and other places? Cheers, Jules. On 19/07/2018 18:24, Jason Passow via ZendTo wrote: I used apt to upgrade to the latest zendto 5.10. ?Now I have several problems. ?The first is it tells me I need libsodium support. ?php -v and php -i | grep sodium below ubuntu:~$ php -v PHP 7.2.7-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jun 22 2018 08:44:50) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies ? ? with Zend OPcache v7.2.7-1+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies ubuntu:~$ php -i |grep sodium sodium sodium support => enabled libsodium headers version => 1.0.16 Also and this may have occurred after the last upgrade but certainly still exists. All virus scans fail. Zend gives the error? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. ?Clam gives an error that this is "not a regular file" ?The file type is irrelevant. ?It happens with txt files, video files, etc. I have disabled scanning for now. ?? Jason Passow | Network Administrator o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com 5150 West 6th Street | Winona, MN?55987 www.mwsco.com ? ? Veteran Owned Small Business _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut.' - Ernest Hemingway www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f3e94a3b-8721-4282-9a20-841ecdd272d6.png Type: image/png Size: 26725 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f3e94a3b-8721-4282-9a20-841ecdd272d6.png Type: image/png Size: 26725 bytes Desc: not available URL: From Jules at Zend.To Fri Jul 20 15:20:43 2018 From: Jules at Zend.To (Jules Field) Date: Fri, 20 Jul 2018 15:20:43 +0100 Subject: [ZendTo] Upgrade gone wrong In-Reply-To: References: <3085552216-5612@KMS.mwsco.com> Message-ID: Jason, I hit this problem myself once while writing the installer. And I can't for the life of me remember the fix. :-( Try restarting clamd and then using the "--verbose" option with clamdscan to see if it helps at all. What you can also try is, within preferences.php, just remove the "--fdpass" option. What you don't want to have to do is back off from using "clamdscan" to just "clamscan". The startup time of clamscan is very long. On 20/07/2018 14:46, Jason Passow wrote: > I was able to download the installer and ran each of the set up > scripts individually Each separate script realises that it isn't being run from ../install.sh and works around that fact so you can use the stages independently. The install.sh basically just calls each one in turn with a "Should I" question on the front. install.sh itself is extremely short and simple. Cheers, Jules. > and things appear to be working except the Clam Anti-Virus. ?(FYI this > was a 5.09 to 5.11 upgrade via apt.) > > www-data at ubuntu:/var/zendto/incoming$ clamdscan --fdpass phpPnYMPZ > /var/zendto/incoming/phpPnYMPZ: OK > > ----------- SCAN SUMMARY ----------- > Infected files: 0 > Time: 4.663 sec (0 m 4 s) > > > There was already a file in incoming so I used www-data in a bash > shell and it was able to scan the file. ? What would be the next > steps? ? I agree that it seems to be a permissions issue but I am not > sure where. > > *Jason Passow* | Network Administrator > > o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com > 5150 West 6^th Street | Winona, MN?55987 > www.mwsco.com > > > > > /**/ > > /*Veteran Owned Small Business*/ > > > > > *From: * Jules Field > *To: * ZendTo Users > *Cc: * Jason Passow > *Sent: * 7/20/2018 3:29 AM > *Subject: * Re: [ZendTo] Upgrade gone wrong > > Please download and run a fresh copy of the ZendTo installer. This > should fix most of this lot for you. > Upgrades to 5.10+ from anything before 5.09 should be done with > the installer. It shouldn't do any harm, but should ensure things > are setup correctly. > > The virus scan problem is *probably* a permissions / group > membership problem. > If you temporarily give the user www-data a shell of /bin/bash so > that you can "su - www-data" (from root), can you then run > "clamdscan --fdpass" on some files in /var/zendto/incoming and > other places? > > Cheers, > Jules. > > On 19/07/2018 18:24, Jason Passow via ZendTo wrote: >> I used apt to upgrade to the latest zendto 5.10. ?Now I have >> several problems. ?The first is it tells me I need libsodium >> support. ?php -v and php -i | grep sodium below >> ubuntu:~$ php -v >> PHP 7.2.7-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Jun 22 >> 2018 08:44:50) ( NTS ) >> Copyright (c) 1997-2018 The PHP Group >> Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies >> ? ? with Zend OPcache v7.2.7-1+ubuntu16.04.1+deb.sury.org+1, >> Copyright (c) 1999-2018, by Zend Technologies >> >> ubuntu:~$ php -i |grep sodium >> sodium >> sodium support => enabled >> libsodium headers version => 1.0.16 >> >> Also and this may have occurred after the last upgrade but >> certainly still exists. All virus scans fail. Zend gives the error >> Upload Error >> >> The attempt to virus-scan your drop-off failed. Please notify >> the system administrator. >> >> ?Clam gives an error that this is "not a regular file" ?The file >> type is irrelevant. ?It happens with txt files, video files, etc. >> I have disabled scanning for now. >> >> *Jason Passow* | Network Administrator >> >> o: (507) 494-5178 |?c: (507) 450-8178 | jasonp at mwsco.com >> 5150 West 6^th Street | Winona, MN?55987 >> www.mwsco.com >> >> >> >> >> /**/ >> >> /*Veteran Owned Small Business*/ >> >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Always do sober what you said you'd do drunk. That will teach you > to keep your mouth shut.' - Ernest Hemingway > > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > 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 PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f3e94a3b-8721-4282-9a20-841ecdd272d6.png Type: image/png Size: 26725 bytes Desc: not available URL: From Jake.Sallee at umhb.edu Wed Jul 25 14:54:38 2018 From: Jake.Sallee at umhb.edu (Sallee, Jake) Date: Wed, 25 Jul 2018 13:54:38 +0000 Subject: [ZendTo] unable to login References: Message-ID: All: I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. No one is able to login when they try they get: Authentication Error The username or password was incorrect. However I have verified my username and password and still I am not able to log in. I have been scouring the logs without much success. the only thing I see is this when I get the error on login: ==> /var/log/apache2/error.log <== [Wed Jul 25 08:32:17.700721 2018] [php7:notice] [pid 3496] [client 10.11.0.54:47742] PHP Notice: Undefined index: SMTPsetFromToSender in /opt/zendto/lib/NSSDropbox.php on line 317 Line 317 in the referenced file is this: $this->_SMTPsetFromToSender = $prefs['SMTPsetFromToSender']; It seems to be referencing an non-existent setting in the preferences.php file, but commenting this line out changed nothing. I have firewall logs showing there is communication going to the AD servers and this setup was working but then stopped. As far as I can tell the AD integration bits are setup correctly ... I' am at a loss here. Is there another log file I can look at to get some more info? Is there some other troubleshooting step I can use (like a debug mode somewhere) to see more info? Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 From deq at pattishall.com Wed Jul 25 15:05:44 2018 From: deq at pattishall.com (Dale E. Qualls) Date: Wed, 25 Jul 2018 14:05:44 +0000 Subject: [ZendTo] unable to login In-Reply-To: References: Message-ID: Did the password for the AD bind user get changed or did the AD bind user get moved to a different location in the AD tree? [http://images.pattishall.com/images/pattishalllogo-170.jpg] Dale E. Qualls Director of Information Technology Pattishall, McAuliffe, Newbury, Hilliard & Geraldson LLP 200 South Wacker Drive, Suite 2900 Chicago, IL 60606-5896 Direct: (312) 554-7979 Main: (312) 554-8000 Fax: (312) 554-8015 deq at pattishall.com www.pattishall.com Follow us on Twitter [http://images.pattishall.com/images/25pixelimage.gif] [http://images.pattishall.com/images/25pixelimage.gif] [http://images.pattishall.com/images/blf-badge.jpg] [http://images.pattishall.com/images/25pixelimage.gif] Pattishall Ranks GOLD in the United States and in Illinois in the prestigious WTR 1000 [http://images.pattishall.com/images/25pixelimage.gif] [http://images.pattishall.com/images/2014chambers-65.jpg] [http://images.pattishall.com/images/25pixelimage.gif] [http://images.pattishall.com/images/2013gototop500.jpg] ________________________________ The preceding message and any attachments may contain confidential information protected by the attorney-client or other privilege. You may not forward this message or any attachments without the permission of the sender. If you believe that it has been sent to you in error, please reply to the sender that you received the message in error and then delete it. Nothing in this email message, including the typed name of the sender and/or this signature block, is intended to constitute an electronic signature unless a specific statement to the contrary is included in the message. ________________________________ From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Sallee, Jake via ZendTo Sent: Wednesday, July 25, 2018 8:55 AM To: ZendTo Users Cc: Sallee, Jake Subject: [ZendTo] unable to login External email, exercise caution. All: I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. No one is able to login when they try they get: Authentication Error The username or password was incorrect. However I have verified my username and password and still I am not able to log in. I have been scouring the logs without much success. the only thing I see is this when I get the error on login: ==> /var/log/apache2/error.log <== [Wed Jul 25 08:32:17.700721 2018] [php7:notice] [pid 3496] [client 10.11.0.54:47742] PHP Notice: Undefined index: SMTPsetFromToSender in /opt/zendto/lib/NSSDropbox.php on line 317 Line 317 in the referenced file is this: $this->_SMTPsetFromToSender = $prefs['SMTPsetFromToSender']; It seems to be referencing an non-existent setting in the preferences.php file, but commenting this line out changed nothing. I have firewall logs showing there is communication going to the AD servers and this setup was working but then stopped. As far as I can tell the AD integration bits are setup correctly ... I' am at a loss here. Is there another log file I can look at to get some more info? Is there some other troubleshooting step I can use (like a debug mode somewhere) to see more info? Jake Sallee Godfather of Bandwidth System Engineer 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.a.young at durham.ac.uk Wed Jul 25 15:19:23 2018 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 25 Jul 2018 15:19:23 +0100 (BST) Subject: [ZendTo] unable to login In-Reply-To: References: Message-ID: On Wed, 25 Jul 2018, Sallee, Jake via ZendTo wrote: > All: > > I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. > > No one is able to login when they try they get: > > Authentication Error > The username or password was incorrect. > > However I have verified my username and password and still I am not able to log in. > > I have been scouring the logs without much success. the only thing I see is this when I get the error on login: Is this an update from zendto 4 and did you do any restrictions of login by group? If so, then the mechanism for AD groups has changed and doesn't work in some setups. In any case if you have group restrictions then try disabling them and see if it makes a difference to whether you can log in. Michael Young From Jules at Zend.To Wed Jul 25 15:23:48 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 25 Jul 2018 15:23:48 +0100 Subject: [ZendTo] unable to login In-Reply-To: References: Message-ID: Jake, The PHP notice you got shows that you haven't used ??? /opt/zendto/bin/upgrade_preferences_php and/or ??? /opt/zendto/bin/upgrade_zendto_conf to upgrade those files. Once you've upgraded your preferences.php and zendto.conf files correctly, all the expected settings will be in them. For AD authentication troubleshooting, please see http://zend.to/activedirectory.php Cheers, Jules. On 25/07/2018 14:54, Sallee, Jake via ZendTo wrote: > All: > > I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. > > No one is able to login when they try they get: > > Authentication Error > The username or password was incorrect. > > However I have verified my username and password and still I am not able to log in. > > I have been scouring the logs without much success. the only thing I see is this when I get the error on login: > > ==> /var/log/apache2/error.log <== > [Wed Jul 25 08:32:17.700721 2018] [php7:notice] [pid 3496] [client 10.11.0.54:47742] PHP Notice: Undefined index: SMTPsetFromToSender in /opt/zendto/lib/NSSDropbox.php on line 317 > > Line 317 in the referenced file is this: > > $this->_SMTPsetFromToSender = $prefs['SMTPsetFromToSender']; > > It seems to be referencing an non-existent setting in the preferences.php file, but commenting this line out changed nothing. > > I have firewall logs showing there is communication going to the AD servers and this setup was working but then stopped. As far as I can tell the AD integration bits are setup correctly ... I' am at a loss here. > > Is there another log file I can look at to get some more info? Is there some other troubleshooting step I can use (like a debug mode somewhere) to see more info? > > Jake Sallee > Godfather of Bandwidth > System Engineer > 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 'Probability factor of one to one. We have normality. I repeat, we have normality. Anything you still can't cope with is therefore your own problem.' - Trillian, The Hitch Hikers Guide to the Galaxy www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jake.Sallee at umhb.edu Wed Jul 25 15:28:07 2018 From: Jake.Sallee at umhb.edu (Sallee, Jake) Date: Wed, 25 Jul 2018 14:28:07 +0000 Subject: [ZendTo] unable to login In-Reply-To: References: , <368981bd8fa249b3b90f9f37e02c6d24@umhb.edu> Message-ID: Thanks for the response: It is an upgrade, but the upgrade was from 5.01 to 5.02, 5.01 was the initial install. Also, I do not have group restrictions enabled. Keep the suggestions coming though! Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: M A Young Sent: Wednesday, July 25, 2018 9:19 AM To: Sallee, Jake via ZendTo Cc: Sallee, Jake Subject: Re: [ZendTo] unable to login On Wed, 25 Jul 2018, Sallee, Jake via ZendTo wrote: > All: > > I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. > > No one is able to login when they try they get: > > Authentication Error > The username or password was incorrect. > > However I have verified my username and password and still I am not able to log in. > > I have been scouring the logs without much success. the only thing I see is this when I get the error on login: Is this an update from zendto 4 and did you do any restrictions of login by group? If so, then the mechanism for AD groups has changed and doesn't work in some setups. In any case if you have group restrictions then try disabling them and see if it makes a difference to whether you can log in. Michael Young From Jake.Sallee at umhb.edu Wed Jul 25 16:51:32 2018 From: Jake.Sallee at umhb.edu (Sallee, Jake) Date: Wed, 25 Jul 2018 15:51:32 +0000 Subject: [ZendTo] unable to login In-Reply-To: References: , <1493fc5ea44642938e9a651d458ec6dd@umhb.edu> Message-ID: Jules: Thank you for your response. I read the upgrade instructions but I apparently did not read them closely enough. I read the bit about running the two commands as only being necessary if you are upgrading from a version earlier than 5.0. My apologies, it was my mistake. I did run the upgrade commands(and a reboot for good measure) and it did take care of the missing config option for me and the error is no longer showing up in the log file, so that is nice. But I still cannot log in. The ldap search command works using the info from my current preferences.php file, shouldn't that mean it should be working? What is really weird is when I do a packet capture I can see the bind response for the user logging in (me in this case) succeeds but the web page still says it failed ... is there a log file I can look at or something? Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor WWW.UMHB.EDU 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 ________________________________________ From: Jules Field Sent: Wednesday, July 25, 2018 9:23 AM To: ZendTo Users Cc: Sallee, Jake Subject: Re: [ZendTo] unable to login Jake, The PHP notice you got shows that you haven't used /opt/zendto/bin/upgrade_preferences_php and/or /opt/zendto/bin/upgrade_zendto_conf to upgrade those files. Once you've upgraded your preferences.php and zendto.conf files correctly, all the expected settings will be in them. For AD authentication troubleshooting, please see https://urldefense.proofpoint.com/v2/url?u=http-3A__zend.to_activedirectory.php&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=YoqPu2mQX7tUfQl8dXTkzGHuKZszFpEyBAE2uYB-kyk&e= Cheers, Jules. On 25/07/2018 14:54, Sallee, Jake via ZendTo wrote: > All: > > I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. > > No one is able to login when they try they get: > > Authentication Error > The username or password was incorrect. > > However I have verified my username and password and still I am not able to log in. > > I have been scouring the logs without much success. the only thing I see is this when I get the error on login: > > ==> /var/log/apache2/error.log <== > [Wed Jul 25 08:32:17.700721 2018] [php7:notice] [pid 3496] [client 10.11.0.54:47742] PHP Notice: Undefined index: SMTPsetFromToSender in /opt/zendto/lib/NSSDropbox.php on line 317 > > Line 317 in the referenced file is this: > > $this->_SMTPsetFromToSender = $prefs['SMTPsetFromToSender']; > > It seems to be referencing an non-existent setting in the preferences.php file, but commenting this line out changed nothing. > > I have firewall logs showing there is communication going to the AD servers and this setup was working but then stopped. As far as I can tell the AD integration bits are setup correctly ... I' am at a loss here. > > Is there another log file I can look at to get some more info? Is there some other troubleshooting step I can use (like a debug mode somewhere) to see more info? > > Jake Sallee > Godfather of Bandwidth > System Engineer > University of Mary Hardin-Baylor > http://WWW.UMHB.EDU > > 900 College St. > Belton, Texas > 76513 > > Fone: 254-295-4658 > Phax: 254-295-4221 > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > https://urldefense.proofpoint.com/v2/url?u=http-3A__jul.es_mailman_listinfo_zendto&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=Z2YAnd5KuimjzLxfzaxEnjtbZX0J-9k6Na60pl5V7Qs&e= Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Probability factor of one to one. We have normality. I repeat, we have normality. Anything you still can't cope with is therefore your own problem.' - Trillian, The Hitch Hikers Guide to the Galaxy https://urldefense.proofpoint.com/v2/url?u=http-3A__www.Zend.To&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=r_o7N-YZzAEiryEcRfnxnwyLaFR3nV848AWPI1EEL4c&e= Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From pedrosi at millercanfield.com Wed Jul 25 17:04:08 2018 From: pedrosi at millercanfield.com (Pedrosi, Derek G.) Date: Wed, 25 Jul 2018 16:04:08 +0000 Subject: [ZendTo] ClamAV fail References: Message-ID: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this... Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I've since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details... >From ZendTo log... 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with >From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line... clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Jul 25 17:17:54 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 25 Jul 2018 17:17:54 +0100 Subject: [ZendTo] unable to login In-Reply-To: References: <1493fc5ea44642938e9a651d458ec6dd@umhb.edu> Message-ID: <1438a9df-684c-8977-623c-7df7b6a66429@Zend.To> On 25/07/2018 16:51, Sallee, Jake via ZendTo wrote: > Jules: > > Thank you for your response. I read the upgrade instructions but I apparently did not read them closely enough. I read the bit about running the two commands as only being necessary if you are upgrading from a version earlier than 5.0. > > My apologies, it was my mistake. You should always run them after any ZendTo upgrade, as I may well have added or removed preferences.php settings or zendto.conf strings. > > I did run the upgrade commands(and a reboot for good measure) and it did take care of the missing config option for me and the error is no longer showing up in the log file, so that is nice. > > But I still cannot log in. > > The ldap search command works using the info from my current preferences.php file, shouldn't that mean it should be working? Yes, it should. With the bind username+password blacked out, would you like to show us your AD settings in? preferences.php? Also, I assume you've got "authenticator" set to "AD", and you haven't got *multiple* lines in preferences.php setting the value of "authenticator"? That is always worth checking... > > What is really weird is when I do a packet capture I can see the bind response for the user logging in (me in this case) succeeds but the web page still says it failed ... is there a log file I can look at or something? If the bind is working, that implies the username+password check is succeeding. After that, it reads some attributes for the user, so it may be that bit that's failing. The relevant code is in /opt/zendto/lib/NSSADAuthenticator.php, it's pretty straightforward code. (In that file you will find most of the code replicated in 2 functions. If you add some calls to "NSSError()" and they don't appear in the web page response to your login attempt, you've probably added them in the wrong function! You can just add things like ??? NSSError("My debug output text", "Debug"); into the code and those should appear as error messages in the web page when you try to login. Cheers, Jules. > > Jake Sallee > Godfather of Bandwidth > System Engineer > University of Mary Hardin-Baylor > WWW.UMHB.EDU > > 900 College St. > Belton, Texas > 76513 > > Fone: 254-295-4658 > Phax: 254-295-4221 > > ________________________________________ > From: Jules Field > Sent: Wednesday, July 25, 2018 9:23 AM > To: ZendTo Users > Cc: Sallee, Jake > Subject: Re: [ZendTo] unable to login > > Jake, > > The PHP notice you got shows that you haven't used > /opt/zendto/bin/upgrade_preferences_php > and/or > /opt/zendto/bin/upgrade_zendto_conf > to upgrade those files. Once you've upgraded your preferences.php and > zendto.conf files correctly, all the expected settings will be in them. > > For AD authentication troubleshooting, please see > https://urldefense.proofpoint.com/v2/url?u=http-3A__zend.to_activedirectory.php&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=YoqPu2mQX7tUfQl8dXTkzGHuKZszFpEyBAE2uYB-kyk&e= > > Cheers, > Jules. > > > On 25/07/2018 14:54, Sallee, Jake via ZendTo wrote: >> All: >> >> I'm having a weird issue in ZendTo version 5.02 with MS AD as the backend user DB. >> >> No one is able to login when they try they get: >> >> Authentication Error >> The username or password was incorrect. >> >> However I have verified my username and password and still I am not able to log in. >> >> I have been scouring the logs without much success. the only thing I see is this when I get the error on login: >> >> ==> /var/log/apache2/error.log <== >> [Wed Jul 25 08:32:17.700721 2018] [php7:notice] [pid 3496] [client 10.11.0.54:47742] PHP Notice: Undefined index: SMTPsetFromToSender in /opt/zendto/lib/NSSDropbox.php on line 317 >> >> Line 317 in the referenced file is this: >> >> $this->_SMTPsetFromToSender = $prefs['SMTPsetFromToSender']; >> >> It seems to be referencing an non-existent setting in the preferences.php file, but commenting this line out changed nothing. >> >> I have firewall logs showing there is communication going to the AD servers and this setup was working but then stopped. As far as I can tell the AD integration bits are setup correctly ... I' am at a loss here. >> >> Is there another log file I can look at to get some more info? Is there some other troubleshooting step I can use (like a debug mode somewhere) to see more info? >> >> Jake Sallee >> Godfather of Bandwidth >> System Engineer >> University of Mary Hardin-Baylor >> http://WWW.UMHB.EDU >> >> 900 College St. >> Belton, Texas >> 76513 >> >> Fone: 254-295-4658 >> Phax: 254-295-4221 >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> https://urldefense.proofpoint.com/v2/url?u=http-3A__jul.es_mailman_listinfo_zendto&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=Z2YAnd5KuimjzLxfzaxEnjtbZX0J-9k6Na60pl5V7Qs&e= > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > 'Probability factor of one to one. We have normality. I repeat, we > have normality. Anything you still can't cope with is therefore > your own problem.' - Trillian, The Hitch Hikers Guide to the Galaxy > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.Zend.To&d=DwIDaQ&c=61yQaCoNVjQr1ah003i6yA&r=hv6FWbB_1Tauwq1un9h_XR4pflYMFHr0Ag1rvcLKIQA&m=aPJXY5gIxyke0vsmlY9i_bOTQpaYFx8EeKemi8iBeFg&s=r_o7N-YZzAEiryEcRfnxnwyLaFR3nV848AWPI1EEL4c&e= > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Dogger, Fisher, German Bight: East 2 or 3, occasionally 4 later. Smooth or slight. Fair. Good. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Wed Jul 25 17:26:07 2018 From: Jules at Zend.To (Jules Field) Date: Wed, 25 Jul 2018 17:26:07 +0100 Subject: [ZendTo] ClamAV fail In-Reply-To: References: Message-ID: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and users were > unable to drop files.? No changes were made. > > User see this? > > *Upload Error* > > > > > *The attempt to virus-scan your drop-off failed. Please notify the > system administrator.* > > I?ve since disable AV scan from the preferences.php (it was > 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users > can drop files. > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of > dropped-off files /var/zendto/incoming/phpLfUrV9 > /var/zendto/incoming/phpf6ExDv for USER failed with > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, > ARCH: x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul > 25 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: > 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, > sigs: 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, > sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 > signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 > > Now, I can scan files manually via the command line? > > clamscan --verbose? /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > Anywhere else to look? > > derek > > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trumpjk at gmail.com Wed Jul 25 19:06:20 2018 From: trumpjk at gmail.com (John Trump) Date: Wed, 25 Jul 2018 14:06:20 -0400 Subject: [ZendTo] Drop-off Request Email References: Message-ID: I have zendto 5.11.1 rpm installed on a Red Hat 6 server. When a user sends a drop-off request to an external user who does not have a login they also forward the email about sending files before drop-off request arrives. It looks like below: The request for a Drop-off has been sent to Tom at EMAILADDR. It is valid for 24 hours. If the recipient wants to send files to you before their request arrives, they should 1. Go to *Link to my server* 2. Select "Drop-off Files" 3. Enter the request code "000 000 000" 4. Click on the "Next" button You may close this window. If the user tries to use the link in this email they are taken to the login page but do not get the option to "Drop-off Files" What setting controls this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From trumpjk at gmail.com Wed Jul 25 19:52:58 2018 From: trumpjk at gmail.com (John Trump) Date: Wed, 25 Jul 2018 14:52:58 -0400 Subject: [ZendTo] Drop-off Request Email In-Reply-To: References: Message-ID: I found the issue. it was a problem with one of the template files. On Wed, Jul 25, 2018 at 2:46 PM John Trump via ZendTo wrote: > I have zendto 5.11.1 rpm installed on a Red Hat 6 server. When a user > sends a drop-off request to an external user who does not have a login they > also forward the email about sending files before drop-off request arrives. > It looks like below: > > > > The request for a Drop-off has been sent to Tom at EMAILADDR. It is valid > for 24 hours. > > If the recipient wants to send files to you before their request arrives, > they should > > 1. Go to *Link to my server* > 2. Select "Drop-off Files" > 3. Enter the request code "000 000 000" > 4. Click on the "Next" button > > You may close this window. > > > If the user tries to use the link in this email they are taken to the > login page but do not get the option to "Drop-off Files" > > > What setting controls this? > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedrosi at millercanfield.com Thu Jul 26 14:50:49 2018 From: pedrosi at millercanfield.com (Pedrosi, Derek G.) Date: Thu, 26 Jul 2018 13:50:49 +0000 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: This is my production server, and no changes were made; it just started throwing the error. Running clamdscan: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 ERROR: Parse error at line 79: Unknown option StatsEnabled ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# clamscan --version ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la total 36 drwxr-xr-x 5 root root 4096 Jul 26 09:49 . drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d derek From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Jules Field via ZendTo Sent: Wednesday, July 25, 2018 12:26 PM To: Pedrosi, Derek G. via ZendTo ; ZendTo Users Cc: Jules Field Subject: Re: [ZendTo] ClamAV fail Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details? From ZendTo log? 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line? clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.dippery at uky.edu Thu Jul 26 15:25:46 2018 From: kyle.dippery at uky.edu (Dippery, Kyle) Date: Thu, 26 Jul 2018 14:25:46 +0000 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> , Message-ID: That looks like something I saw on a non-Zendto system just this morning. The clamd.conf file probably got changed during the latest clamav-daemon upgrade. It will probably be happy if you edit /etc/clamav/clamd.conf, remove the StatsEnabled line, save the file, and restart clamav. Also if you're not using the AllowSupplementaryGroups option (line 11 of the clamd.conf file), go ahead and remove that line, too, or something like this will happen when they get around to taking it out of the code. Cheers, Kyle -- Kyle Dippery Engineering Computing Services 219 RMB 859-257-1346 ________________________________________ From: ZendTo on behalf of Pedrosi, Derek G. via ZendTo Sent: Thursday, July 26, 2018 9:50 AM To: ZendTo Users Cc: Pedrosi, Derek G. Subject: Re: [ZendTo] ClamAV fail This is my production server, and no changes were made; it just started throwing the error. Running clamdscan: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 ERROR: Parse error at line 79: Unknown option StatsEnabled ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# clamscan --version ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la total 36 drwxr-xr-x 5 root root 4096 Jul 26 09:49 . drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d derek From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Jules Field via ZendTo Sent: Wednesday, July 25, 2018 12:26 PM To: Pedrosi, Derek G. via ZendTo ; ZendTo Users Cc: Jules Field Subject: Re: [ZendTo] ClamAV fail Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details? >From ZendTo log? 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with >From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line? clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 From Jules at Zend.To Thu Jul 26 15:26:53 2018 From: Jules at Zend.To (Jules Field) Date: Thu, 26 Jul 2018 15:26:53 +0100 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: Derek, On 26/07/2018 14:50, Pedrosi, Derek G. wrote: > > This is my production server, and no changes were made; > Ah, the famous "But I didn't change anything" defence. :-) :-) > > it just started throwing the error. > Ah, but changes *were* made. Just possibly not by you. :-) Someone (or more likely some*thing*) did a "yum upgrade" or an "apt upgrade", and replaced the copy of ClamAV that was running. You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? That was modified yesterday morning, which is probably shortly before it all stopped working. From your /etc/clamav/clamd.conf file, based on the output from "clamdscan" below, you should remove the lines that start "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd service ("service clamd restart" will *probably* do the trick on almost any Linux variant). Then try that clamdscan command again and see if it gets further. Cheers, Jules. > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout > preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 > > root at ZendTo5:/opt/zendto/config# nano? /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# ls? /etc/clamav -la > > total 36 > > drwxr-xr-x 5 root?? root 4096 Jul 26 09:49 . > > drwxr-xr-x 94 root?? root 4096 Jul 25 06:06 .. > > -rw-r--r-- 1 root?? root 2059 Mar? 5 10:19 clamd.conf > > -rw-r--r-- 1 root?? root 1999 Jul 25 06:06 clamd.conf.ucf-dist > > -rw-r--r-- 1 root?? root 2060 Mar? 5 10:19 clamd.conf.zendto > > -r--r--r-- 1 clamav adm?? 702 Jul 25 06:06 freshclam.conf > > drwxr-xr-x 2 root?? root 4096 Jan 29 11:14 onerrorexecute.d > > drwxr-xr-x 2 root?? root 4096 Jan 29 11:14 onupdateexecute.d > > drwxr-xr-x 2 root?? root 4096 Jan 29 11:14 virusevent.d > > derek > > *From:*ZendTo [mailto:zendto-bounces at zend.to] *On Behalf Of *Jules > Field via ZendTo > *Sent:* Wednesday, July 25, 2018 12:26 PM > *To:* Pedrosi, Derek G. via ZendTo ; ZendTo Users > > *Cc:* Jules Field > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > Testing it with "clamscan" won't help. It's "clamdscan" that has to > work, which is a very different beast. > "clamscan" just does it all at once (which is why it takes so long). > "clamdscan" uses the "clamd" process to actually do the scanning, and > hence is much faster as there's no startup time while it loads and > compiles all the virus signatures. > > If it works with a small text file, but not an archive or docx file, > then you've probably run out of disk space in wherever clamd is trying > to unpack the archive. > > Otherwise, it is almost always permissions/ownership problems. > You shouldn't do any harm by fetching a new copy of the ZendTo > installer and *just* doing the "Setup ClamAV" section. > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > If both of those succeed, then start a big upload going in ZendTo. > This will force some data (with the right permissions) into > /var/zendto/incoming. While it's running, do "clamdscan > /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". > > By the time you've done all that lot, you've probably got some errors > from ClamAV which will help narrow down the cause. > > When you've fixed it, remember to put your "/etc/passwd" file back so > the shell says "/sbin/nologin" and run the "pwconv" command again. > > Hope that helps, > Jules. > > On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and users > were unable to drop files.? No changes were made. > > User see this? > > *Upload Error* > > > > > *The attempt to virus-scan your drop-off failed. Please notify the > system administrator.* > > I?ve since disable AV scan from the preferences.php (it was > 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now > users can drop files. > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of > dropped-off files? /var/zendto/incoming/phpLfUrV9 > /var/zendto/incoming/phpf6ExDv for USER failed with > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: > linux-gnu, ARCH: x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed > Jul 25 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, > sigs: 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: > 24781, sigs: 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: > 325, sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 > signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 > > Now, I can scan files manually via the command line? > > clamscan --verbose? /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > Anywhere else to look? > > derek > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, > becoming rough in west. Rain later. Good, occasionally poor. > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Ensanguining the skies How heavily it dies Into the west away; Past touch and sight and sound Not further to be found, How hopeless under ground Falls the remorseful day.' - A.E.Houseman www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.a.young at durham.ac.uk Thu Jul 26 16:04:13 2018 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 26 Jul 2018 16:04:13 +0100 (BST) Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: On Thu, 26 Jul 2018, Pedrosi, Derek G. via ZendTo wrote: > > This is my production server, and no changes were made; it just started > throwing the error. > > ? > > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > ? > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 If this is clamav from EPEL then the 0.100.1 packages were only released in the last couple of days so I think it is likely someone or something has updated your clamav packages recently. In any case clamav must have been updated since July 9th which is when 0.100.1 was released. Michael Young From pedrosi at millercanfield.com Thu Jul 26 16:07:47 2018 From: pedrosi at millercanfield.com (Pedrosi, Derek G.) Date: Thu, 26 Jul 2018 15:07:47 +0000 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: Jules, I?m the only one with ANY access to this system (other than web), and I was on vacation. Nevertheless, I?ve comment out the stats lines in clamd.conf and then I received this error. root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Likewise in ZendTo the log shows? Error: Virus scan of dropped-off files /var/zendto/incoming/phpSAkd0U for dgpedrosi failed with ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Then from clamd.conf I commented out these lines #LocalSocket /var/run/clamav/clamd.ctl #FixStaleSocket true And now I can run a command line scan without error: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) root at ZendTo5:/opt/zendto/config# But ZendTo will still not AV scan, from the ZendTo log: Error: Virus scan of dropped-off files /var/zendto/incoming/phpcz1Ojf for dgpedrosi failed with ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: root at ZendTo5:/opt/zendto/config# service --status-all [ + ] acpid [ + ] apache-htcacheclean [ + ] apache2 [ + ] apparmor [ + ] apport [ + ] atd [ - ] bootmisc.sh [ - ] checkfs.sh [ - ] checkroot-bootclean.sh [ - ] checkroot.sh [ - ] clamav-daemon [ + ] clamav-freshclam [ + ] console-setup [ + ] cron But I did reboot the server, and I?m still seeing the issue. ??? From: Jules Field [mailto:Jules at Zend.To] Sent: Thursday, July 26, 2018 10:27 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Derek, On 26/07/2018 14:50, Pedrosi, Derek G. wrote: This is my production server, and no changes were made; Ah, the famous "But I didn't change anything" defence. :-) :-) it just started throwing the error. Ah, but changes *were* made. Just possibly not by you. :-) Someone (or more likely some*thing*) did a "yum upgrade" or an "apt upgrade", and replaced the copy of ClamAV that was running. You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? That was modified yesterday morning, which is probably shortly before it all stopped working. From your /etc/clamav/clamd.conf file, based on the output from "clamdscan" below, you should remove the lines that start "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd service ("service clamd restart" will *probably* do the trick on almost any Linux variant). Then try that clamdscan command again and see if it gets further. Cheers, Jules. Running clamdscan: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 ERROR: Parse error at line 79: Unknown option StatsEnabled ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# clamscan --version ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la total 36 drwxr-xr-x 5 root root 4096 Jul 26 09:49 . drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d derek From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Jules Field via ZendTo Sent: Wednesday, July 25, 2018 12:26 PM To: Pedrosi, Derek G. via ZendTo ; ZendTo Users Cc: Jules Field Subject: Re: [ZendTo] ClamAV fail Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details? From ZendTo log? 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line? clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Ensanguining the skies How heavily it dies Into the west away; Past touch and sight and sound Not further to be found, How hopeless under ground Falls the remorseful day.' - A.E.Houseman www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Jul 26 16:13:18 2018 From: Jules at Zend.To (Jules Field) Date: Thu, 26 Jul 2018 16:13:18 +0100 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: Derek, On 26/07/2018 16:07, Pedrosi, Derek G. wrote: > > Jules, > > I?m the only one with ANY access to this system (other than web), and > I was on vacation. > Hence my suggestion of some*thing*. Such as your cron daemon, which appears to have been installing updates (they might well have been tagged as security updates, so got automatically installed). Having read your lines below, have you tried this bit I suggested in my original reply to you? If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* What does that lot output? You not only need to get the location of the LocalSocket correct enough for clamd to start and clamdscan to talk to it, but freshclam.conf needs to know where it is too, or else freshclam can't tell clamd that its signatures have been updated and hence needs to restart itself. Cheers, Jules. > > Nevertheless, I?ve comment out the stats lines in clamd.conf and then > I received this error. > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > Likewise in ZendTo the log shows? > > Error: Virus scan of dropped-off files? /var/zendto/incoming/phpSAkd0U > for dgpedrosi failed with ERROR: Could not connect to clamd on > LocalSocket /var/run/clamav/clamd.ctl: No such file or directory > ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 > Time: 0.000 sec (0 m 0 s) > > Then from clamd.conf I commented out these lines > > #LocalSocket /var/run/clamav/clamd.ctl > > #FixStaleSocket true > > And now I can run a command line scan without error: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > root at ZendTo5:/opt/zendto/config# > > But ZendTo will still not AV scan, from the ZendTo log: > > Error: Virus scan of dropped-off files? /var/zendto/incoming/phpcz1Ojf > for dgpedrosi failed with? ----------- SCAN SUMMARY ----------- > Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) > > Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: > > root at ZendTo5:/opt/zendto/config# service --status-all > > [ + ]? acpid > > [ + ]? apache-htcacheclean > > [ + ]? apache2 > > [ + ]? apparmor > > [ + ]? apport > > [ + ]? atd > > [ - ]? bootmisc.sh > > [ - ]? checkfs.sh > > [ - ]? checkroot-bootclean.sh > > [ - ]? checkroot.sh > > [ - ]? clamav-daemon > > [ + ]? clamav-freshclam > > [ + ]? console-setup > > [ + ]? cron > > But I did reboot the server, and I?m still seeing the issue. > > ??? > > *From:*Jules Field [mailto:Jules at Zend.To] > *Sent:* Thursday, July 26, 2018 10:27 AM > *To:* Pedrosi, Derek G. ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > On 26/07/2018 14:50, Pedrosi, Derek G. wrote: > > This is my production server, and no changes were made; > > Ah, the famous "But I didn't change anything" defence. :-) :-) > > it just started throwing the error. > > Ah, but changes *were* made. Just possibly not by you. :-) > Someone (or more likely some*thing*) did a "yum upgrade" or an "apt > upgrade", and replaced the copy of ClamAV that was running. > You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? > That was modified yesterday morning, which is probably shortly before > it all stopped working. > > From your /etc/clamav/clamd.conf file, based on the output from > "clamdscan" below, you should remove the lines that start > "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd > service ("service clamd restart" will *probably* do the trick on > almost any Linux variant). Then try that clamdscan command again and > see if it gets further. > > Cheers, > Jules. > > > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout > preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups at > line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 > > root at ZendTo5:/opt/zendto/config# nano? /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# ls? /etc/clamav -la > > total 36 > > drwxr-xr-x? 5 root root 4096 Jul 26 09:49 . > > drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. > > -rw-r--r--? 1 root root 2059 Mar? 5 10:19 clamd.conf > > -rw-r--r--? 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist > > -rw-r--r--? 1 root root 2060 Mar? 5 10:19 clamd.conf.zendto > > -r--r--r--? 1 clamav adm?? 702 Jul 25 06:06 freshclam.conf > > drwxr-xr-x? 2 root root 4096 Jan 29 11:14 onerrorexecute.d > > drwxr-xr-x? 2 root root 4096 Jan 29 11:14 onupdateexecute.d > > drwxr-xr-x? 2 root root 4096 Jan 29 11:14 virusevent.d > > derek > > *From:*ZendTo [mailto:zendto-bounces at zend.to] *On Behalf Of *Jules > Field via ZendTo > *Sent:* Wednesday, July 25, 2018 12:26 PM > *To:* Pedrosi, Derek G. via ZendTo > ; ZendTo Users > > *Cc:* Jules Field > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > Testing it with "clamscan" won't help. It's "clamdscan" that has > to work, which is a very different beast. > "clamscan" just does it all at once (which is why it takes so long). > "clamdscan" uses the "clamd" process to actually do the scanning, > and hence is much faster as there's no startup time while it loads > and compiles all the virus signatures. > > If it works with a small text file, but not an archive or docx > file, then you've probably run out of disk space in wherever clamd > is trying to unpack the archive. > > Otherwise, it is almost always permissions/ownership problems. > You shouldn't do any harm by fetching a new copy of the ZendTo > installer and *just* doing the "Setup ClamAV" section. > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a > real shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web > server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > If both of those succeed, then start a big upload going in ZendTo. > This will force some data (with the right permissions) into > /var/zendto/incoming. While it's running, do "clamdscan > /var/zendto/incoming/*" and "clamdscan --fdpass > /var/zendto/incoming/*". > > By the time you've done all that lot, you've probably got some > errors from ClamAV which will help narrow down the cause. > > When you've fixed it, remember to put your "/etc/passwd" file back > so the shell says "/sbin/nologin" and run the "pwconv" command again. > > Hope that helps, > Jules. > > > On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and users > were unable to drop files.? No changes were made. > > User see this? > > *Upload Error* > > > > > *The attempt to virus-scan your drop-off failed. Please notify > the system administrator.* > > I?ve since disable AV scan from the preferences.php (it was > 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and > now users can drop files. > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of > dropped-off files /var/zendto/incoming/phpLfUrV9 > /var/zendto/incoming/phpf6ExDv for USER failed with > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: > linux-gnu, ARCH: x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started at > Wed Jul 25 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: > 58, sigs: 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: > 24781, sigs: 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date > (version: 325, sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded > (6584590 signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 > 2018 > > Now, I can scan files manually via the command line? > > clamscan --verbose? /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > Anywhere else to look? > > derek > > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, > > becoming rough in west. Rain later. Good, occasionally poor. > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > 'Ensanguining the skies > How heavily it dies > Into the west away; > Past touch and sight and sound > Not further to be found, > How hopeless under ground > ?? Falls the remorseful day.' - A.E.Houseman > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'We face neither East nor West: we face forward.' - Kwame Nkrumah www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedrosi at millercanfield.com Fri Jul 27 13:59:44 2018 From: pedrosi at millercanfield.com (Pedrosi, Derek G.) Date: Fri, 27 Jul 2018 12:59:44 +0000 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: Running clamdscan with changes Jules outlined yields the following. When I go to that directory, the file /var/run/clamav/clamd.ctl does not exist. www-data at ZendTo5:~$ clamdscan --verbose /var/zendto/* ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 8 Time: 0.001 sec (0 m 0 s) www-data at ZendTo5:~$ clamdscan --verbose --fdpass /var/zendto/* ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory /var/zendto/incoming: OK /var/zendto/library: OK ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 6 Time: 0.000 sec (0 m 0 s) derek From: Jules Field [mailto:Jules at Zend.To] Sent: Thursday, July 26, 2018 11:13 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Derek, On 26/07/2018 16:07, Pedrosi, Derek G. wrote: Jules, I?m the only one with ANY access to this system (other than web), and I was on vacation. Hence my suggestion of some*thing*. Such as your cron daemon, which appears to have been installing updates (they might well have been tagged as security updates, so got automatically installed). Having read your lines below, have you tried this bit I suggested in my original reply to you? If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* What does that lot output? You not only need to get the location of the LocalSocket correct enough for clamd to start and clamdscan to talk to it, but freshclam.conf needs to know where it is too, or else freshclam can't tell clamd that its signatures have been updated and hence needs to restart itself. Cheers, Jules. Nevertheless, I?ve comment out the stats lines in clamd.conf and then I received this error. root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Likewise in ZendTo the log shows? Error: Virus scan of dropped-off files /var/zendto/incoming/phpSAkd0U for dgpedrosi failed with ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Then from clamd.conf I commented out these lines #LocalSocket /var/run/clamav/clamd.ctl #FixStaleSocket true And now I can run a command line scan without error: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) root at ZendTo5:/opt/zendto/config# But ZendTo will still not AV scan, from the ZendTo log: Error: Virus scan of dropped-off files /var/zendto/incoming/phpcz1Ojf for dgpedrosi failed with ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: root at ZendTo5:/opt/zendto/config# service --status-all [ + ] acpid [ + ] apache-htcacheclean [ + ] apache2 [ + ] apparmor [ + ] apport [ + ] atd [ - ] bootmisc.sh [ - ] checkfs.sh [ - ] checkroot-bootclean.sh [ - ] checkroot.sh [ - ] clamav-daemon [ + ] clamav-freshclam [ + ] console-setup [ + ] cron But I did reboot the server, and I?m still seeing the issue. ??? From: Jules Field [mailto:Jules at Zend.To] Sent: Thursday, July 26, 2018 10:27 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Derek, On 26/07/2018 14:50, Pedrosi, Derek G. wrote: This is my production server, and no changes were made; Ah, the famous "But I didn't change anything" defence. :-) :-) it just started throwing the error. Ah, but changes *were* made. Just possibly not by you. :-) Someone (or more likely some*thing*) did a "yum upgrade" or an "apt upgrade", and replaced the copy of ClamAV that was running. You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? That was modified yesterday morning, which is probably shortly before it all stopped working. From your /etc/clamav/clamd.conf file, based on the output from "clamdscan" below, you should remove the lines that start "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd service ("service clamd restart" will *probably* do the trick on almost any Linux variant). Then try that clamdscan command again and see if it gets further. Cheers, Jules. Running clamdscan: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 ERROR: Parse error at line 79: Unknown option StatsEnabled ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# clamscan --version ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la total 36 drwxr-xr-x 5 root root 4096 Jul 26 09:49 . drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d derek From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Jules Field via ZendTo Sent: Wednesday, July 25, 2018 12:26 PM To: Pedrosi, Derek G. via ZendTo ; ZendTo Users Cc: Jules Field Subject: Re: [ZendTo] ClamAV fail Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details? From ZendTo log? 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line? clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Ensanguining the skies How heavily it dies Into the west away; Past touch and sight and sound Not further to be found, How hopeless under ground Falls the remorseful day.' - A.E.Houseman www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'We face neither East nor West: we face forward.' - Kwame Nkrumah www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Jul 27 15:10:05 2018 From: Jules at Zend.To (Jules Field) Date: Fri, 27 Jul 2018 15:10:05 +0100 Subject: [ZendTo] ClamAV fail In-Reply-To: References: Message-ID: <12d19368-29e6-7ef6-654a-2c7d5eae5290@Zend.To> Have you restarted clamd before trying clamdscan? Is there any setting for "LocalSocket" in your clamd.conf file? (There probably doesn't have to be, it will most likely use a default if you don't set one, you can check in your clamd.conf file as if there isn't a setting for it, there will still be a comment describing it and stating what the default value is.) On 27/07/2018 13:59, Pedrosi, Derek G. wrote: > > Running clamdscan with changes Jules outlined yields the following. > > When I go to that directory, the file /var/run/clamav/clamd.ctl does > not exist. > > www-data at ZendTo5:~$ clamdscan --verbose /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 8 > > Time: 0.001 sec (0 m 0 s) > > www-data at ZendTo5:~$ clamdscan --verbose --fdpass /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > /var/zendto/incoming: OK > > /var/zendto/library: OK > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 6 > > Time: 0.000 sec (0 m 0 s) > > derek > > *From:*Jules Field [mailto:Jules at Zend.To] > *Sent:* Thursday, July 26, 2018 11:13 AM > *To:* Pedrosi, Derek G. ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > On 26/07/2018 16:07, Pedrosi, Derek G. wrote: > > Jules, > > I?m the only one with ANY access to this system (other than web), > and I was on vacation. > > Hence my suggestion of some*thing*. > Such as your cron daemon, which appears to have been installing > updates (they might well have been tagged as security updates, so got > automatically installed). > > Having read your lines below, have you tried this bit I suggested in > my original reply to you? > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > What does that lot output? > > You not only need to get the location of the LocalSocket correct > enough for clamd to start and clamdscan to talk to it, but > freshclam.conf needs to know where it is too, or else freshclam can't > tell clamd that its signatures have been updated and hence needs to > restart itself. > > Cheers, > Jules. > > Nevertheless, I?ve comment out the stats lines in clamd.conf and > then I received this error. > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > Likewise in ZendTo the log shows? > > Error: Virus scan of dropped-off files? > /var/zendto/incoming/phpSAkd0U for dgpedrosi failed with ERROR: > Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory? ----------- > SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: > 0.000 sec (0 m 0 s) > > Then from clamd.conf I commented out these lines > > #LocalSocket /var/run/clamav/clamd.ctl > > #FixStaleSocket true > > And now I can run a command line scan without error: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > root at ZendTo5:/opt/zendto/config# > > But ZendTo will still not AV scan, from the ZendTo log: > > Error: Virus scan of dropped-off files? > /var/zendto/incoming/phpcz1Ojf for dgpedrosi failed with? > ----------- SCAN SUMMARY ----------- Infected files: 0 Total > errors: 1 Time: 0.000 sec (0 m 0 s) > > Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: > > root at ZendTo5:/opt/zendto/config# service --status-all > > [ + ]? acpid > > [ + ] apache-htcacheclean > > [ + ]? apache2 > > [ + ]? apparmor > > [ + ]? apport > > [ + ]? atd > > [ - ]? bootmisc.sh > > [ - ]? checkfs.sh > > [ - ] checkroot-bootclean.sh > > [ - ]? checkroot.sh > > [ - ]? clamav-daemon > > [ + ] clamav-freshclam > > [ + ]? console-setup > > [ + ]? cron > > But I did reboot the server, and I?m still seeing the issue. > > ??? > > *From:*Jules Field [mailto:Jules at Zend.To] > *Sent:* Thursday, July 26, 2018 10:27 AM > *To:* Pedrosi, Derek G. > ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > On 26/07/2018 14:50, Pedrosi, Derek G. wrote: > > This is my production server, and no changes were made; > > Ah, the famous "But I didn't change anything" defence. :-) :-) > > > it just started throwing the error. > > Ah, but changes *were* made. Just possibly not by you. :-) > Someone (or more likely some*thing*) did a "yum upgrade" or an > "apt upgrade", and replaced the copy of ClamAV that was running. > You see that file "clamd.conf.ucf-dist" in your "ls -al" output > below? That was modified yesterday morning, which is probably > shortly before it all stopped working. > > From your /etc/clamav/clamd.conf file, based on the output from > "clamdscan" below, you should remove the lines that start > "AllowSupplementaryGroups" and "StatsEnabled". Then restart the > clamd service ("service clamd restart" will *probably* do the > trick on almost any Linux variant). Then try that clamdscan > command again and see if it gets further. > > Cheers, > Jules. > > > > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout > preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups > at line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 > > root at ZendTo5:/opt/zendto/config# nano? /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# ls? /etc/clamav -la > > total 36 > > drwxr-xr-x? 5 root?? root 4096 Jul 26 09:49 . > > drwxr-xr-x 94 root?? root 4096 Jul 25 06:06 .. > > -rw-r--r--? 1 root?? root 2059 Mar? 5 10:19 clamd.conf > > -rw-r--r--? 1 root?? root 1999 Jul 25 06:06 clamd.conf.ucf-dist > > -rw-r--r--? 1 root?? root 2060 Mar? 5 10:19 clamd.conf.zendto > > -r--r--r--? 1 clamav adm?? 702 Jul 25 06:06 freshclam.conf > > drwxr-xr-x? 2 root?? root 4096 Jan 29 11:14 onerrorexecute.d > > drwxr-xr-x? 2 root?? root 4096 Jan 29 11:14 onupdateexecute.d > > drwxr-xr-x? 2 root?? root 4096 Jan 29 11:14 virusevent.d > > derek > > *From:*ZendTo [mailto:zendto-bounces at zend.to] *On Behalf Of > *Jules Field via ZendTo > *Sent:* Wednesday, July 25, 2018 12:26 PM > *To:* Pedrosi, Derek G. via ZendTo > ; ZendTo Users > > *Cc:* Jules Field > *Subject:* Re: [ZendTo] ClamAV fail > > Derek, > > Testing it with "clamscan" won't help. It's "clamdscan" that > has to work, which is a very different beast. > "clamscan" just does it all at once (which is why it takes so > long). > "clamdscan" uses the "clamd" process to actually do the > scanning, and hence is much faster as there's no startup time > while it loads and compiles all the virus signatures. > > If it works with a small text file, but not an archive or docx > file, then you've probably run out of disk space in wherever > clamd is trying to unpack the archive. > > Otherwise, it is almost always permissions/ownership problems. > You shouldn't do any harm by fetching a new copy of the ZendTo > installer and *just* doing the "Setup ClamAV" section. > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data > user a real shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web > server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > If both of those succeed, then start a big upload going in > ZendTo. This will force some data (with the right permissions) > into /var/zendto/incoming. While it's running, do "clamdscan > /var/zendto/incoming/*" and "clamdscan --fdpass > /var/zendto/incoming/*". > > By the time you've done all that lot, you've probably got some > errors from ClamAV which will help narrow down the cause. > > When you've fixed it, remember to put your "/etc/passwd" file > back so the shell says "/sbin/nologin" and run the "pwconv" > command again. > > Hope that helps, > Jules. > > > > On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and > users were unable to drop files.? No changes were made. > > User see this? > > *Upload Error* > > > > > *The attempt to virus-scan your drop-off failed. Please > notify the system administrator.* > > I?ve since disable AV scan from the preferences.php (it > was 'clamdscan' => '/usr/bin/clamdscan --stdout > --fdpass',) and now users can drop files. > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan > of dropped-off files /var/zendto/incoming/phpLfUrV9 > /var/zendto/incoming/phpf6ExDv for USER failed with > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> > -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> > -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: > linux-gnu, ARCH: x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started > at Wed Jul 25 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date > (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date > (version: 24781, sigs: 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date > (version: 325, sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> > -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from > /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded > (6584590 signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 > 06:05:55 2018 > > Now, I can scan files manually via the command line? > > clamscan --verbose? /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > Anywhere else to look? > > derek > > > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, > > becoming rough in west. Rain later. Good, occasionally poor. > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Ensanguining the skies > > How heavily it dies > > Into the west away; > > Past touch and sight and sound > > Not further to be found, > > How hopeless under ground > > ?? Falls the remorseful day.' - A.E.Houseman > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > 'We face neither East nor West: we face forward.' - Kwame Nkrumah > www.Zend.To > Twitter: @JulesFM > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut.' - Ernest Hemingway www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.brudenell at york.ac.uk Fri Jul 27 15:23:38 2018 From: mike.brudenell at york.ac.uk (Mike Brudenell) Date: Fri, 27 Jul 2018 15:23:38 +0100 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <644ad67b-be92-cb5c-dbf7-d6368500d2e1@Zend.To> Message-ID: This may or may not be related, but I'm having trouble with ClamAV and Exim on our mail gateways, getting the same error. Testing using the "clamdscan" command to scan a file with the daemon also had problems. A quick search with Google suggests there might be an incompatibility between ClamAV 0.100 and certain Yara rules databases: https://github.com/extremeshok/clamav-unofficial-sigs/issues/203 ?Disabling the Yara rules as suggested in that conversation has helped me get things running again.? ?Cheers, Mike B.? On Fri, 27 Jul 2018 at 14:46, Pedrosi, Derek G. via ZendTo wrote: > Running clamdscan with changes Jules outlined yields the following. > > When I go to that directory, the file /var/run/clamav/clamd.ctl does not > exist. > > > > > > > > www-data at ZendTo5:~$ clamdscan --verbose /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 8 > > Time: 0.001 sec (0 m 0 s) > > www-data at ZendTo5:~$ clamdscan --verbose --fdpass /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > /var/zendto/incoming: OK > > /var/zendto/library: OK > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 6 > > Time: 0.000 sec (0 m 0 s) > > > > > > derek > > > > > > *From:* Jules Field [mailto:Jules at Zend.To] > *Sent:* Thursday, July 26, 2018 11:13 AM > *To:* Pedrosi, Derek G. ; ZendTo Users < > zendto at zend.to> > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > On 26/07/2018 16:07, Pedrosi, Derek G. wrote: > > Jules, > > I?m the only one with ANY access to this system (other than web), and I > was on vacation. > > Hence my suggestion of some*thing*. > Such as your cron daemon, which appears to have been installing updates > (they might well have been tagged as security updates, so got automatically > installed). > > Having read your lines below, have you tried this bit I suggested in my > original reply to you? > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > What does that lot output? > > You not only need to get the location of the LocalSocket correct enough > for clamd to start and clamdscan to talk to it, but freshclam.conf needs to > know where it is too, or else freshclam can't tell clamd that its > signatures have been updated and hence needs to restart itself. > > Cheers, > Jules. > > > > Nevertheless, I?ve comment out the stats lines in clamd.conf and then I > received this error. > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > > > Likewise in ZendTo the log shows? > > > > Error: Virus scan of dropped-off files /var/zendto/incoming/phpSAkd0U for > dgpedrosi failed with ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN > SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m > 0 s) > > > > > > Then from clamd.conf I commented out these lines > > #LocalSocket /var/run/clamav/clamd.ctl > > #FixStaleSocket true > > > > > > And now I can run a command line scan without error: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > root at ZendTo5:/opt/zendto/config# > > > > > > But ZendTo will still not AV scan, from the ZendTo log: > > Error: Virus scan of dropped-off files /var/zendto/incoming/phpcz1Ojf for > dgpedrosi failed with ----------- SCAN SUMMARY ----------- Infected files: > 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) > > > > > > Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: > > root at ZendTo5:/opt/zendto/config# service --status-all > > [ + ] acpid > > [ + ] apache-htcacheclean > > [ + ] apache2 > > [ + ] apparmor > > [ + ] apport > > [ + ] atd > > [ - ] bootmisc.sh > > [ - ] checkfs.sh > > [ - ] checkroot-bootclean.sh > > [ - ] checkroot.sh > > [ - ] clamav-daemon > > [ + ] clamav-freshclam > > [ + ] console-setup > > [ + ] cron > > > > > > > > But I did reboot the server, and I?m still seeing the issue. > > > > ??? > > > > > > *From:* Jules Field [mailto:Jules at Zend.To ] > *Sent:* Thursday, July 26, 2018 10:27 AM > *To:* Pedrosi, Derek G. > ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > On 26/07/2018 14:50, Pedrosi, Derek G. wrote: > > This is my production server, and no changes were made; > > Ah, the famous "But I didn't change anything" defence. :-) :-) > > > it just started throwing the error. > > Ah, but changes *were* made. Just possibly not by you. :-) > Someone (or more likely some*thing*) did a "yum upgrade" or an "apt > upgrade", and replaced the copy of ClamAV that was running. > You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? > That was modified yesterday morning, which is probably shortly before it > all stopped working. > > From your /etc/clamav/clamd.conf file, based on the output from > "clamdscan" below, you should remove the lines that start > "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd > service ("service clamd restart" will *probably* do the trick on almost any > Linux variant). Then try that clamdscan command again and see if it gets > further. > > Cheers, > Jules. > > > > > > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout > preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 > > > > root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la > > total 36 > > drwxr-xr-x 5 root root 4096 Jul 26 09:49 . > > drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. > > -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf > > -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist > > -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto > > -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d > > > > > > > > derek > > > > > > *From:* ZendTo [mailto:zendto-bounces at zend.to ] *On > Behalf Of *Jules Field via ZendTo > *Sent:* Wednesday, July 25, 2018 12:26 PM > *To:* Pedrosi, Derek G. via ZendTo ; > ZendTo Users > *Cc:* Jules Field > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > Testing it with "clamscan" won't help. It's "clamdscan" that has to work, > which is a very different beast. > "clamscan" just does it all at once (which is why it takes so long). > "clamdscan" uses the "clamd" process to actually do the scanning, and > hence is much faster as there's no startup time while it loads and compiles > all the virus signatures. > > If it works with a small text file, but not an archive or docx file, then > you've probably run out of disk space in wherever clamd is trying to unpack > the archive. > > Otherwise, it is almost always permissions/ownership problems. > You shouldn't do any harm by fetching a new copy of the ZendTo installer > and *just* doing the "Setup ClamAV" section. > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > If both of those succeed, then start a big upload going in ZendTo. This > will force some data (with the right permissions) into > /var/zendto/incoming. While it's running, do "clamdscan > /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". > > By the time you've done all that lot, you've probably got some errors from > ClamAV which will help narrow down the cause. > > When you've fixed it, remember to put your "/etc/passwd" file back so the > shell says "/sbin/nologin" and run the "pwconv" command again. > > Hope that helps, > Jules. > > > > On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and users were unable > to drop files. No changes were made. > > User see this? > > *Upload Error* > > *The attempt to virus-scan your drop-off failed. Please notify the system > administrator.* > > > > > > > > I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => > '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. > > > > > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off > files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for > USER failed with > > > > > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: > x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 > 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: > 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: > 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, > sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 > signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 > > > > > > Now, I can scan files manually via the command line? > > clamscan --verbose /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > > > > > > > Anywhere else to look? > > > > derek > > > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, > > becoming rough in west. Rain later. Good, occasionally poor. > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Ensanguining the skies > > How heavily it dies > > Into the west away; > > Past touch and sight and sound > > Not further to be found, > > How hopeless under ground > > Falls the remorseful day.' - A.E.Houseman > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'We face neither East nor West: we face forward.' - Kwame Nkrumah > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -- Systems Administrator & Change Manager IT Services, University of York, Heslington, York YO10 5DD, UK Tel: +44-(0)1904-323811 Web: www.york.ac.uk/it-services Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedrosi at millercanfield.com Fri Jul 27 18:51:37 2018 From: pedrosi at millercanfield.com (Pedrosi, Derek G.) Date: Fri, 27 Jul 2018 17:51:37 +0000 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <12d19368-29e6-7ef6-654a-2c7d5eae5290@Zend.To> Message-ID: The first few lines of my clamd.conf? #Automatically Generated by clamav-daemon postinst #To reconfigure clamd run #dpkg-reconfigure clamav-daemon #Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details LocalSocket /var/run/clamav/clamd.ctl FixStaleSocket true LocalSocketGroup clamav LocalSocketMode 666 # TemporaryDirectory is not set to its default /tmp here to make overriding # the default with environment variables TMPDIR/TMP/TEMP possible User clamav Also? root at ZendTo5:/var/run# systemctl status clamav-daemon ? clamav-daemon.service - Clam AntiVirus userspace daemon Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/clamav-daemon.service.d ??extend.conf Active: failed (Result: exit-code) since Fri 2018-07-27 06:59:56 EDT; 6h ago Docs: man:clamd(8) man:clamd.conf(5) https://www.clamav.net/documents/ Process: 7502 ExecStart=/usr/sbin/clamd --foreground=true (code=exited, status=1/FAILURE) Process: 7499 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, status=0/SUCCESS) Process: 7496 ExecStartPre=/bin/mkdir /run/clamav (code=exited, status=1/FAILURE) Main PID: 7502 (code=exited, status=1/FAILURE) Jul 27 06:59:55 ZendTo5 systemd[1]: Starting Clam AntiVirus userspace daemon... Jul 27 06:59:55 ZendTo5 mkdir[7496]: /bin/mkdir: cannot create directory ?/run/clamav?: File exists Jul 27 06:59:56 ZendTo5 systemd[1]: Started Clam AntiVirus userspace daemon. Jul 27 06:59:56 ZendTo5 clamd[7502]: Fri Jul 27 06:59:56 2018 -> !Please define server type (local and/or TCP). Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Main process exited, code=exited, status=1/FAILURE Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Unit entered failed state. Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Failed with result 'exit-code'. I explored Mike?s comments, but ultimately I do not think it is related. derek From: Jules Field [mailto:Jules at Zend.To] Sent: Friday, July 27, 2018 10:10 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Have you restarted clamd before trying clamdscan? Is there any setting for "LocalSocket" in your clamd.conf file? (There probably doesn't have to be, it will most likely use a default if you don't set one, you can check in your clamd.conf file as if there isn't a setting for it, there will still be a comment describing it and stating what the default value is.) On 27/07/2018 13:59, Pedrosi, Derek G. wrote: Running clamdscan with changes Jules outlined yields the following. When I go to that directory, the file /var/run/clamav/clamd.ctl does not exist. www-data at ZendTo5:~$ clamdscan --verbose /var/zendto/* ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 8 Time: 0.001 sec (0 m 0 s) www-data at ZendTo5:~$ clamdscan --verbose --fdpass /var/zendto/* ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory /var/zendto/incoming: OK /var/zendto/library: OK ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 6 Time: 0.000 sec (0 m 0 s) derek From: Jules Field [mailto:Jules at Zend.To] Sent: Thursday, July 26, 2018 11:13 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Derek, On 26/07/2018 16:07, Pedrosi, Derek G. wrote: Jules, I?m the only one with ANY access to this system (other than web), and I was on vacation. Hence my suggestion of some*thing*. Such as your cron daemon, which appears to have been installing updates (they might well have been tagged as security updates, so got automatically installed). Having read your lines below, have you tried this bit I suggested in my original reply to you? If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* What does that lot output? You not only need to get the location of the LocalSocket correct enough for clamd to start and clamdscan to talk to it, but freshclam.conf needs to know where it is too, or else freshclam can't tell clamd that its signatures have been updated and hence needs to restart itself. Cheers, Jules. Nevertheless, I?ve comment out the stats lines in clamd.conf and then I received this error. root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Likewise in ZendTo the log shows? Error: Virus scan of dropped-off files /var/zendto/incoming/phpSAkd0U for dgpedrosi failed with ERROR: Could not connect to clamd on LocalSocket /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Then from clamd.conf I commented out these lines #LocalSocket /var/run/clamav/clamd.ctl #FixStaleSocket true And now I can run a command line scan without error: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) root at ZendTo5:/opt/zendto/config# But ZendTo will still not AV scan, from the ZendTo log: Error: Virus scan of dropped-off files /var/zendto/incoming/phpcz1Ojf for dgpedrosi failed with ----------- SCAN SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: root at ZendTo5:/opt/zendto/config# service --status-all [ + ] acpid [ + ] apache-htcacheclean [ + ] apache2 [ + ] apparmor [ + ] apport [ + ] atd [ - ] bootmisc.sh [ - ] checkfs.sh [ - ] checkroot-bootclean.sh [ - ] checkroot.sh [ - ] clamav-daemon [ + ] clamav-freshclam [ + ] console-setup [ + ] cron But I did reboot the server, and I?m still seeing the issue. ??? From: Jules Field [mailto:Jules at Zend.To] Sent: Thursday, July 26, 2018 10:27 AM To: Pedrosi, Derek G. ; ZendTo Users Subject: Re: [ZendTo] ClamAV fail Derek, On 26/07/2018 14:50, Pedrosi, Derek G. wrote: This is my production server, and no changes were made; Ah, the famous "But I didn't change anything" defence. :-) :-) it just started throwing the error. Ah, but changes *were* made. Just possibly not by you. :-) Someone (or more likely some*thing*) did a "yum upgrade" or an "apt upgrade", and replaced the copy of ClamAV that was running. You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? That was modified yesterday morning, which is probably shortly before it all stopped working. From your /etc/clamav/clamd.conf file, based on the output from "clamdscan" below, you should remove the lines that start "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd service ("service clamd restart" will *probably* do the trick on almost any Linux variant). Then try that clamdscan command again and see if it gets further. Cheers, Jules. Running clamdscan: root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout preferences.php WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 ERROR: Parse error at line 79: Unknown option StatsEnabled ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# clamscan --version ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la total 36 drwxr-xr-x 5 root root 4096 Jul 26 09:49 . drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d derek From: ZendTo [mailto:zendto-bounces at zend.to] On Behalf Of Jules Field via ZendTo Sent: Wednesday, July 25, 2018 12:26 PM To: Pedrosi, Derek G. via ZendTo ; ZendTo Users Cc: Jules Field Subject: Re: [ZendTo] ClamAV fail Derek, Testing it with "clamscan" won't help. It's "clamdscan" that has to work, which is a very different beast. "clamscan" just does it all at once (which is why it takes so long). "clamdscan" uses the "clamd" process to actually do the scanning, and hence is much faster as there's no startup time while it loads and compiles all the virus signatures. If it works with a small text file, but not an archive or docx file, then you've probably run out of disk space in wherever clamd is trying to unpack the archive. Otherwise, it is almost always permissions/ownership problems. You shouldn't do any harm by fetching a new copy of the ZendTo installer and *just* doing the "Setup ClamAV" section. If you want to test it by hand, you need to do this: Edit the /etc/passwd file and give your apache or www-data user a real shell such as /bin/bash. "pwconv" (that makes the /etc/shadow file). "su - apache" (or "su - www-data") to properly become the web server user. clamdscan /var/zendto/* clamdscan --fdpass /var/zendto/* If both of those succeed, then start a big upload going in ZendTo. This will force some data (with the right permissions) into /var/zendto/incoming. While it's running, do "clamdscan /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". By the time you've done all that lot, you've probably got some errors from ClamAV which will help narrow down the cause. When you've fixed it, remember to put your "/etc/passwd" file back so the shell says "/sbin/nologin" and run the "pwconv" command again. Hope that helps, Jules. On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: Suddenly, my drops are no longer being scanned by AV and users were unable to drop files. No changes were made. User see this? Upload Error The attempt to virus-scan your drop-off failed. Please notify the system administrator. I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. The details? From ZendTo log? 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for USER failed with From the /var/log/clamav dir: root at ZendTo5:/var/log/clamav# tail freshclam.log Wed Jul 25 11:02:09 2018 -> -------------------------------------- Wed Jul 25 11:44:24 2018 -> Update process terminated Wed Jul 25 11:44:25 2018 -> -------------------------------------- Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64) Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 11:44:25 2018 Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr) Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: 2024541, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, sigs: 90, f-level: 63, builder: neo) Wed Jul 25 11:44:25 2018 -> -------------------------------------- root at ZendTo5:/var/log/clamav# tail clamav.log Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 signatures) Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 Now, I can scan files manually via the command line? clamscan --verbose /var/log/ ----------- SCAN SUMMARY ----------- Known viruses: 6584590 Engine version: 0.100.1 Scanned directories: 1 Scanned files: 43 Infected files: 0 Data scanned: 8.88 MB Data read: 1.75 MB (ratio 5.07:1) Time: 19.976 sec (0 m 19 s) Anywhere else to look? derek _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, becoming rough in west. Rain later. Good, occasionally poor. www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Ensanguining the skies How heavily it dies Into the west away; Past touch and sight and sound Not further to be found, How hopeless under ground Falls the remorseful day.' - A.E.Houseman www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'We face neither East nor West: we face forward.' - Kwame Nkrumah www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut.' - Ernest Hemingway www.Zend.To Twitter: @JulesFM PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 -------------- next part -------------- An HTML attachment was scrubbed... URL: From glenn.noel at gmail.com Fri Jul 27 20:51:06 2018 From: glenn.noel at gmail.com (Glenn Noel) Date: Fri, 27 Jul 2018 15:51:06 -0400 Subject: [ZendTo] ClamAV fail In-Reply-To: References: <12d19368-29e6-7ef6-654a-2c7d5eae5290@Zend.To> Message-ID: Hi Derek and Zendto community. This is my first time posting to the group. Derek, I had the same ClamAV issue you encountered where it seemed to break out of no-where. I had been following this thread closely and trying the various suggestions such as commenting out or deleting lines in the clamd.conf. Nothing seemed to work for me. I strayed from the thread and tried an upgrade via the instructions on: http://zend.to/upgrade.php After the upgrade I received errors regarding "libsodium not being installed" - I recalled seeing this in another thread so I followed Jules' recommendation of running the full installer: http://zend.to/downloads.php#installer 1. Become root with "su -" if using CentOS or RedHat, or "sudo su -" if using Ubuntu. 2. Download the installer: curl -O http://zend.to/files/install.ZendTo.tgz 3. Unpack it and cd into it: tar xzvf install.ZendTo.tgz cd install.ZendTo 4. Run the installer: ./install.sh During the install process there were a couple of prompts to look out for to not overwrite the zendto.conf and preferences.php, but other than that the installer ran over top of my existing installation. After the installer completed and a reboot of the server I was back to full operation. ClamAV is working great with no errors. I'm running Ubuntu Server 16.04 LTS. My server is a VM so I was sure to snap it before the upgrade and also backed up my files as per the instructions in http://zend.to/upgrade.php. Best wishes to you in sorting out your challenges. (Thanks to Jules for your support). Take care. Glenn On Fri, Jul 27, 2018 at 1:51 PM, Pedrosi, Derek G. via ZendTo < zendto at zend.to> wrote: > The first few lines of my clamd.conf? > > #Automatically Generated by clamav-daemon postinst > > #To reconfigure clamd run #dpkg-reconfigure clamav-daemon > > #Please read /usr/share/doc/clamav-daemon/README.Debian.gz for details > > LocalSocket /var/run/clamav/clamd.ctl > > FixStaleSocket true > > LocalSocketGroup clamav > > LocalSocketMode 666 > > # TemporaryDirectory is not set to its default /tmp here to make overriding > > # the default with environment variables TMPDIR/TMP/TEMP possible > > User clamav > > > > Also? > > > > root at ZendTo5:/var/run# systemctl status clamav-daemon > > ? clamav-daemon.service - Clam AntiVirus userspace daemon > > Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; > vendor preset: enabled) > > Drop-In: /etc/systemd/system/clamav-daemon.service.d > > ??extend.conf > > Active: failed (Result: exit-code) since Fri 2018-07-27 06:59:56 EDT; > 6h ago > > Docs: man:clamd(8) > > man:clamd.conf(5) > > https://www.clamav.net/documents/ > > Process: 7502 ExecStart=/usr/sbin/clamd --foreground=true (code=exited, > status=1/FAILURE) > > Process: 7499 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, > status=0/SUCCESS) > > Process: 7496 ExecStartPre=/bin/mkdir /run/clamav (code=exited, > status=1/FAILURE) > > Main PID: 7502 (code=exited, status=1/FAILURE) > > > > Jul 27 06:59:55 ZendTo5 systemd[1]: Starting Clam AntiVirus userspace > daemon... > > Jul 27 06:59:55 ZendTo5 mkdir[7496]: /bin/mkdir: cannot create directory > ?/run/clamav?: File exists > > Jul 27 06:59:56 ZendTo5 systemd[1]: Started Clam AntiVirus userspace > daemon. > > Jul 27 06:59:56 ZendTo5 clamd[7502]: Fri Jul 27 06:59:56 2018 -> !Please > define server type (local and/or TCP). > > Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Main process > exited, code=exited, status=1/FAILURE > > Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Unit entered > failed state. > > Jul 27 06:59:56 ZendTo5 systemd[1]: clamav-daemon.service: Failed with > result 'exit-code'. > > > > > > > > I explored Mike?s comments, but ultimately I do not think it is related. > > > > > > derek > > > > > > *From:* Jules Field [mailto:Jules at Zend.To] > *Sent:* Friday, July 27, 2018 10:10 AM > *To:* Pedrosi, Derek G. ; ZendTo Users < > zendto at zend.to> > *Subject:* Re: [ZendTo] ClamAV fail > > > > Have you restarted clamd before trying clamdscan? > > Is there any setting for "LocalSocket" in your clamd.conf file? > (There probably doesn't have to be, it will most likely use a default if > you don't set one, you can check in your clamd.conf file as if there isn't > a setting for it, there will still be a comment describing it and stating > what the default value is.) > > On 27/07/2018 13:59, Pedrosi, Derek G. wrote: > > Running clamdscan with changes Jules outlined yields the following. > > When I go to that directory, the file /var/run/clamav/clamd.ctl does not > exist. > > > > > > > > www-data at ZendTo5:~$ clamdscan --verbose /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 8 > > Time: 0.001 sec (0 m 0 s) > > www-data at ZendTo5:~$ clamdscan --verbose --fdpass /var/zendto/* > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > /var/zendto/incoming: OK > > /var/zendto/library: OK > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 6 > > Time: 0.000 sec (0 m 0 s) > > > > > > derek > > > > > > *From:* Jules Field [mailto:Jules at Zend.To ] > *Sent:* Thursday, July 26, 2018 11:13 AM > *To:* Pedrosi, Derek G. > ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > On 26/07/2018 16:07, Pedrosi, Derek G. wrote: > > Jules, > > I?m the only one with ANY access to this system (other than web), and I > was on vacation. > > Hence my suggestion of some*thing*. > Such as your cron daemon, which appears to have been installing updates > (they might well have been tagged as security updates, so got automatically > installed). > > Having read your lines below, have you tried this bit I suggested in my > original reply to you? > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > What does that lot output? > > You not only need to get the location of the LocalSocket correct enough > for clamd to start and clamdscan to talk to it, but freshclam.conf needs to > know where it is too, or else freshclam can't tell clamd that its > signatures have been updated and hence needs to restart itself. > > Cheers, > Jules. > > > > > Nevertheless, I?ve comment out the stats lines in clamd.conf and then I > received this error. > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > > > Likewise in ZendTo the log shows? > > > > Error: Virus scan of dropped-off files /var/zendto/incoming/phpSAkd0U for > dgpedrosi failed with ERROR: Could not connect to clamd on LocalSocket > /var/run/clamav/clamd.ctl: No such file or directory ----------- SCAN > SUMMARY ----------- Infected files: 0 Total errors: 1 Time: 0.000 sec (0 m > 0 s) > > > > > > Then from clamd.conf I commented out these lines > > #LocalSocket /var/run/clamav/clamd.ctl > > #FixStaleSocket true > > > > > > And now I can run a command line scan without error: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan preferences.php > > > > ----------- SCAN SUMMARY ----------- > > Infected files: 0 > > Total errors: 1 > > Time: 0.000 sec (0 m 0 s) > > root at ZendTo5:/opt/zendto/config# > > > > > > But ZendTo will still not AV scan, from the ZendTo log: > > Error: Virus scan of dropped-off files /var/zendto/incoming/phpcz1Ojf for > dgpedrosi failed with ----------- SCAN SUMMARY ----------- Infected files: > 0 Total errors: 1 Time: 0.000 sec (0 m 0 s) > > > > > > Also, I?m running Ubuntu 16.04.4 LTS no clamd service to be found: > > root at ZendTo5:/opt/zendto/config# service --status-all > > [ + ] acpid > > [ + ] apache-htcacheclean > > [ + ] apache2 > > [ + ] apparmor > > [ + ] apport > > [ + ] atd > > [ - ] bootmisc.sh > > [ - ] checkfs.sh > > [ - ] checkroot-bootclean.sh > > [ - ] checkroot.sh > > [ - ] clamav-daemon > > [ + ] clamav-freshclam > > [ + ] console-setup > > [ + ] cron > > > > > > > > But I did reboot the server, and I?m still seeing the issue. > > > > ??? > > > > > > *From:* Jules Field [mailto:Jules at Zend.To ] > *Sent:* Thursday, July 26, 2018 10:27 AM > *To:* Pedrosi, Derek G. > ; ZendTo Users > > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > On 26/07/2018 14:50, Pedrosi, Derek G. wrote: > > This is my production server, and no changes were made; > > Ah, the famous "But I didn't change anything" defence. :-) :-) > > > > it just started throwing the error. > > Ah, but changes *were* made. Just possibly not by you. :-) > Someone (or more likely some*thing*) did a "yum upgrade" or an "apt > upgrade", and replaced the copy of ClamAV that was running. > You see that file "clamd.conf.ucf-dist" in your "ls -al" output below? > That was modified yesterday morning, which is probably shortly before it > all stopped working. > > From your /etc/clamav/clamd.conf file, based on the output from > "clamdscan" below, you should remove the lines that start > "AllowSupplementaryGroups" and "StatsEnabled". Then restart the clamd > service ("service clamd restart" will *probably* do the trick on almost any > Linux variant). Then try that clamdscan command again and see if it gets > further. > > Cheers, > Jules. > > > > > > > Running clamdscan: > > root at ZendTo5:/opt/zendto/config# /usr/bin/clamdscan --stdout > preferences.php > > WARNING: Ignoring deprecated option AllowSupplementaryGroups at line 11 > > ERROR: Parse error at line 79: Unknown option StatsEnabled > > ERROR: Can't parse clamd configuration file /etc/clamav/clamd.conf > > > > root at ZendTo5:/opt/zendto/config# clamscan --version > > ClamAV 0.100.1/24784/Thu Jul 26 04:44:34 2018 > > > > root at ZendTo5:/opt/zendto/config# nano /etc/clamav/clamd.conf > > root at ZendTo5:/opt/zendto/config# ls /etc/clamav -la > > total 36 > > drwxr-xr-x 5 root root 4096 Jul 26 09:49 . > > drwxr-xr-x 94 root root 4096 Jul 25 06:06 .. > > -rw-r--r-- 1 root root 2059 Mar 5 10:19 clamd.conf > > -rw-r--r-- 1 root root 1999 Jul 25 06:06 clamd.conf.ucf-dist > > -rw-r--r-- 1 root root 2060 Mar 5 10:19 clamd.conf.zendto > > -r--r--r-- 1 clamav adm 702 Jul 25 06:06 freshclam.conf > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 onerrorexecute.d > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 onupdateexecute.d > > drwxr-xr-x 2 root root 4096 Jan 29 11:14 virusevent.d > > > > > > > > derek > > > > > > *From:* ZendTo [mailto:zendto-bounces at zend.to ] *On > Behalf Of *Jules Field via ZendTo > *Sent:* Wednesday, July 25, 2018 12:26 PM > *To:* Pedrosi, Derek G. via ZendTo ; > ZendTo Users > *Cc:* Jules Field > *Subject:* Re: [ZendTo] ClamAV fail > > > > Derek, > > Testing it with "clamscan" won't help. It's "clamdscan" that has to work, > which is a very different beast. > "clamscan" just does it all at once (which is why it takes so long). > "clamdscan" uses the "clamd" process to actually do the scanning, and > hence is much faster as there's no startup time while it loads and compiles > all the virus signatures. > > If it works with a small text file, but not an archive or docx file, then > you've probably run out of disk space in wherever clamd is trying to unpack > the archive. > > Otherwise, it is almost always permissions/ownership problems. > You shouldn't do any harm by fetching a new copy of the ZendTo installer > and *just* doing the "Setup ClamAV" section. > > If you want to test it by hand, you need to do this: > Edit the /etc/passwd file and give your apache or www-data user a real > shell such as /bin/bash. > "pwconv" (that makes the /etc/shadow file). > "su - apache" (or "su - www-data") to properly become the web server user. > clamdscan /var/zendto/* > clamdscan --fdpass /var/zendto/* > > If both of those succeed, then start a big upload going in ZendTo. This > will force some data (with the right permissions) into > /var/zendto/incoming. While it's running, do "clamdscan > /var/zendto/incoming/*" and "clamdscan --fdpass /var/zendto/incoming/*". > > By the time you've done all that lot, you've probably got some errors from > ClamAV which will help narrow down the cause. > > When you've fixed it, remember to put your "/etc/passwd" file back so the > shell says "/sbin/nologin" and run the "pwconv" command again. > > Hope that helps, > Jules. > > > > > On 25/07/2018 17:04, Pedrosi, Derek G. via ZendTo wrote: > > Suddenly, my drops are no longer being scanned by AV and users were unable > to drop files. No changes were made. > > User see this? > > *Upload Error* > > *The attempt to virus-scan your drop-off failed. Please notify the system > administrator.* > > > > > > > > I?ve since disable AV scan from the preferences.php (it was 'clamdscan' => > '/usr/bin/clamdscan --stdout --fdpass',) and now users can drop files. > > > > > > The details? > > From ZendTo log? > > 2018-07-25 08:22:31 172.16.0.103 [XXXX]: Error: Virus scan of dropped-off > files /var/zendto/incoming/phpLfUrV9 /var/zendto/incoming/phpf6ExDv for > USER failed with > > > > > > From the /var/log/clamav dir: > > root at ZendTo5:/var/log/clamav# tail freshclam.log > > Wed Jul 25 11:02:09 2018 -> -------------------------------------- > > Wed Jul 25 11:44:24 2018 -> Update process terminated > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > Wed Jul 25 11:44:25 2018 -> freshclam daemon 0.100.1 (OS: linux-gnu, ARCH: > x86_64, CPU: x86_64) > > Wed Jul 25 11:44:25 2018 -> ClamAV update process started at Wed Jul 25 > 11:44:25 2018 > > Wed Jul 25 11:44:25 2018 -> main.cvd is up to date (version: 58, sigs: > 4566249, f-level: 60, builder: sigmgr) > > Wed Jul 25 11:44:25 2018 -> daily.cld is up to date (version: 24781, sigs: > 2024541, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> bytecode.cld is up to date (version: 325, > sigs: 90, f-level: 63, builder: neo) > > Wed Jul 25 11:44:25 2018 -> -------------------------------------- > > root at ZendTo5:/var/log/clamav# tail clamav.log > > Wed Jul 25 04:47:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 04:57:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:07:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:17:22 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:27:13 2018 -> Reading databases from /var/lib/clamav > > Wed Jul 25 05:27:27 2018 -> Database correctly reloaded (6584590 > signatures) > > Wed Jul 25 05:37:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:47:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 05:57:27 2018 -> SelfCheck: Database status OK. > > Wed Jul 25 06:05:55 2018 -> --- Stopped at Wed Jul 25 06:05:55 2018 > > > > > > Now, I can scan files manually via the command line? > > clamscan --verbose /var/log/ > > ----------- SCAN SUMMARY ----------- > > Known viruses: 6584590 > > Engine version: 0.100.1 > > Scanned directories: 1 > > Scanned files: 43 > > Infected files: 0 > > Data scanned: 8.88 MB > > Data read: 1.75 MB (ratio 5.07:1) > > Time: 19.976 sec (0 m 19 s) > > > > > > > > Anywhere else to look? > > > > derek > > > > > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > Malin, Hebrides: South 5 to 7, occasionally 4 at first. Slight or moderate, > > becoming rough in west. Rain later. Good, occasionally poor. > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Ensanguining the skies > > How heavily it dies > > Into the west away; > > Past touch and sight and sound > > Not further to be found, > > How hopeless under ground > > Falls the remorseful day.' - A.E.Houseman > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'We face neither East nor West: we face forward.' - Kwame Nkrumah > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > > Jules > > > > -- > > Julian Field MEng CEng CITP MBCS MIEEE MACM > > > > 'Always do sober what you said you'd do drunk. That will teach you > > to keep your mouth shut.' - Ernest Hemingway > > > > www.Zend.To > > Twitter: @JulesFM > > PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654 > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > > -------------- next part -------------- An HTML attachment was scrubbed... URL: