From john.thurston at alaska.gov Tue Dec 1 20:45:33 2020 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 1 Dec 2020 11:45:33 -0900 Subject: [ZendTo] Abandoned files in 'incoming' References: Message-ID: We're running 6.05-4 on CentOS 7 From time to time, I'm finding abandoned files in 'incoming', of the form: > bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.1 > bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.2 > bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.3 > bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.4 The dates on the files leave me confident they are derelict, so I smoke the oldest and reclaim my disk space. I've tried to find the footprints of these files in logs, but have failed. It looks to me like these are used during upload, before ZendTo creates a 16-character directory name in 'dropoffs' and relocates the files to it. But it doesn't look like ZendTo logs the activity until the upload is complete. > Info: new unencrypted dropoff T9dFqdfZENNkgnAd of 3 files created I'd like to do something more than periodically empty my disk of abandoned files. I'd like to figure out why they are abandoned, and correct the problem. In what log should I be looking to find more footprints? -- -- 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 Wed Dec 2 09:57:15 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Wed, 2 Dec 2020 09:57:15 +0000 Subject: [ZendTo] Suggestion: replace google reCAPTCHA with hCaptcha References: Message-ID: Hi all, Internally we are moving away from google reCAPTCHA and migrating to https://www.hcaptcha.com/ since it does not collect/resell user data. What do you think about having it as a secondary option for ZendTo instead of Google? TY -- 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 Wed Dec 2 10:57:38 2020 From: Jules at Zend.To (Jules) Date: Wed, 2 Dec 2020 10:57:38 +0000 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: References: Message-ID: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> John, There should be a cron job that cleans these up for you. It should be in /etc/cron.d/zendto. The relevant line in that file is this one: 5 */4 * * * root find -H /var/zendto/incoming -type f -mmin +1440 -delete >/dev/null 2>&1 This will fire every 4 hours, deleting any files in /var/zendto/incoming that are more than 24 hours old. ZendTo takes files from the user's browser in chunks nowadays, as that gets around all the problems caused by "network protection" devices/software in all their ugly forms. Those are numbered chunks from an upload that never completed. They are totally superfluous, and should be deleted automatically by the cron job above. I would be interested to hear if that line is missing from your cron.d file or if you have a ".rpmnew" file in there or similar. I haven't bothered logging the individual chunks as they're by default only 50 MB. So there can be an awful lot of them appearing on a busy server, and they amount to nothing useful unless the upload completes properly, at which point they are creating a new drop-off and so lots of stuff is logged. I hope that clears up that question for you. Cheers, Jules. On Tue 01/12/20 20:45, John Thurston via ZendTo wrote: > We're running 6.05-4 on CentOS 7 > From time to time, I'm finding abandoned files in 'incoming', of the > form: >> bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.1 >> bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.2 >> bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.3 >> bKH5SY6MTmy2fJ4b6N3N5XbyjCbnw8if.4 > > The dates on the files leave me confident they are derelict, so I > smoke the oldest and reclaim my disk space. > > I've tried to find the footprints of these files in logs, but have > failed. It looks to me like these are used during upload, before > ZendTo creates a 16-character directory name in 'dropoffs' and > relocates the files to it. But it doesn't look like ZendTo logs the > activity until the upload is complete. > >> Info: new unencrypted dropoff T9dFqdfZENNkgnAd of 3 files created > > I'd like to do something more than periodically empty my disk of > abandoned files. I'd like to figure out why they are abandoned, and > correct the problem. In what log should I be looking to find more > footprints? > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Wed Dec 2 11:11:50 2020 From: Jules at Zend.To (Jules) Date: Wed, 2 Dec 2020 11:11:50 +0000 Subject: [ZendTo] Suggestion: replace google reCAPTCHA with hCaptcha In-Reply-To: References: Message-ID: <2f624a70-4f2b-f74d-79ca-d68ad6ed276a@Zend.To> Massimo, That most definitely looks worth investigating. Thanks for the tip! Cheers, Jules. On Wed 02/12/20 09:57, Massimo Forni via ZendTo wrote: > > Hi all, > > Internally we are moving away from google reCAPTCHA and migrating to > https://www.hcaptcha.com/ since it does > not collect/resell user data. > > What do you think about having it as a secondary option for ZendTo > instead of Google? > > TY > > -- > > *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 'Think globally, act locally.' - Friends of the Earth www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Wed Dec 2 23:33:03 2020 From: john.thurston at alaska.gov (John Thurston) Date: Wed, 2 Dec 2020 14:33:03 -0900 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: References: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> <833ced01-e607-4f40-b8ca-764daf426823@alaska.gov> Message-ID: a'yep, that job is there, and running the 'find' command interactively returns appropriate files. I don't recall how old the files were the last time my disk-full alarm went off and I shoveled it out. It is possible that job was just about to trigger and I was premature. It is likely that our increased use of this tool is simply over-running my small disks. I have two more questions: 1) I see a reference in the preferences: // This is where your drop-offs are stored. // It must be on the same filesystem as /var/zendto/incoming, and // on preferably on the same filesystem as /var/zendto. 'dropboxDirectory' => NSSDROPBOX_DATA_DIR."dropoffs", Why the "same filesystem" requirement for 'incoming' and 'dropoffs'? 2) The lines above define 'dropoffs'. Where is 'incoming' defined? -- 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 12/2/2020 1:57 AM, Jules wrote: > There should be a cron job that cleans these up for you. > It should be in /etc/cron.d/zendto. > The relevant line in that file is this one: > > 5 */4 * * * root find -H /var/zendto/incoming -type f -mmin +1440 > -delete >/dev/null 2>&1 > > This will fire every 4 hours, deleting any files in /var/zendto/incoming > that are more than 24 hours old. From Jules at Zend.To Thu Dec 3 11:52:46 2020 From: Jules at Zend.To (Jules) Date: Thu, 3 Dec 2020 11:52:46 +0000 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: References: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> <833ced01-e607-4f40-b8ca-764daf426823@alaska.gov> Message-ID: <06613d31-2c85-becd-0ed4-0e11c8c73bbe@Zend.To> Hi John, On Wed 02/12/20 23:33, John Thurston via ZendTo wrote: > a'yep, that job is there, and running the 'find' command interactively > returns appropriate files. > > I don't recall how old the files were the last time my disk-full alarm > went off and I shoveled it out. It is possible that job was just about > to trigger and I was premature. It is likely that our increased use of > this tool is simply over-running my small disks. That's quite possible. Just about every ZendTo installation I have seen has an ever-increasing disk space requirement. On my own installation here at Southampton, I have recently had to up the max drop-off size to 100GB (we have a non-clinical team who do MRI scans of tiny objects, and create data like it's going out of fashion). And after adding the 4th TB of disk space, we've had to reduce the default lifetime from 32 days to 22 days, just to try to limit its hunger for space! > > I have two more questions: > > 1) I see a reference in the preferences: > > ? // This is where your drop-offs are stored. > ? // It must be on the same filesystem as /var/zendto/incoming, and > ? // on preferably on the same filesystem as /var/zendto. > ? 'dropboxDirectory'???? => NSSDROPBOX_DATA_DIR."dropoffs", > > Why the "same filesystem" requirement for 'incoming' and 'dropoffs'? Because it basically does a "mv" from the incoming directory to the dropoffs directory. If they are on the same filesystem, that is an instant atomic operation. If they aren't, that could take minutes, where the user will just be left waiting and wondering why his upload got to 100% and then just sat there! > > 2) The lines above define 'dropoffs'. Where is 'incoming' defined? php.ini. It's the temporary upload location that PHP uses. Cheers, Jules. > > On 12/2/2020 1:57 AM, Jules wrote: >> There should be a cron job that cleans these up for you. >> It should be in /etc/cron.d/zendto. >> The relevant line in that file is this one: >> >> 5 */4 * * * root find -H /var/zendto/incoming -type f -mmin +1440 >> -delete >/dev/null 2>&1 >> >> This will fire every 4 hours, deleting any files in >> /var/zendto/incoming that are more than 24 hours old. > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Solutions nearly always come from the direction you least expect, which means there's no point trying to look in that direction because it won't be coming from there.' - Douglas Adams www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Tue Dec 8 20:28:21 2020 From: john.thurston at alaska.gov (John Thurston) Date: Tue, 8 Dec 2020 11:28:21 -0900 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: References: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> <833ced01-e607-4f40-b8ca-764daf426823@alaska.gov> <06613d31-2c85-becd-0ed4-0e11c8c73bbe@Zend.To> Message-ID: On 12/3/2020 2:52 AM, Jules wrote: >> 1) I see a reference in the preferences: >> >> ? // This is where your drop-offs are stored. >> ? // It must be on the same filesystem as /var/zendto/incoming, and >> ? // on preferably on the same filesystem as /var/zendto. >> ? 'dropboxDirectory'???? => NSSDROPBOX_DATA_DIR."dropoffs", >> >> Why the "same filesystem" requirement for 'incoming' and 'dropoffs'? > Because it basically does a "mv" from the incoming directory to the > dropoffs directory. > If they are on the same filesystem, that is an instant atomic operation. > If they aren't, that could take minutes, where the user will just be > left waiting and wondering why his upload got to 100% and then just sat > there! >> >> 2) The lines above define 'dropoffs'. Where is 'incoming' defined? > php.ini. It's the temporary upload location that PHP uses. Found it, thank you. Why isn't this defined in preferences (with the rest)? It could be explicitly listed, or relative to NSSDROPBOX_DATA_DIR (especially considering we'd like all that stuff to be in a common file system). By tweaking php.ini, and the path in the scavenging cron job, have I set myself up for complications in the next ZendTo version-update? -- 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 Thu Dec 10 15:28:29 2020 From: Jules at Zend.To (Jules) Date: Thu, 10 Dec 2020 15:28:29 +0000 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: References: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> <833ced01-e607-4f40-b8ca-764daf426823@alaska.gov> <06613d31-2c85-becd-0ed4-0e11c8c73bbe@Zend.To> Message-ID: <38235bbd-e641-8d58-79c0-786fdcbf7336@Zend.To> John, On Tue 08/12/20 20:28, John Thurston via ZendTo wrote: > > On 12/3/2020 2:52 AM, Jules wrote: >>> 1) I see a reference in the preferences: >>> >>> ? // This is where your drop-offs are stored. >>> ? // It must be on the same filesystem as /var/zendto/incoming, and >>> ? // on preferably on the same filesystem as /var/zendto. >>> ? 'dropboxDirectory'???? => NSSDROPBOX_DATA_DIR."dropoffs", >>> >>> Why the "same filesystem" requirement for 'incoming' and 'dropoffs'? > >> Because it basically does a "mv" from the incoming directory to the >> dropoffs directory. >> If they are on the same filesystem, that is an instant atomic operation. >> If they aren't, that could take minutes, where the user will just be >> left waiting and wondering why his upload got to 100% and then just >> sat there! > >>> >>> 2) The lines above define 'dropoffs'. Where is 'incoming' defined? >> php.ini. It's the temporary upload location that PHP uses. > > Found it, thank you. > > Why isn't this defined in preferences (with the rest)? Historical, that's all. At that point I probably didn't know about ini_set(). :-) > > It could be explicitly listed, or relative to NSSDROPBOX_DATA_DIR > (especially considering we'd like all that stuff to be in a common > file system). Yet it should. Right now I have an important bug fix to get out the door (I really must remember to create git branches occasionally), but this will definitely get added to the list. > By tweaking php.ini, and the path in the scavenging cron job, have I > set myself up for complications in the next ZendTo version-update? You shouldn't have, no. It won't overwrite the cron job as you've changed it, and ZendTo never touches php.ini again after the Installer has done its bit. Which also reminds me that I need to improve the Installer. Pretty much all distros now have a /etc/php.d directory of some sort somewhere, so I can just put all the ZendTo settings in a new file in there, and not need to touch the main php.ini file at all. 1 change I am definitely going to make right now though, is to change the yum/rpm upgrade behaviour so that modified *.tpl template files are moved out of the way and the new ones become active. I get too many queries from people who slightly tweaked one of the template files, and after they upgrade they can't understand why it breaks. I won't overwrite their tweaked file, but I will now move it to *.rpmsave and put the new one in place. They will then immediately see a ZendTo service that works, but is just missing the odd bit of customisation they did. Cheers, Jules. > > > -- > 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 'Find a place inside where there's joy, and the joy will burn out the pain.' - Joseph Campbell www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Dec 10 15:55:11 2020 From: Jules at Zend.To (Jules) Date: Thu, 10 Dec 2020 15:55:11 +0000 Subject: [ZendTo] New beta release 6.06-3 Message-ID: <79a9c8ea-5d0c-926b-e859-810ebae03bfd@Zend.To> Hi folks, I have just released a new beta 6.06-3. As usual, get it from the beta page at ??? zend.to/beta The list of changes & fixes is fairly extensive, but the urgent one for me was that if you sent a "request for a drop-off" for some time in the future, and you weren't in the same timezone as the ZendTo server, it would muck up the start and end times completely. Here is the full Change Log since the last production release (6.05)... - Number of days a drop-off lives before expiry shown at the bottom ? of the main menu is now the default number of days, not the maximum ? number of days. - Template caching totally disabled. - Bug fixed where requesting a drop-off from a different timezone from ? the server would result in incorrect start/expiry times being set. - Updated moment.js to latest version. - Changed yum/rpm upgrade behaviour for templates (*.tpl) like this: ? Before, if you changed a template file and then upgraded to a newer ? RPM with a newer version of that template file, your old one would be ? left in place and the new one installed with ".rpmnew" on the end. ? You would have to know to check for these and handle them appropriately ? or else most likely your ZendTo would not work. ? Now, your old one will be renamed to ".rpmsave" and the new one ? installed and used. Your ZendTo site will work, but you may be missing ? any local customisations you had made before. But the old version is ? still there as ".rpmsave" so you can apply your changes to the new one. ? Note: Hopefully you use the locale translations system to change the ??????? text displayed by the templates, so you aren't modifying them ??????? at all! - Corrected missing parameter to validUsername() when attempting to ? unlock users. - Fixed bug in language changing, which could have resulted in changing ? language not immediately taking effect. - Minor change to header.tpl to allow Manty to set $zendToURL to '' and ? still have the Home button tidily. - Increased length of DB fields storing Organization names to 256 ? characters, and added length checks to "request a drop-off" code so ? excessively long organization names won't break anything. - Added "--startDateTime" and "--sendemail" parameters to "autorequest" ? automation script. I would be really grateful if you could just quickly test it for me, at which point I can do a production release for you all. Many thanks! P.S. The apparently "boring legal disclaimer" below isn't quite as obvious as it looks... ;-) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Thu Dec 10 16:42:14 2020 From: Jules at Zend.To (Jules) Date: Thu, 10 Dec 2020 16:42:14 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> Message-ID: <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> John and others, I didn't ignore this, I just mentally added it to the list without remembering to reply to you about it! :-/ I should be able to do hours and days and stuff like that too. So that it matches with what happens in the code already, can we agree to use 1024, 1024^2, 1024^3 etc as the K, M and G multiples? For times I could allow s, h, d, w. So the multipliers would be (ignoring case): k = 1024 m = 1024*1024 g = 1024*1024*1024 s = 1 h = 60*60 d = 60*60*24 w = 60*60*24*7 Are there any I have missed (I'm avoiding minutes in favour of megs). The syntax would have to change in the preferences.php file where you chose to use a suffix, as ??? 'maxBytesForDropoff' => *24G*, is not valid PHP, it would need to be ??? 'maxBytesForDropoff' => *'24G'*, but you would only need the quotes round ones where you chose to use a suffix. Sound okay to everyone? Cheers, Jules. On Tue 17/11/20 19:13, John Thurston via ZendTo wrote: > Computers are good at doing math. Can we have the option of including > units on some preferences? > > I'm thinking, particularly, about: > ? maxBytesForDropoff > ? maxBytesForFile > ? maxBytesForChecksum > ? maxBytesForEncryption > > These are currently specified in bytes. This is generally a long > number which is hard to read and easy to stumble over. May we have the > default continue to be "number of bytes" but have it accept an > optional unit-suffix? For example: > ? 'maxBytesForDropoff'?? => 25769790582, > could be specified as: > ? 'maxBytesForDropoff'?? => 24G, > > Old preferences would continue to work, and new preferences would be > easier to read. > Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Solutions nearly always come from the direction you least expect, which means there's no point trying to look in that direction because it won't be coming from there.' - Douglas Adams www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Massimo.Forni at turboden.it Thu Dec 10 16:49:12 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Thu, 10 Dec 2020 16:49:12 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> Message-ID: Hi, Just to point out that in the SI the Mega, Giga, etc are all capital letters, this way you can still use ?m? for minutes https://en.wikipedia.org/wiki/International_System_of_Units#Prefixes best regards From: ZendTo On Behalf Of Jules via ZendTo Sent: gioved? 10 dicembre 2020 17:42 To: ZendTo Users Cc: Jules Subject: Re: [ZendTo] Feature request: optional units on some preferences John and others, I didn't ignore this, I just mentally added it to the list without remembering to reply to you about it! :-/ I should be able to do hours and days and stuff like that too. So that it matches with what happens in the code already, can we agree to use 1024, 1024^2, 1024^3 etc as the K, M and G multiples? For times I could allow s, h, d, w. So the multipliers would be (ignoring case): k = 1024 m = 1024*1024 g = 1024*1024*1024 s = 1 h = 60*60 d = 60*60*24 w = 60*60*24*7 Are there any I have missed (I'm avoiding minutes in favour of megs). The syntax would have to change in the preferences.php file where you chose to use a suffix, as 'maxBytesForDropoff' => 24G, is not valid PHP, it would need to be 'maxBytesForDropoff' => '24G', but you would only need the quotes round ones where you chose to use a suffix. Sound okay to everyone? Cheers, Jules. On Tue 17/11/20 19:13, John Thurston via ZendTo wrote: Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Solutions nearly always come from the direction you least expect, which means there's no point trying to look in that direction because it won't be coming from there.' - Douglas Adams www.Zend.To Twitter: @JulesFM -- 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 Dec 10 16:55:28 2020 From: Jules at Zend.To (Jules) Date: Thu, 10 Dec 2020 16:55:28 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> Message-ID: Hi Massimo, Fair point. Sadly they are also supposed to be powers of 10 and not 2. And I never realised that Z was smaller than Y and not the other way round. That's bonkers! Will people always get the case right, even when they never read the instructions? Or do I only insist on "m" and "M" having the right case, and ignore the case on all the others? Bit awkward. Only other option is to infer whether it's a byte count or a time duration from the name of the setting (/bytes/i ==> byte count, rules like that). Cheers, Jules. On Thu 10/12/20 16:49, Massimo Forni wrote: > > Hi, > > Just to point out that in the SI the Mega, Giga, etc are all capital > letters, this way you can still use ?m? for minutes > > https://en.wikipedia.org/wiki/International_System_of_Units#Prefixes > > > best regards > > *From:*ZendTo *On Behalf Of *Jules via ZendTo > *Sent:* gioved? 10 dicembre 2020 17:42 > *To:* ZendTo Users > *Cc:* Jules > *Subject:* Re: [ZendTo] Feature request: optional units on some > preferences > > John and others, > > I didn't ignore this, I just mentally added it to the list without > remembering to reply to you about it! :-/ > > I should be able to do hours and days and stuff like that too. > So that it matches with what happens in the code already, can we agree > to use 1024, 1024^2, 1024^3 etc as the K, M and G multiples? > For times I could allow s, h, d, w. > > So the multipliers would be (ignoring case): > k = 1024 > m = 1024*1024 > g = 1024*1024*1024 > s = 1 > h = 60*60 > d = 60*60*24 > w = 60*60*24*7 > > Are there any I have missed (I'm avoiding minutes in favour of megs). > > The syntax would have to change in the preferences.php file where you > chose to use a suffix, as > ??? 'maxBytesForDropoff' => *24G*, > is not valid PHP, it would need to be > ??? 'maxBytesForDropoff' => *'24G'*, > but you would only need the quotes round ones where you chose to use a > suffix. > > Sound okay to everyone? > > Cheers, > Jules. > > On Tue 17/11/20 19:13, John Thurston via ZendTo wrote: > > Computers are good at doing math. Can we have the option of > including units on some preferences? > > I'm thinking, particularly, about: > ? maxBytesForDropoff > ? maxBytesForFile > ? maxBytesForChecksum > ? maxBytesForEncryption > > These are currently specified in bytes. This is generally a long > number which is hard to read and easy to stumble over. May we have > the default continue to be "number of bytes" but have it accept an > optional unit-suffix? For example: > ? 'maxBytesForDropoff'?? => 25769790582, > could be specified as: > ? 'maxBytesForDropoff'?? => 24G, > > Old preferences would continue to work, and new preferences would > be easier to read. > > > > Jules > -- > Julian Field MEng CEng CITP MBCS MIEEE MACM > 'Solutions nearly always come from the direction you least expect, which > means there's no point trying to look in that direction because it won't > be coming from there.' - Douglas Adams > www.Zend.To > Twitter: @JulesFM > > -- > > *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. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssilva at sgvwater.com Thu Dec 10 17:21:21 2020 From: ssilva at sgvwater.com (Scott Silva) Date: Thu, 10 Dec 2020 17:21:21 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> <54D3F6A07E3F2A4AAD4CBA73922025F4345D4FF4@FONEXCH01.sgvwc.local> Message-ID: I have found through the years working with people that no matter how idiot proof you think you made something, a more skilled idiot will show up and break it? From: ZendTo On Behalf Of Jules via ZendTo Sent: Thursday, December 10, 2020 9:11 AM To: Massimo Forni ; ZendTo Users Cc: Jules Subject: Re: [ZendTo] Feature request: optional units on some preferences Hi Massimo, Fair point. Sadly they are also supposed to be powers of 10 and not 2. And I never realised that Z was smaller than Y and not the other way round. That's bonkers! Will people always get the case right, even when they never read the instructions? Or do I only insist on "m" and "M" having the right case, and ignore the case on all the others? Bit awkward. Only other option is to infer whether it's a byte count or a time duration from the name of the setting (/bytes/i ==> byte count, rules like that). Cheers, Jules. On Thu 10/12/20 16:49, Massimo Forni wrote: Hi, Just to point out that in the SI the Mega, Giga, etc are all capital letters, this way you can still use ?m? for minutes https://en.wikipedia.org/wiki/International_System_of_Units#Prefixes best regards From: ZendTo On Behalf Of Jules via ZendTo Sent: gioved? 10 dicembre 2020 17:42 To: ZendTo Users Cc: Jules Subject: Re: [ZendTo] Feature request: optional units on some preferences John and others, I didn't ignore this, I just mentally added it to the list without remembering to reply to you about it! :-/ I should be able to do hours and days and stuff like that too. So that it matches with what happens in the code already, can we agree to use 1024, 1024^2, 1024^3 etc as the K, M and G multiples? For times I could allow s, h, d, w. So the multipliers would be (ignoring case): k = 1024 m = 1024*1024 g = 1024*1024*1024 s = 1 h = 60*60 d = 60*60*24 w = 60*60*24*7 Are there any I have missed (I'm avoiding minutes in favour of megs). The syntax would have to change in the preferences.php file where you chose to use a suffix, as 'maxBytesForDropoff' => 24G, is not valid PHP, it would need to be 'maxBytesForDropoff' => '24G', but you would only need the quotes round ones where you chose to use a suffix. Sound okay to everyone? Cheers, Jules. On Tue 17/11/20 19:13, John Thurston via ZendTo wrote: Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Solutions nearly always come from the direction you least expect, which means there's no point trying to look in that direction because it won't be coming from there.' - Douglas Adams www.Zend.To Twitter: @JulesFM -- 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.thurston at alaska.gov Thu Dec 10 17:29:14 2020 From: john.thurston at alaska.gov (John Thurston) Date: Thu, 10 Dec 2020 08:29:14 -0900 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> <271c56ab-f834-c524-a1d1-1394bd21cdc8@alaska.gov> Message-ID: On 12/10/2020 7:55 AM, Jules via ZendTo wrote: > Only other option is to infer whether it's a byte count or a time > duration from the name of the setting That's where I'd go. As I mentioned, "Computers are good at doing math". It's only a couple of lines of code, and it makes the end-user's (my) life easier. I don't mind overloading the letter 'm'. It has a strong, arched shape. It can probably handle the load. The suffixes would be: :: For Size :: k = 1024 m = 1024*1024 g = 1024*1024*1024 :: For Duration :: s = 1 m = 60 h = 60*60 d = 60*60*24 w = 60*60*24*7 -- 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 alt36 at cam.ac.uk Thu Dec 10 18:03:10 2020 From: alt36 at cam.ac.uk (Adam Thorn) Date: Thu, 10 Dec 2020 18:03:10 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> <7a06b805-2f92-dc88-1b7a-482a51aa6584@cam.ac.uk> Message-ID: On 10/12/2020 16:55, Jules via ZendTo wrote: > Will people always get the case right, even when they never read the > instructions? > Or do I only insist on "m" and "M" having the right case, and ignore the > case on all the others? > Bit awkward. Only other option is to infer whether it's a byte count or > a time duration from the name of the setting (/bytes/i ==> byte count, > rules like that). My immediate instinct is to suggest case-sensitivity, because SI prefixes are case-sensitive and m=milli vs M=mega are rather different! But,.. for the size units it might be best to mirror the options specified in https://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes : i.e. accept K/k, M/m, G/g, and use them to mean the "power of 2" values rather than "power of 10". Adam From Massimo.Forni at turboden.it Thu Dec 10 18:04:24 2020 From: Massimo.Forni at turboden.it (Massimo Forni) Date: Thu, 10 Dec 2020 18:04:24 +0000 Subject: [ZendTo] Feature request: optional units on some preferences In-Reply-To: References: <1c502289-0e18-a0c8-917d-c11cca8f393b@alaska.gov> <935067ed-1883-4376-66f3-6c54b9f24cfb@Zend.To> <104afdad39c04cb7826e09633dcf3d13@Mailbox13.turboden.local> Message-ID: Hi again. Php.ini uses M for megabyte as an example? I suspect there is already a php function for this ? From: Jules Sent: gioved? 10 dicembre 2020 17:55 To: Massimo Forni ; ZendTo Users Subject: Re: [ZendTo] Feature request: optional units on some preferences Hi Massimo, Fair point. Sadly they are also supposed to be powers of 10 and not 2. And I never realised that Z was smaller than Y and not the other way round. That's bonkers! Will people always get the case right, even when they never read the instructions? Or do I only insist on "m" and "M" having the right case, and ignore the case on all the others? Bit awkward. Only other option is to infer whether it's a byte count or a time duration from the name of the setting (/bytes/i ==> byte count, rules like that). Cheers, Jules. On Thu 10/12/20 16:49, Massimo Forni wrote: Hi, Just to point out that in the SI the Mega, Giga, etc are all capital letters, this way you can still use ?m? for minutes https://en.wikipedia.org/wiki/International_System_of_Units#Prefixes best regards From: ZendTo On Behalf Of Jules via ZendTo Sent: gioved? 10 dicembre 2020 17:42 To: ZendTo Users Cc: Jules Subject: Re: [ZendTo] Feature request: optional units on some preferences John and others, I didn't ignore this, I just mentally added it to the list without remembering to reply to you about it! :-/ I should be able to do hours and days and stuff like that too. So that it matches with what happens in the code already, can we agree to use 1024, 1024^2, 1024^3 etc as the K, M and G multiples? For times I could allow s, h, d, w. So the multipliers would be (ignoring case): k = 1024 m = 1024*1024 g = 1024*1024*1024 s = 1 h = 60*60 d = 60*60*24 w = 60*60*24*7 Are there any I have missed (I'm avoiding minutes in favour of megs). The syntax would have to change in the preferences.php file where you chose to use a suffix, as 'maxBytesForDropoff' => 24G, is not valid PHP, it would need to be 'maxBytesForDropoff' => '24G', but you would only need the quotes round ones where you chose to use a suffix. Sound okay to everyone? Cheers, Jules. On Tue 17/11/20 19:13, John Thurston via ZendTo wrote: Computers are good at doing math. Can we have the option of including units on some preferences? I'm thinking, particularly, about: maxBytesForDropoff maxBytesForFile maxBytesForChecksum maxBytesForEncryption These are currently specified in bytes. This is generally a long number which is hard to read and easy to stumble over. May we have the default continue to be "number of bytes" but have it accept an optional unit-suffix? For example: 'maxBytesForDropoff' => 25769790582, could be specified as: 'maxBytesForDropoff' => 24G, Old preferences would continue to work, and new preferences would be easier to read. Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Solutions nearly always come from the direction you least expect, which means there's no point trying to look in that direction because it won't be coming from there.' - Douglas Adams www.Zend.To Twitter: @JulesFM -- 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Fri Dec 11 09:18:10 2020 From: Jules at Zend.To (Jules) Date: Fri, 11 Dec 2020 09:18:10 +0000 Subject: [ZendTo] Abandoned files in 'incoming' In-Reply-To: <38235bbd-e641-8d58-79c0-786fdcbf7336@Zend.To> References: <987d6bc0-6902-a5d1-62b0-79efddfd1324@Zend.To> <833ced01-e607-4f40-b8ca-764daf426823@alaska.gov> <06613d31-2c85-becd-0ed4-0e11c8c73bbe@Zend.To> <38235bbd-e641-8d58-79c0-786fdcbf7336@Zend.To> Message-ID: <7d106702-881e-7f7d-9109-0cfbc82116b7@Zend.To> John, Bad news on this one, I'm afraid. I just checked the PHP docs, and the location of the incoming directory (normally /var/zendto/incoming) can *only* set in php.ini or httpd.conf. In ??? https://www.php.net/manual/en/ini.list.php "upload_tmp_dir" is listed as being of type "PHP_INI_SYSTEM" which, according to ??? https://www.php.net/manual/en/configuration.changes.modes.php means it can't be set in running PHP code. So the definition is going to have to stay where it is. Sorry about that. Cheers, Jules. On Thu 10/12/20 15:28, Jules via ZendTo wrote: > John, > > On Tue 08/12/20 20:28, John Thurston via ZendTo wrote: >> >> On 12/3/2020 2:52 AM, Jules wrote: >>>> 1) I see a reference in the preferences: >>>> >>>> ? // This is where your drop-offs are stored. >>>> ? // It must be on the same filesystem as /var/zendto/incoming, and >>>> ? // on preferably on the same filesystem as /var/zendto. >>>> ? 'dropboxDirectory'???? => NSSDROPBOX_DATA_DIR."dropoffs", >>>> >>>> Why the "same filesystem" requirement for 'incoming' and 'dropoffs'? >> >>> Because it basically does a "mv" from the incoming directory to the >>> dropoffs directory. >>> If they are on the same filesystem, that is an instant atomic >>> operation. >>> If they aren't, that could take minutes, where the user will just be >>> left waiting and wondering why his upload got to 100% and then just >>> sat there! >> >>>> >>>> 2) The lines above define 'dropoffs'. Where is 'incoming' defined? >>> php.ini. It's the temporary upload location that PHP uses. >> >> Found it, thank you. >> >> Why isn't this defined in preferences (with the rest)? > Historical, that's all. At that point I probably didn't know about > ini_set(). :-) > >> >> It could be explicitly listed, or relative to NSSDROPBOX_DATA_DIR >> (especially considering we'd like all that stuff to be in a common >> file system). > Yet it should. > Right now I have an important bug fix to get out the door (I really > must remember to create git branches occasionally), but this will > definitely get added to the list. > >> By tweaking php.ini, and the path in the scavenging cron job, have I >> set myself up for complications in the next ZendTo version-update? > You shouldn't have, no. It won't overwrite the cron job as you've > changed it, and ZendTo never touches php.ini again after the Installer > has done its bit. > > Which also reminds me that I need to improve the Installer. Pretty > much all distros now have a /etc/php.d directory of some sort > somewhere, so I can just put all the ZendTo settings in a new file in > there, and not need to touch the main php.ini file at all. > > 1 change I am definitely going to make right now though, is to change > the yum/rpm upgrade behaviour so that modified *.tpl template files > are moved out of the way and the new ones become active. > I get too many queries from people who slightly tweaked one of the > template files, and after they upgrade they can't understand why it > breaks. > > I won't overwrite their tweaked file, but I will now move it to > *.rpmsave and put the new one in place. They will then immediately see > a ZendTo service that works, but is just missing the odd bit of > customisation they did. > > Cheers, > Jules. > >> >> >> -- >> 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 > > 'Find a place inside where there's joy, and the joy will burn out > the pain.' - Joseph Campbell > > www.Zend.To > Twitter: @JulesFM > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'I've heard that it's possible to grow up. I've just never met anyone who's actually done it.' - Meredith Grey, Grey's Anatomy www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bailey.Coole at outlook.com Fri Dec 11 23:47:25 2020 From: Bailey.Coole at outlook.com (Bailey Coole) Date: Fri, 11 Dec 2020 23:47:25 +0000 Subject: [ZendTo] 500 server error on successful AD authentication References: Message-ID: We're running 6.05-4 on CentOS 8. If an AD user successfully authenticates, they get a 500-server error. If an AD user inputs an incorrect password, they are warned that "The username or password was incorrect" (as expected). If a local (i.e., admin) user authenticates, everything 'works' properly. I don't *think* this is an issue with the ldap/AD config as ldapsearch with the same inputs returns all the expected users and the same settings (different bind account) are in use elsewhere in our infrastructure. Nothing showing in the apache logs, but there is a Fatal error in the php log: [11-Dec-2020 17:45:36 Australia/Perth] PHP Warning: Attempt to read property "value" on null in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.cache.php on line 424 [11-Dec-2020 17:45:42 Australia/Perth] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /opt/zendto/lib/NSSADAuthenticator.php:658 Stack trace: #0 /opt/zendto/lib/NSSADAuthenticator.php(485): NSSADAuthenticator->Tryauthenticate() #1 /opt/zendto/lib/NSSMultiAuthenticator.php(154): NSSADAuthenticator->authenticate() #2 /opt/zendto/lib/NSSDropbox.php(2332): NSSMultiAuthenticator->authenticate() #3 /opt/zendto/lib/NSSDropbox.php(620): NSSDropbox->userFromAuthentication() #4 /opt/zendto/www/index.php(35): NSSDropbox->__construct() #5 {main} thrown in /opt/zendto/lib/NSSADAuthenticator.php on line 658 Any ideas on what could be causing this behaviour? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules at zend.to Mon Dec 14 09:56:06 2020 From: jules at zend.to (jules at zend.to) Date: Mon, 14 Dec 2020 09:56:06 +0000 Subject: [ZendTo] 500 server error on successful AD authentication In-Reply-To: References: Message-ID: Bailey, Interesting one, slightly surprised that (a) it causes an error in your case, and that (b) in that case, no one has seen it before. Edit /opt/zendto/lib/NSSADAuthenticator.php and change line 658 from ??????????????? if ( @$value['count'] >= 1 ) { to ??????????????? if ( is_array($value) && @$value['count'] >= 1 ) { On Fri 11/12/20 23:47, Bailey Coole via ZendTo wrote: > > We're running 6.05-4 on CentOS 8. > > If an AD user successfully authenticates, they get a 500-server error. > > If an AD user inputs an incorrect password, they are warned that "The > username or password was incorrect" (as expected). > > If a local (i.e., admin) user authenticates, everything 'works' properly. > > I don't *think* this is an issue with the ldap/AD config as ldapsearch > with the same inputs returns all the expected users and the same > settings (different bind account) are in use elsewhere in our > infrastructure. > > Nothing showing in the apache logs, but there is a Fatal error in the > php log: > > [11-Dec-2020 17:45:36 Australia/Perth] PHP Warning: ?Attempt to read > property "value" on null in > /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.cache.php > on line 424 > > [11-Dec-2020 17:45:42 Australia/Perth] PHP Fatal error: ?Uncaught > TypeError: Cannot access offset of type string on string in > /opt/zendto/lib/NSSADAuthenticator.php:658 > > Stack trace: > > #0 /opt/zendto/lib/NSSADAuthenticator.php(485): > NSSADAuthenticator->Tryauthenticate() > > #1 /opt/zendto/lib/NSSMultiAuthenticator.php(154): > NSSADAuthenticator->authenticate() > > #2 /opt/zendto/lib/NSSDropbox.php(2332): > NSSMultiAuthenticator->authenticate() > > #3 /opt/zendto/lib/NSSDropbox.php(620): > NSSDropbox->userFromAuthentication() > > #4 /opt/zendto/www/index.php(35): NSSDropbox->__construct() > > #5 {main} > > ? thrown in /opt/zendto/lib/NSSADAuthenticator.php on line 658 > > Any ideas on what could be causing this behaviour? > > Thank you > > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jules at Zend.To Mon Dec 14 09:58:41 2020 From: Jules at Zend.To (Jules) Date: Mon, 14 Dec 2020 09:58:41 +0000 Subject: [ZendTo] 500 server error on successful AD authentication In-Reply-To: References: Message-ID: Bailey, Bother, thumped Send by mistake. Bar a bit of formatting, that actually does contain the change I want you to try making. BTW Why are you using the "Multi" authenticator? Can't you just do it all with AD? It's simpler to administer (in years time, after you've left the organisation) if all the users come from the same place. Cheers, Jules. On Mon 14/12/20 09:56, Julian Field via ZendTo wrote: > Bailey, > > Interesting one, slightly surprised that (a) it causes an error in > your case, and that (b) in that case, no one has seen it before. > > Edit /opt/zendto/lib/NSSADAuthenticator.php and change line 658 > from > ??????????????? if ( @$value['count'] >= 1 ) { > to > ??????????????? if ( is_array($value) && @$value['count'] >= 1 ) { > > > > On Fri 11/12/20 23:47, Bailey Coole via ZendTo wrote: >> >> We're running 6.05-4 on CentOS 8. >> >> If an AD user successfully authenticates, they get a 500-server error. >> >> If an AD user inputs an incorrect password, they are warned that "The >> username or password was incorrect" (as expected). >> >> If a local (i.e., admin) user authenticates, everything 'works' >> properly. >> >> I don't *think* this is an issue with the ldap/AD config as >> ldapsearch with the same inputs returns all the expected users and >> the same settings (different bind account) are in use elsewhere in >> our infrastructure. >> >> Nothing showing in the apache logs, but there is a Fatal error in the >> php log: >> >> [11-Dec-2020 17:45:36 Australia/Perth] PHP Warning: ?Attempt to read >> property "value" on null in >> /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.cache.php >> on line 424 >> >> [11-Dec-2020 17:45:42 Australia/Perth] PHP Fatal error: ?Uncaught >> TypeError: Cannot access offset of type string on string in >> /opt/zendto/lib/NSSADAuthenticator.php:658 >> >> Stack trace: >> >> #0 /opt/zendto/lib/NSSADAuthenticator.php(485): >> NSSADAuthenticator->Tryauthenticate() >> >> #1 /opt/zendto/lib/NSSMultiAuthenticator.php(154): >> NSSADAuthenticator->authenticate() >> >> #2 /opt/zendto/lib/NSSDropbox.php(2332): >> NSSMultiAuthenticator->authenticate() >> >> #3 /opt/zendto/lib/NSSDropbox.php(620): >> NSSDropbox->userFromAuthentication() >> >> #4 /opt/zendto/www/index.php(35): NSSDropbox->__construct() >> >> #5 {main} >> >> ? thrown in /opt/zendto/lib/NSSADAuthenticator.php on line 658 >> >> Any ideas on what could be causing this behaviour? >> >> Thank you >> >> >> _______________________________________________ >> ZendTo mailing list >> ZendTo at zend.to >> http://jul.es/mailman/listinfo/zendto > > 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 > > _______________________________________________ > ZendTo mailing list > ZendTo at zend.to > http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Think globally, act locally.' - Friends of the Earth www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bailey.Coole at outlook.com Mon Dec 14 13:09:38 2020 From: Bailey.Coole at outlook.com (Bailey Coole) Date: Mon, 14 Dec 2020 13:09:38 +0000 Subject: [ZendTo] 500 server error on successful AD authentication In-Reply-To: References: Message-ID: Hi Thank you, that fixed it. I was using multi to test if it was failing on any auth or just failing on just AD auth. I was surprised aswell, seems like that kind of thing that would be more widespread/reported by now indeed. I did find the settings to get the AD connections working at all to be somewhat different from those documented in the preference file/we weren?t forced to ldaps: ?authLDAPServers1? => array (??). ?authLDAPUseSSL1? = > false ?authLDAPUseTLS1? => false ?authLDAPBindUser1? => ? ? ?authLDAPUsernameAttribute1? => ?sAMAccountName? The domain controller is running windows server 2019. Maybe some part of that config just doesn?t ?play nicely?? Yes, I know we should get the certs/tls playing nicely, but we were having issues with them and we needed to have a working demo together. Cheers for the fix, and Merry Christmas (or your regional /personal equivalent). Kind regards Bailey From: Jules Sent: 14 December 2020 17:59 To: ZendTo Users Cc: Bailey Coole Subject: Re: [ZendTo] 500 server error on successful AD authentication Bailey, Bother, thumped Send by mistake. Bar a bit of formatting, that actually does contain the change I want you to try making. BTW Why are you using the "Multi" authenticator? Can't you just do it all with AD? It's simpler to administer (in years time, after you've left the organisation) if all the users come from the same place. Cheers, Jules. On Mon 14/12/20 09:56, Julian Field via ZendTo wrote: Bailey, Interesting one, slightly surprised that (a) it causes an error in your case, and that (b) in that case, no one has seen it before. Edit /opt/zendto/lib/NSSADAuthenticator.php and change line 658 from if ( @$value['count'] >= 1 ) { to if ( is_array($value) && @$value['count'] >= 1 ) { On Fri 11/12/20 23:47, Bailey Coole via ZendTo wrote: We're running 6.05-4 on CentOS 8. If an AD user successfully authenticates, they get a 500-server error. If an AD user inputs an incorrect password, they are warned that "The username or password was incorrect" (as expected). If a local (i.e., admin) user authenticates, everything 'works' properly. I don't *think* this is an issue with the ldap/AD config as ldapsearch with the same inputs returns all the expected users and the same settings (different bind account) are in use elsewhere in our infrastructure. Nothing showing in the apache logs, but there is a Fatal error in the php log: [11-Dec-2020 17:45:36 Australia/Perth] PHP Warning: Attempt to read property "value" on null in /var/zendto/templates_c/9da848d4b67ceaa147b62c8524dedce691bc7ce2_0.file.header.tpl.cache.php on line 424 [11-Dec-2020 17:45:42 Australia/Perth] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /opt/zendto/lib/NSSADAuthenticator.php:658 Stack trace: #0 /opt/zendto/lib/NSSADAuthenticator.php(485): NSSADAuthenticator->Tryauthenticate() #1 /opt/zendto/lib/NSSMultiAuthenticator.php(154): NSSADAuthenticator->authenticate() #2 /opt/zendto/lib/NSSDropbox.php(2332): NSSMultiAuthenticator->authenticate() #3 /opt/zendto/lib/NSSDropbox.php(620): NSSDropbox->userFromAuthentication() #4 /opt/zendto/www/index.php(35): NSSDropbox->__construct() #5 {main} thrown in /opt/zendto/lib/NSSADAuthenticator.php on line 658 Any ideas on what could be causing this behaviour? Thank you _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto 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 _______________________________________________ ZendTo mailing list ZendTo at zend.to http://jul.es/mailman/listinfo/zendto Jules -- Julian Field MEng CEng CITP MBCS MIEEE MACM 'Think globally, act locally.' - Friends of the Earth www.Zend.To Twitter: @JulesFM -------------- next part -------------- An HTML attachment was scrubbed... URL: