From Jules at Zend.To Thu Oct 1 10:21:40 2020 From: Jules at Zend.To (Jules) Date: Thu, 1 Oct 2020 10:21:40 +0100 Subject: [ZendTo] Automation In-Reply-To: References: <18eed29e-1c20-459e-8254-7b86e60d4c51@gci.it> <9f7f9581-487c-a0a4-f256-9517bea7ca42@gci.it> Message-ID: Hi Davide, No, but there is a beta repo. However, it's usually best to just install the betas directly with yum, for example yum install https://zend.to/files/zendto-6.06-1.noarch.rpm You can get the link address I've used above from the zend.to/beta page. It's the link address of the 6.06-1 rpm file given there. Cheers, Jules. On 30/09/2020 17:19, Davide Bozzelli wrote: > Thx Jules > > I'm usually use the rpm repo: does the beta lives in it ? > > Thx > > > *Davide Bozzelli* > IT Architect > davide.bozzelli at gci.it > > +39 02 90092830 > > www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. 105) > - 20084 Lacchiarella (MI) > > > > > > Il 30/09/20 17:47, Jules ha scritto: >> Davide, >> >> I have just released a new beta release 6.06-1 which should fix all >> the autorequest problems you were having. >> You can now also set the --startdatetime. >> And you can --sendemail too (which by default it doesn't as you >> probably want to do that in some other software; the link you need to >> send is in the JSON output). >> >> Please can you give it a try and let me know how you get on. >> >> Cheers, >> Jules. >> >> On 24/09/2020 13:31, Davide Bozzelli via ZendTo wrote: >>> Hi >>> >>> I'm playing aroung the automation script. >>> Version is "zendto-6.05-4.noarch" centos 7. >>> >>> When i try to run something like: >>> >>> /opt/zendto/bin/autorequest --expirydatetime '2030-10-10 10:10:00' >>> --username 'myuser' --password 'mypass' --sendername 'myname' >>> --senderemail 'me at me.it' --senderorg 'me spa' --subject 'Request for >>> files' --note 'Please send me the log files we discussed' >>> --recipientname 'me ' --recipientemail 'me at gmail.com' >>> https://my.zend.to/ >>> >>> I receive: {"status":"error","error":"request error: The end time >>> you set has already passed. >>> >>> Even if I don't specify the expire time >>> >>> Thx >>> >>> >>> >>> >>> *Davide Bozzelli* >>> IT Architect >>> davide.bozzelli at gci.it >>> >>> +39 02 90092830 >>> >>> www.gci.it General Computer Italia S.p.A. Via Milano 11 (S.P. >>> 105) - 20084 Lacchiarella (MI) >>> >>> >>> >>> >>> >>> >>> -- >>> CONFIDENTIALITY NOTICE >>> >>> Questo messaggio e' destinato alle sole persone indicate e puo' >>> contenere informazioni riservate. >>> Se ricevuto per errore, si prega di avvisare immediatamente il >>> mittente e cancellare l'originale. >>> Ogni altro uso del messaggio e' vietato! >>> **** >>> This message is for the designated recipient(s) only and may contain >>> privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original message. >>> Any other use of the email by you is prohibited! >>> -- >>> >>> _______________________________________________ >>> ZendTo mailing list >>> ZendTo at zend.to >>> http://jul.es/mailman/listinfo/zendto >> >> Jules >> >> -- >> Julian Field MEng CEng CITP MBCS MIEEE MACM >> >> 'There is always one moment in childhood when the door opens and >> lets the future in.' - Graham Greene >> >> www.Zend.To >> Twitter: @JulesFM > > > -- > CONFIDENTIALITY NOTICE > > Questo messaggio e' destinato alle sole persone indicate e puo' > contenere informazioni riservate. > Se ricevuto per errore, si prega di avvisare immediatamente il > mittente e cancellare l'originale. > Ogni altro uso del messaggio e' vietato! > **** > This message is for the designated recipient(s) only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original message. > Any other use of the email by you is prohibited! > -- Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Humber, Thames, Dover: South 5 to 7, veering west 4 or 5, than backing east 5 to 7 later. Moderate or rough becoming slight or moderate for a time. Occasional rain. Good, occasionally poor. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pnahmlinmbbfdnif.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aamnpmkjhnannehb.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ececegaanpagnmgh.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mdbhjpdmdmcklimm.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ghbbggdlddcgnlhj.jpg Type: image/jpeg Size: 6436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: napdnidbfhfohkad.jpg Type: image/jpeg Size: 3534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mnfocponpfgkpiig.jpg Type: image/jpeg Size: 1540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ejjhbglfeemblmfl.jpg Type: image/jpeg Size: 1562 bytes Desc: not available URL: From dsolodow at gaylor.com Thu Oct 1 20:09:53 2020 From: dsolodow at gaylor.com (Solodow, Damien) Date: Thu, 1 Oct 2020 19:09:53 +0000 Subject: [ZendTo] Index.php downloading instead of executing References: Message-ID: ZendTo 6.05-4 on Ubuntu 18.04.5 LTS Things have been humming along, and was looking to upgrade it to 20.04 LTS. Took a snapshot pre-upgrade, did the do-release-upgrade. Ran into weird stuff and reverted to snapshot. It seems like folks who hit the site while it was in whatever wonky state 20.04 created are now having an issue accessing the site. When they hit it, it downloads a file called ?download? which looks to be index.php However if you hit the site from a different browser or an incognito session, it works as expected. That *seems* like a cookie related thing, but I?m trying to see if there is anything we can do aside from deal with ?if the site doesn?t load clear your cookies and try again? for a while. ? ? [Gaylor Electric logo] [Gaylor Electric Website] [Facebook] [Twitter] [LinkedIn] Damien Solodow IS System Administrator Gaylor Electric, Inc. 5750 Castle Creek Pkwy N Drive, Suite 400 Indianapolis , IN . 46250 O: 317.815.3103 | M: 317.506.8521 317.759.0077 emergency IS support -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Oct 2 09:53:33 2020 From: Jules at Zend.To (Jules) Date: Fri, 2 Oct 2020 09:53:33 +0100 Subject: [ZendTo] Index.php downloading instead of executing In-Reply-To: References: Message-ID: Damien, Have you switched to php-fpm? (If that means nothing to you, the answer is "no" :-) It sounds like you haven't got the mod_php Apache module loaded. You could try running Stage 2 of the ZendTo Installer again. Redownload the Installer via zend.to, unpack it, cd into the "Ubuntu-Debian" directory and run the script whose name starts with "2". That will reinstall the correct PHP modules for you, which may help. But I'm then unsure as to why an incognito session would help. That implies it's a browser cache problem or a cookie problem. Anyone else seen these symptoms? Cheers, Jules. On 01/10/2020 20:09, Solodow, Damien via ZendTo wrote: > > ZendTo 6.05-4 on Ubuntu 18.04.5 LTS > > Things have been humming along, and was looking to upgrade it to 20.04 > LTS. > > Took a snapshot pre-upgrade, did the do-release-upgrade. > > Ran into weird stuff and reverted to snapshot. > > It seems like folks who hit the site while it was in whatever wonky > state 20.04 created are now having an issue accessing the site. > > When they hit it, it downloads a file called ?download? which looks to > be index.php > > However if you hit the site from a different browser or an incognito > session, it works as expected. > > That **seems** like a cookie related thing, but I?m trying to see if > there is anything we can do aside from deal with ?if the site doesn?t > load clear your cookies and try again? for a while. ? > > ? > > Gaylor Electric logo > > Gaylor Electric Website > > > > Facebook > > > > Twitter > > > > LinkedIn > > > > *Damien?Solodow* > > *IS?System?Administrator* > > Gaylor?Electric,?Inc. > > 5750?Castle?Creek?Pkwy?N?Drive,?Suite?400 > > Indianapolis > > > > , > > > > IN > > > > . > > > > 46250 > > O: 317.815.3103 > > > > | > > > > M: 317.506.8521 > > *317.759.0077 emergency > IS?support * > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Fair Isle, Faeroes, Southeast Iceland: Cyclonic 5 to 7, occasionally gale 8 at first in Fair Isle. Moderate or rough, occasionally very rough at first except in Southeast Iceland. Rain. Good, occasionally poor. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsolodow at gaylor.com Fri Oct 2 14:59:14 2020 From: dsolodow at gaylor.com (Solodow, Damien) Date: Fri, 2 Oct 2020 13:59:14 +0000 Subject: [ZendTo] Index.php downloading instead of executing In-Reply-To: References: Message-ID: Nope, not using php-fpm. Re-ran the php module installer script, only thing I saw was it complaining about not being able to install php7.2-sodium due to no installation candidate. I?m reasonably certain it?s a cache/cookie issue as a PC that has used the site in the past but didn?t hit it yesterday during the troubles was fine in the evening. ? [Gaylor Electric logo] [Gaylor Electric Website] [Facebook] [Twitter] [LinkedIn] Damien Solodow IS System Administrator Gaylor Electric, Inc. 5750 Castle Creek Pkwy N Drive, Suite 400 Indianapolis , IN . 46250 O: 317.815.3103 | M: 317.506.8521 317.759.0077 emergency IS support From: Jules Sent: Friday, October 2, 2020 4:54 AM To: ZendTo Users Cc: Solodow, Damien Subject: Re: [ZendTo] Index.php downloading instead of executing Damien, Have you switched to php-fpm? (If that means nothing to you, the answer is "no" :-) It sounds like you haven't got the mod_php Apache module loaded. You could try running Stage 2 of the ZendTo Installer again. Redownload the Installer via zend.to, unpack it, cd into the "Ubuntu-Debian" directory and run the script whose name starts with "2". That will reinstall the correct PHP modules for you, which may help. But I'm then unsure as to why an incognito session would help. That implies it's a browser cache problem or a cookie problem. Anyone else seen these symptoms? Cheers, Jules. On 01/10/2020 20:09, Solodow, Damien via ZendTo wrote: ZendTo 6.05-4 on Ubuntu 18.04.5 LTS Things have been humming along, and was looking to upgrade it to 20.04 LTS. Took a snapshot pre-upgrade, did the do-release-upgrade. Ran into weird stuff and reverted to snapshot. It seems like folks who hit the site while it was in whatever wonky state 20.04 created are now having an issue accessing the site. When they hit it, it downloads a file called ?download? which looks to be index.php However if you hit the site from a different browser or an incognito session, it works as expected. That *seems* like a cookie related thing, but I?m trying to see if there is anything we can do aside from deal with ?if the site doesn?t load clear your cookies and try again? for a while. ? ? [Gaylor Electric logo] [Gaylor Electric Website] [Facebook] [Twitter] [LinkedIn] Damien Solodow IS System Administrator Gaylor Electric, Inc. 5750 Castle Creek Pkwy N Drive, Suite 400 Indianapolis , IN . 46250 O: 317.815.3103 | M: 317.506.8521 317.759.0077 emergency IS support _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM The current UK shipping forecast: Fair Isle, Faeroes, Southeast Iceland: Cyclonic 5 to 7, occasionally gale 8 at first in Fair Isle. Moderate or rough, occasionally very rough at first except in Southeast Iceland. Rain. Good, occasionally poor. www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Oct 2 15:30:55 2020 From: Jules at Zend.To (Jules) Date: Fri, 2 Oct 2020 15:30:55 +0100 Subject: [ZendTo] Index.php downloading instead of executing In-Reply-To: References: Message-ID: Damien, The PHP Sodium module is needed for all the encryption in ZendTo. If the output of "php -m" doesn't include the sodium module, I would advise you try to find out why and how to install it. It certainly is available. But glad to hear that otherwise it's a cookie or cache problem. Cheers, Jules. On 02/10/2020 14:59, Solodow, Damien wrote: > > Nope, not using php-fpm. > > Re-ran the php module installer script, only thing I saw was it > complaining about not being able to install php7.2-sodium due to no > installation candidate. > > I?m reasonably certain it?s a cache/cookie issue as a PC that has used > the site in the past but didn?t hit it yesterday during the troubles > was fine in the evening. > > ? > > Gaylor Electric logo > > Gaylor Electric Website > > > > Facebook > > > > Twitter > > > > LinkedIn > > > > *Damien?Solodow* > > *IS?System?Administrator* > > Gaylor?Electric,?Inc. > > 5750?Castle?Creek?Pkwy?N?Drive,?Suite?400 > > Indianapolis > > > > , > > > > IN > > > > . > > > > 46250 > > O: 317.815.3103 > > > > | > > > > M: 317.506.8521 > > *317.759.0077 emergency > IS?support * > > *From:* Jules > *Sent:* Friday, October 2, 2020 4:54 AM > *To:* ZendTo Users > *Cc:* Solodow, Damien > *Subject:* Re: [ZendTo] Index.php downloading instead of executing > > Damien, > > Have you switched to php-fpm? (If that means nothing to you, the > answer is "no" :-) > > It sounds like you haven't got the mod_php Apache module loaded. > You could try running Stage 2 of the ZendTo Installer again. > Redownload the Installer via zend.to, unpack it, cd into the > "Ubuntu-Debian" directory and run the script whose name starts with > "2". That will reinstall the correct PHP modules for you, which may help. > > But I'm then unsure as to why an incognito session would help. That > implies it's a browser cache problem or a cookie problem. > > Anyone else seen these symptoms? > > Cheers, > Jules. > > On 01/10/2020 20:09, Solodow, Damien via ZendTo wrote: > > ZendTo 6.05-4 on Ubuntu 18.04.5 LTS > > Things have been humming along, and was looking to upgrade it to > 20.04 LTS. > > Took a snapshot pre-upgrade, did the do-release-upgrade. > > Ran into weird stuff and reverted to snapshot. > > It seems like folks who hit the site while it was in whatever > wonky state 20.04 created are now having an issue accessing the site. > > When they hit it, it downloads a file called ?download? which > looks to be index.php > > However if you hit the site from a different browser or an > incognito session, it works as expected. > > That **seems** like a cookie related thing, but I?m trying to see > if there is anything we can do aside from deal with ?if the site > doesn?t load clear your cookies and try again? for a while. ? > > ? > > Gaylor Electric logo > > Gaylor Electric Website > > > > Facebook > > > > Twitter > > > > LinkedIn > > > > *Damien?Solodow* > > *IS?System?Administrator* > > Gaylor?Electric,?Inc. > > 5750?Castle?Creek?Pkwy?N?Drive,?Suite?400 > > Indianapolis > > > > , > > > > IN > > > > . > > > > 46250 > > O: 317.815.3103 > > > > | > > > > M: 317.506.8521 > > *317.759.0077 emergency > IS?support * > > > > _______________________________________________ > > ZendTo mailing list > > ZendTo at zend.to > > http://jul.es/mailman/listinfo/zendto > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > The current UK shipping forecast: > Fair Isle, Faeroes, Southeast Iceland: Cyclonic 5 to 7, occasionally gale 8 at > first in Fair Isle. Moderate or rough, occasionally very rough at first except > in Southeast Iceland. Rain. Good, occasionally poor. > www.Zend.To > Twitter: @JulesFM Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'It's in Apple's DNA that technology alone is not enough. It's technology married with liberal arts, married with the humanities, that yields us the result that makes our hearts sing.' - Steve Jobs www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Massimo.Forni at turboden.it Thu Oct 8 15:48:35 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Thu, 8 Oct 2020 14:48:35 +0000 Subject: [ZendTo] 500 internal server error on user unlock References: <55a91860e82c48ce9734a882f5118739@Mailbox13.turboden.local> Message-ID: Hi Jules, With the latest version whenever I try to open the unlock user page I get a 500 error. I think I saw a similar post in the previous weeks PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function NSSADAuthenticator::validUsername(), 2 passed in /opt/zendto/www/unlock.php on line 78 and exactly 3 expected in /opt/zendto/lib/NSSADAuthenticator.php:188\nStack trace:\n#0 /opt/zendto/www/unlock.php(78): NSSADAuthenticator->validUsername('my.username...', Array)\n#1 {main}\n thrown in /opt/zendto/lib/NSSADAuthenticator.php on line 188 Thank you Best regards -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Oct 8 16:26:58 2020 From: Jules at Zend.To (Jules) Date: Thu, 8 Oct 2020 16:26:58 +0100 Subject: [ZendTo] 500 internal server error on user unlock In-Reply-To: References: <55a91860e82c48ce9734a882f5118739@Mailbox13.turboden.local> Message-ID: Hi Massimo, Many thanks for reporting that. I missed one :-( If you want to fix it yourself, it's very simple. Edit /opt/zendto/www/unlock.php. At line 78 you should see the line ??????? $theDropbox->authenticator()->validUsername($user, $props, $errormsg); Replace that 1 line with these 2: ??????? $errormsg = ''; $theDropbox->authenticator()->validUsername($user, $props, $errormsg); and refresh the page in your web browser. That should fix it. Otherwise, the fix will be in the next beta. As an alternative to the "unlock" page, there is a very simple "unlockuser" command in /opt/zendto/bin that you can run by hand on the command-line. Mostly you just want to do ??? /opt/zendto/bin/unlockuser -a to unlock all locked users. Run it without the "-a" to see the usage. Cheers, Jules. On 08/10/2020 15:48, Massimo Forni via ZendTo wrote: > > Hi Jules, > > With the latest version whenever I try to open the unlock user page I > get a 500 error. > > I think I saw a similar post in the previous weeks > > PHP Fatal error:Uncaught ArgumentCountError: Too few arguments to > function NSSADAuthenticator::validUsername(), 2 passed in > /opt/zendto/www/unlock.php on line 78 and exactly 3 expected in > /opt/zendto/lib/NSSADAuthenticator.php:188\nStack trace:\n#0 > /opt/zendto/www/unlock.php(78): > NSSADAuthenticator->validUsername('my.username...', Array)\n#1 > {main}\nthrown in /opt/zendto/lib/NSSADAuthenticator.php on line 188 > > Thank you > > Best regards > > -- > > *Massimo Forni* > ICT Infrastructure Manager > > Mobile: +393474110278 > > ------------------------------------------------------------------------ > > *Turboden S.p.A.* *I* via Cernaia 10 *I* 25124 Brescia *I* Italy > t. +39 030 3552001 *I* f. +39 030 3552011 > www.turboden.com > > > *Confidentiality notice*: this message, together with its attachments, > may contain strictly confidential and/or legally privileged > information and it is destined solely to the intended addressee(s), > who only may use it under his/their responsibility. Opinions, > conclusions and other information contained in this message, that do > not relate to the official business of this firm, shall be considered > as not given or endorsed by it. If you have received this > communication in error, please notify us immediately by responding to > this email and then delete it from your system. Any use, disclosure, > copying or distribution of the contents of this communication by a > not-intended recipient or in violation of the purposes of this > communication is strictly prohibited and may be unlawful. > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Massimo.Forni at turboden.it Thu Oct 8 18:38:45 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Thu, 8 Oct 2020 17:38:45 +0000 Subject: [ZendTo] 500 internal server error on user unlock In-Reply-To: References: <55a91860e82c48ce9734a882f5118739@Mailbox13.turboden.local> , <00A08A04-DD96-4D67-B16F-CB2478021F89@turboden.it> Message-ID: thank you as usual for the fastest reply in the west ? Sent from my iPhone On 8 Oct 2020, at 17:27, Jules wrote: ? Hi Massimo, Many thanks for reporting that. I missed one :-( If you want to fix it yourself, it's very simple. Edit /opt/zendto/www/unlock.php. At line 78 you should see the line $theDropbox->authenticator()->validUsername($user, $props, $errormsg); Replace that 1 line with these 2: $errormsg = ''; $theDropbox->authenticator()->validUsername($user, $props, $errormsg); and refresh the page in your web browser. That should fix it. Otherwise, the fix will be in the next beta. As an alternative to the "unlock" page, there is a very simple "unlockuser" command in /opt/zendto/bin that you can run by hand on the command-line. Mostly you just want to do /opt/zendto/bin/unlockuser -a to unlock all locked users. Run it without the "-a" to see the usage. Cheers, Jules. On 08/10/2020 15:48, Massimo Forni via ZendTo wrote: -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at nwra.com Fri Oct 16 16:16:43 2020 From: orion at nwra.com (Orion Poplawski) Date: Fri, 16 Oct 2020 09:16:43 -0600 Subject: [ZendTo] Retaining historical usage References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> Message-ID: I got the following request from one of our users. It seems like it might reasonable to do. Thoughts? ----- It'd be useful if the ZendTo Inbox & Outbox tabs could retain their listings after the items therein are no longer active. The Inbox & Outbox tabs list the active items recently dropped-off or available for pick-up. Once they expire (after 2 weeks, by default), the items disappear from the lists. I appreciate that the payloads can get quite large, so it may be impractical to retain those for long times. But some simple records shouldn't require much storage, such as that items were dropped off by NWRA user and when and for whom, or that items were dropped off for NWRA user and when and by whom, and the total size of the payload and whether it was actually picked up. Any option to retain that much information for longer time -- well after the payloads have expired? I occasionally need to refer customers to drop-offs or pick-ups months later, sometimes several years later. Ideally, the simple record would also store more details of the payload, including names and sizes of individual files, their descriptions, and the comments associated with the drop-off. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3843 bytes Desc: S/MIME Cryptographic Signature URL: From Massimo.Forni at turboden.it Fri Oct 16 16:28:44 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Fri, 16 Oct 2020 15:28:44 +0000 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> <7bf1fe7efcfc441faf11876d484f6a1d@Mailbox13.turboden.local> Message-ID: +1 for me There could be an option in the settings for the "record retentions" so we could set eg 6 months -----Original Message----- From: ZendTo On Behalf Of Orion Poplawski via ZendTo Sent: venerd? 16 ottobre 2020 17:17 To: ZendTo Users Cc: Orion Poplawski Subject: [ZendTo] Retaining historical usage I got the following request from one of our users. It seems like it might reasonable to do. Thoughts? ----- It'd be useful if the ZendTo Inbox & Outbox tabs could retain their listings after the items therein are no longer active. The Inbox & Outbox tabs list the active items recently dropped-off or available for pick-up. Once they expire (after 2 weeks, by default), the items disappear from the lists. I appreciate that the payloads can get quite large, so it may be impractical to retain those for long times. But some simple records shouldn't require much storage, such as that items were dropped off by NWRA user and when and for whom, or that items were dropped off for NWRA user and when and by whom, and the total size of the payload and whether it was actually picked up. Any option to retain that much information for longer time -- well after the payloads have expired? I occasionally need to refer customers to drop-offs or pick-ups months later, sometimes several years later. Ideally, the simple record would also store more details of the payload, including names and sizes of individual files, their descriptions, and the comments associated with the drop-off. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/ -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. From Jules at Zend.To Fri Oct 16 16:48:21 2020 From: Jules at Zend.To (Jules) Date: Fri, 16 Oct 2020 16:48:21 +0100 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> <7bf1fe7efcfc441faf11876d484f6a1d@Mailbox13.turboden.local> Message-ID: Orion, Massimo, Currently ZendTo wipes all trace (apart from the logs which are controlled by logrotate) of expired/deleted drop-offs. As a result, nothing grows over time. Even including the data for the usage stats graphs that admins can see. That stays constant size too. If nothing grows, you never suddenly run out of space. Which improves reliability and reduces support costs. But yes, I can see your point. This feature would be useful for some sites. I'm going to need to have a good think about exactly how to do this sensibly. It would probably involve an extra button on the Inbox/Outbox pages that would show you a separate log of past drop-offs that were to/from you. And do note that it is *impossible* to prove that someone *has* downloaded a drop-off. You can prove they haven't tried to download it, but you can't prove they have completely downloaded the file. So don't start relying on that particular "tickbox". It's just the way the Internet works these days, there's nothing I nor anyone else can do to change that. I'll have a think... Cheers, Jules. On 16/10/2020 16:28, Massimo Forni via ZendTo wrote: > +1 for me > There could be an option in the settings for the "record retentions" so we could set eg 6 months > > -----Original Message----- > From: ZendTo On Behalf Of Orion Poplawski via ZendTo > Sent: venerd? 16 ottobre 2020 17:17 > To: ZendTo Users > Cc: Orion Poplawski > Subject: [ZendTo] Retaining historical usage > > I got the following request from one of our users. It seems like it might reasonable to do. Thoughts? > > ----- > > It'd be useful if the ZendTo Inbox & Outbox tabs could retain their listings after the items therein are no longer active. > > The Inbox & Outbox tabs list the active items recently dropped-off or available for pick-up. Once they expire (after 2 weeks, by default), the items disappear from the lists. > > I appreciate that the payloads can get quite large, so it may be impractical to retain those for long times. But some simple records shouldn't require much storage, such as that > > items were dropped off by NWRA user and when and for whom, or that > items were dropped off for NWRA user and when and by whom, > > and the total size of the payload and whether it was actually picked up. > > Any option to retain that much information for longer time -- well after the payloads have expired? I occasionally need to refer customers to drop-offs or pick-ups months later, sometimes several years later. > > Ideally, the simple record would also store more details of the payload, including names and sizes of individual files, their descriptions, and the comments associated with the drop-off. > > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane orion at nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > -- > > Massimo Forni > ICT Infrastructure Manager > > Mobile: +393474110278 > > ________________________________ > > Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy > t. +39 030 3552001 I f. +39 030 3552011 > www.turboden.com > > > Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From klou at themusiclink.net Fri Oct 16 17:20:27 2020 From: klou at themusiclink.net (Kris Lou) Date: Fri, 16 Oct 2020 09:20:27 -0700 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> <7bf1fe7efcfc441faf11876d484f6a1d@Mailbox13.turboden.local> Message-ID: > > items were dropped off by NWRA user and when and for whom, or that > items were dropped off for NWRA user and when and by whom, Retaining the checksum might be helpful as well. Kris Lou klou at themusiclink.net On Fri, Oct 16, 2020 at 8:48 AM Jules via ZendTo wrote: > Orion, Massimo, > > Currently ZendTo wipes all trace (apart from the logs which are controlled > by logrotate) of expired/deleted drop-offs. > As a result, nothing grows over time. Even including the data for the > usage stats graphs that admins can see. That stays constant size too. > If nothing grows, you never suddenly run out of space. > Which improves reliability and reduces support costs. > > But yes, I can see your point. This feature would be useful for some sites. > > I'm going to need to have a good think about exactly how to do this > sensibly. It would probably involve an extra button on the Inbox/Outbox > pages that would show you a separate log of past drop-offs that were > to/from you. > > And do note that it is *impossible* to prove that someone *has* downloaded > a drop-off. You can prove they haven't tried to download it, but you can't > prove they have completely downloaded the file. So don't start relying on > that particular "tickbox". It's just the way the Internet works these days, > there's nothing I nor anyone else can do to change that. > > I'll have a think... > > Cheers, > Jules. > > On 16/10/2020 16:28, Massimo Forni via ZendTo wrote: > > +1 for me > There could be an option in the settings for the "record retentions" so we could set eg 6 months > > -----Original Message----- > From: ZendTo On Behalf Of Orion Poplawski via ZendTo > Sent: venerd? 16 ottobre 2020 17:17 > To: ZendTo Users > Cc: Orion Poplawski > Subject: [ZendTo] Retaining historical usage > > I got the following request from one of our users. It seems like it might reasonable to do. Thoughts? > > ----- > > It'd be useful if the ZendTo Inbox & Outbox tabs could retain their listings after the items therein are no longer active. > > The Inbox & Outbox tabs list the active items recently dropped-off or available for pick-up. Once they expire (after 2 weeks, by default), the items disappear from the lists. > > I appreciate that the payloads can get quite large, so it may be impractical to retain those for long times. But some simple records shouldn't require much storage, such as that > > items were dropped off by NWRA user and when and for whom, or that > items were dropped off for NWRA user and when and by whom, > > and the total size of the payload and whether it was actually picked up. > > Any option to retain that much information for longer time -- well after the payloads have expired? I occasionally need to refer customers to drop-offs or pick-ups months later, sometimes several years later. > > Ideally, the simple record would also store more details of the payload, including names and sizes of individual files, their descriptions, and the comments associated with the drop-off. > > > -- > Orion Poplawski > Manager of NWRA Technical Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane orion at nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > -- > > Massimo Forni > ICT Infrastructure Manager > > Mobile: +393474110278 > > ________________________________ > > Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy > t. +39 030 3552001 I f. +39 030 3552011www.turboden.com > > > Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. > > _______________________________________________ > ZendTo mailing listZendTo at zend.tohttp://jul.es/mailman/listinfo/zendto > > > Jules > > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Fri Oct 16 17:25:37 2020 From: john.thurston at alaska.gov (John Thurston) Date: Fri, 16 Oct 2020 08:25:37 -0800 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> Message-ID: On 10/16/2020 7:16 AM, Orion Poplawski via ZendTo wrote: > I got the following request from one of our users.? It seems like it > might reasonable to do.? Thoughts? -1 And if it is implemented, I hope it is default==false. ZendTo is an ad-hoc file transfer mechanism. When the work is done, it should disappear. I don't want inactive transactions cluttering up the web interface and confusing my customers. Notifications of the activity was handed out to the users at the time the activity took place. -- 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 Massimo.Forni at turboden.it Fri Oct 16 17:28:50 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Fri, 16 Oct 2020 16:28:50 +0000 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> , Message-ID: I just want to clarify that I originally envisioned this in the admin section, where the admins can see all the old records, not in the user sections Sent from my iPhone > On 16 Oct 2020, at 18:26, John Thurston via ZendTo wrote: > > ?On 10/16/2020 7:16 AM, Orion Poplawski via ZendTo wrote: >> I got the following request from one of our users. It seems like it might reasonable to do. Thoughts? > > -1 > > And if it is implemented, I hope it is default==false. > > ZendTo is an ad-hoc file transfer mechanism. When the work is done, it should disappear. I don't want inactive transactions cluttering up the web interface and confusing my customers. Notifications of the activity was handed out to the users at the time the activity took place. > > -- > 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 > https://urldefense.com/v3/__http://jul.es/mailman/listinfo/zendto__;!!BYEqwblc0Q!iBIy2ATyJYDZ59fTEJDSxHTFOk1hkJd9so4H5YaxVO0enGjWO8FunHQIDoMwEIek1zSDUw$ -- Massimo Forni ICT Infrastructure Manager Mobile: +393474110278 ________________________________ Turboden S.p.A. I via Cernaia 10 I 25124 Brescia I Italy t. +39 030 3552001 I f. +39 030 3552011 www.turboden.com Confidentiality notice: this message, together with its attachments, may contain strictly confidential and/or legally privileged information and it is destined solely to the intended addressee(s), who only may use it under his/their responsibility. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. From john.thurston at alaska.gov Fri Oct 16 17:32:54 2020 From: john.thurston at alaska.gov (John Thurston) Date: Fri, 16 Oct 2020 08:32:54 -0800 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> Message-ID: On 10/16/2020 8:28 AM, Massimo Forni wrote: > I just want to clarify that I originally envisioned this in the admin > section, where the admins can see all the old records, not in the > user sections In which case I'm going to say: -2 An admin already has the information you seek in the activity log. (See my .sig for details) -- 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 Mon Oct 19 09:53:22 2020 From: Jules at Zend.To (Jules) Date: Mon, 19 Oct 2020 09:53:22 +0100 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <6671ee4d-c0cd-d543-fbf5-d09f78d50efd@nwra.com> Message-ID: <64b5fb70-8443-d217-ded2-21c837fb658a@Zend.To> All, We appear to have about as many '+' votes as '-' votes. And if it is only for admin use (as Massimo says), then John is quite right that all that information is in the logs. If there is any bit of info that is *not* in the logs, please do tell me. When a new drop-off is created, the ZendTo logs include quite a lot of data about it, even including the language they used and what browser they used (set browscap in your php.ini to the browscap.ini file in /opt/zendto/lib and it will interpret the "USER_AGENT" string into something sensible). If you want to search logs, use grep. If you want to search compressed logs, use zgrep. Unless we see lots more '+' votes for this, I'm going to let it lie. Thoughts? Jules. On 16/10/2020 17:32, John Thurston via ZendTo wrote: > On 10/16/2020 8:28 AM, Massimo Forni wrote: >> I just want to clarify that I originally envisioned this in the admin >> section, where the admins can see all the old records, not in the >> user sections > > > In which case I'm going to say: > > -2 > > An admin already has the information you seek in the activity log. > (See my .sig for details) > > -- > 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 www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at nwra.com Fri Oct 23 22:49:55 2020 From: greg at nwra.com (Greg Bullock) Date: Fri, 23 Oct 2020 14:49:55 -0700 Subject: [ZendTo] Retaining historical usage References: <20201023214955.D71693407BC@mail.nwra.com> Message-ID: +1 Although I'm the source of the original request, I think mine qualifies as an separate vote. :-) And to clarify, I requested this for the user sections, as Jules inferred, not in the in the admin section, which already has sufficient logging. -Greg On 19/10/2020 09:53, Jules via ZendTo wrote: All, We appear to have about as many '+' votes as '-' votes. And if it is only for admin use (as Massimo says), then John is quite right that all that information is in the logs. If there is any bit of info that is *not* in the logs, please do tell me. When a new drop-off is created, the ZendTo logs include quite a lot of data about it, even including the language they used and what browser they used (set browscap in your php.ini to the browscap.ini file in /opt/zendto/lib and it will interpret the "USER_AGENT" string into something sensible). If you want to search logs, use grep. If you want to search compressed logs, use zgrep. Unless we see lots more '+' votes for this, I'm going to let it lie. Thoughts? Jules. -- Regards. Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Oct 26 09:25:38 2020 From: Jules at Zend.To (Jules) Date: Mon, 26 Oct 2020 09:25:38 +0000 Subject: [ZendTo] Retaining historical usage In-Reply-To: References: <20201023214955.D71693407BC@mail.nwra.com> Message-ID: Hi Greg, Noted. :-) Cheers, Jules. On 23/10/2020 22:49, Greg Bullock via ZendTo wrote: > > +1 > > Although I'm the source of the original request, I think mine > qualifies as an separate vote. :-) > > And to clarify, I requested this for the user sections, as Jules > inferred, not in the in the admin section, which already has > sufficient logging. > > -Greg > > On 19/10/2020 09:53, Jules via ZendTo wrote: > > All, > > We appear to have about as many '+' votes as '-' votes. > > And if it is only for admin use (as Massimo says), then John is quite > right that all that information is in the logs. > If there is any bit of info that is *not* in the logs, please do > tell me. > When a new drop-off is created, the ZendTo logs include quite a > lot of > data about it, even including the language they used and what browser > they used (set browscap in your php.ini to the browscap.ini file in > /opt/zendto/lib and it will interpret the "USER_AGENT" string into > something sensible). > > If you want to search logs, use grep. > If you want to search compressed logs, use zgrep. > > Unless we see lots more '+' votes for this, I'm going to let it lie. > > Thoughts? > Jules. > > -- > > Regards. > Greg > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: