Search results

I'm also nog sure why you should/can select a language, as this is not propagated to the next screens and only works one time for the login screen. If I logoff it has changed back to english again. At least keep the choice in a cookie or whatever.

I think solutions differ if you have one server or a lot of servers. We have more than one person's ip whitelisted so if one ip changes, the other can update the edge firewalls :)

I said 'you don't have to' because you don't have to close the ssh port in the first place. Besides that I would recommend another port to run ssh on. This 'obscurity' isn't security of course but it's will make you logfiles a lot smaller so it's easier to track real problems.

Haha true, but with ssh keys or port knocking, you don't have to whitelist your ip-address. username/passwords attacks are never going to work. But you can't avoid brute force attacks, you can only make them less likely or impossible to succeed.

SSH Portknocking or ssh keys only.

I hate to tell you, but hosters who sell 'infinite/unlimited' things are selling you BS. There is no such thing als unlimited/infinite things in the hostingworld. As you have learner today. Contact them.

Shutdown your server or disconnect the network cable or only use private internet addresses. Everything else with a publicly routable internet address will get BF attacks. Deal with it by using very strong passwords and indeed a tool like csf.

Oh, I don't know about that. I presumed it was a DA patch, it wasn't. It also wasn't in the online sourcecode. But the tar.gz has a date of 14 apr. And the source file is changed only 12 days ago. So it just looks like a bug in the current tar.gz where the (void)in is replaced with void(blob)...

Why wouldn't it be correct? It's basic c...

Hmm, i looked in this file: https://github.com/curl/curl/blob/master/lib/vtls/openssl.c It's not there so i presumed it was the result of a patch. My bad!

Because it's not in the original curl sourcecode but is in the source from the da-servers. Seemed obvious to me?

Well, I think this is just a bug in the patch DA made. It's not in the original curl source code.

No problem, but the variable isn't defined anywhere so it's save to delete it and enjoy all the glorious bugfixes :):):):):)

A quick fix is to cd /usr/local/directadmin/custombuild/ # untarzip the curl package tar -zxvf curl-7.76.1.tar.gz #change to the directory where the error occurs cd curl-7.76.1/lib/vtls/ # edit the file and remove the unused/unreference variable "(void)in" line at line 734 sed -i '734d'...

Me too, centos 6.

After an 'ldconfig /usr/local/lib64' it seems to work again. Might be a symbolic link that is forgotten in the install. ln -s /usr/local/lib64/libzip.so.5.3 /usr/lib64/libzip.so.5 fixes it in my case. Extra: In CentOS 6 i had to remove the libjpeg.so.62 versions, manually extract the...

Yups, tried on 3 different servers, only happens with the 7.3 php version. # /usr/local/php73/bin/php -i|grep imagick PHP Warning: PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /usr/local/php73/lib/php/extensions/no-debug-non-zts-20180731/imagick.so (libzip.so.5: cannot open...

I already tried that. It seems to only fail with php 7.3. It works on 7.4 of 8.0. # php -v PHP Warning: PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /usr/local/php73/lib/php/extensions/no-debug-non-zts-20180731/imagick.so (libzip.so.5: cannot open shared object file: No...

FYI: Rebuilding PHP or reinstalling libzip does not fix it so I restored the backup of the previous imagick.so to fix it.

Anybody having issues with the latest imagick update? Compiles without problems, but results in a: PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /usr/local/php73/lib/php/extensions/no-debug-non-zts-20180731/imagick.so (libzip.so.5: cannot open shared object file: No such...