DirectAdmin v1.656

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,157
Hi everyone!

We are happy to announce the release of DirectAdmin 1.656.

Main focus of this release is to provide a way for old servers to clean up no longer used libraries in /usr/local.

Full release change log can be found here:

DirectAdmin 1.656​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
I think maybe the documentation for SFTP support in ProFTPd needs to be updated: https://docs.directadmin.com/other-...ral.html#how-to-install-mod-sftp-into-proftpd

There used to be a reference to https://files.directadmin.com/services/all/sftp/configure.proftpd.sftp in the documentation I think, but it's no longer mentioned, and that file looks quite different from the (new) default one in configure/proftpd/configure.proftpd.

I see the new file is using extra_modules to define the mod_clamav support, perhaps it can be extended to also support the mod_sftp module?
 
Last edited:
Nice release:)

@fln typo

local package 'libsrs_alt' is removed, it can be resoted with command:
da build restore_old_local libsrs_alt
 
Last edited:
  • Like
Reactions: fln
Hi,
On three servers I can't upgrade Exim to 4.97


Code: 
rfc2047.o: In function `rfc2047_decode2':
rfc2047.c:(.text+0x49f): undefined reference to `libiconv_open'
rfc2047.c:(.text+0x543): undefined reference to `libiconv'
rfc2047.c:(.text+0x5f2): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
make[1]: *** [exim] Error 1
make[1]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.qExf4S7Bkq.exim-4.97.tar.gz/build-Linux-x86_64'
make: *** [all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.qExf4S7Bkq.exim-4.97.tar.gz'
failed to compile exim 4.97

Every of them is CentOS 7.
 
I have the same problem
make[2]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.iU437UGOP9.exim-4.97.tar.gz/build-Linux-x86_64/routers'

cc lookups/lf_quote.c
cc lookups/lf_check_file.c
cc lookups/lf_sqlperform.c
cc local_scan.c
cc -o exim
rfc2047.o: In function `rfc2047_decode2':
rfc2047.c:(.text+0x49f): undefined reference to `libiconv_open'
rfc2047.c:(.text+0x543): undefined reference to `libiconv'
rfc2047.c:(.text+0x5f2): undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status
make[1]: *** [exim] Error 1
make[1]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.iU437UGOP9.exim-4.97.tar.gz/build-Linux-x86_64'
make: *** [all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.iU437UGOP9.exim-4.97.tar.gz'
failed to compile exim 4.97
 
I was made aware of this possible bug in the Evolution skin by a customer:

When you as an admin use "login as <user>", you get a black bar at the top with a dropdown/search box to change the user you're logged in as. This dropdown now have some MASSIVE icons, and I can't get the search functionality to work either. This was reported to me today, so I suspect it's related to the 1.656 release.
 
I can confirm that the big icons are introduced with 1.656.

The black user search bar doesn't work correctly since a previous version. I've seen someone mention it before, but probably it was missed. When you switch to a different user, you keep seeing the previous user. It does seem to work (switch) the second time, but this is not how it's supposed to be of course.
 
fln said:
@remsnel, @ShinJii please make sure you do not have old libraries in /usr/local getting in the way. Output of da build list_removals should not hint about old libraries being installed.

There is separate thread about cleaning up old libraries, more details on how to remove old libraries - https://forum.directadmin.com/threads/directadmin-v1-656-rc.69439/#post-367775
Click to expand...

Ok, I deleted all libraries in "removes" and then while update all (because of iconv) I have an error in php 7.2 lol because library were removed xD

Code: 
checking for PCRE headers location... configure: error: Could not find pcre.h in /usr/local

*** There was an error while trying to configure php. Check the configure file
 
Standard PHP compile script does not try to find any libraries in /usr/local (well except imagemagic for the time being) please check if you have any PHP compilation customization that forces PHP to search the /usr/local dir.
 
fln said:
Standard PHP compile script does not try to find any libraries in /usr/local (well except imagemagic for the time being) please check if you have any PHP compilation customization that forces PHP to search the /usr/local dir.
Click to expand...
How to find that?
 
I had the same issue some time ago and then I did the following:
Code: 
./build update
./build clean
./build php n
and then PHP compiled against the correct libraries. Maybe this works for you too.
 
If possible, may DA add a (Y/N) confirmation dialog before "da build remove_items" in custombuild cli.
I, by mistake (copy & paste wrong command in putty), deleted a number of items.

(Hopefully I have KVM snapshot in my testing site)
 
After removing all old libraries - got this (debian 10):

php-fpm74[25079]: /usr/local/php74/sbin/php-fpm74: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory

How to get it to work?
 
Removal of old libraries needs to be performed manually, because it can really depend on how much local system is customized, but here is the general guidelines how to perform old libs removal minimizing the service downtime:

  1. Run da build list_removals to get a list of legacy libraries detected on the system. This would be useful if libraries removal causes problems and we would like to restore old libraries.
  2. Run da build remove_items to remove most of the old libraries (except iconv) form the system. Existing software linked against old libraries should automatically start using system libraries instead.
  3. Create a backup of iconv library with commands da build remove_old_local libiconv and da build restore_old_local libiconv, backup is automatically created before removing library and we restore it immediately to avoid affecting the system.
  4. Run rm -f /usr/local/include/{iconv.h,libcharset.h,localcharset.h} command to partially remove iconv. This removes header files and ensures new software will not detect old iconv presence, but the real library in /usr/local/lib/libiconv.so is still present for software that still uses it.
  5. Rebuild the software that was using old iconv one by one da build php, da build exim, da build dovecot or just perform full rebuild using da build all.
  6. Optional, remove iconv fully with da build remove_old_local libiconv. Any software still linked against iconv will stop working but if everything is rebuild there should be no such software components.
At any point if some software component stops working old libraries can be returned back with da build restore_old_local {name}.

The goal of the above steps is to minimize service downtime. It is built around two ideas:
  • Removing all (except iconv) libraries does not require software to be recompiled when compatible system libraries exist. Linker just start using library substitute from /usr/lib.
  • Removing only iconv headers allows us to continue using software that is linked against iconv but ensure freshly built software will not get linked with old iconv.
If some downtime can be accepted then simple solution would be da build remove_items, then da build remove_old_local libiconv and finally da build all.

Feedback if the following approach helped would be really appreciated.
 
kristian said:
I was made aware of this possible bug in the Evolution skin by a customer:

When you as an admin use "login as <user>", you get a black bar at the top with a dropdown/search box to change the user you're logged in as. This dropdown now have some MASSIVE icons, and I can't get the search functionality to work either. This was reported to me today, so I suspect it's related to the 1.656 release.
Click to expand...
Yes same here, bad UX design ;) :P Can this be fixed or can we fix this somewhere ourselves?
 
You must log in or register to reply here.
Back
Top