CentOS 5 client compatibility

Hi,
I’m using urbackup 2.4.12 server with some centos 7 clients (version 2.4.10) and all works well. Now I have some centos 5 client, and I’d like to know if version 1.4.11 is compatible with version 2.4.12 of the server.
I did some tests:

  • From CentOS 5 I compiled version 1.4.11 with
    ./configure --enable-headless --disable-fortify; make; make install
    and it works.
    In a test environment I tried to setup a folder to backup from the server (/root/test) and it works.
    When I try to do the same in my production environment it doesn’t work. More precisely, when I start the client in debug mode I have an error:
    2020-01-16 17:57:23: FileSrv: Sending file (normal) urbackup/filelist.ub
    2020-01-16 17:57:23: FileSrv: Mapped name: /root/urbackup/filelist.ub

and clearly the path is wrong! (/root/urbackup/filelist.ub). In the test environment I have a different path:
2020-01-16 17:51:17: FileSrv: Sending file (normal) urbackup/filelist.ub
2020-01-16 17:51:17: FileSrv: Mapped name: /usr/local/var/urbackup/data/filelist.ub

Why in prod env I have a different one? how can I force the client to use the right path?
Thank you

I guess it uses the working directory? So you’d have to run it from /usr/local/var or /var

Does the Linux binary client not work? https://www.urbackup.org/download.html#linux_all_binary

Ops… I’m sorry, it works!
Just one question: Using the binary client you suggested, I have the file /usr/local/var/urbackup/data/settings.cfg a bit different. It starts with:
#Initial Settings. Changes will not be respected
#<long_serial_number>
Am I missing something? I need to configure internet_mode and specify internet server and port. Should I modify this file manually? What’s the best practice?
Thank you

See the manual for easiest installation of the client (2.2 Client installation https://www.urbackup.org/administration_manual.html#x1-110002.2 ). TLDR: Create the client on the server, then it’ll show download links to pre-configured client binaries.

I installed the client using the binary provided by my server. Anyway the client doesn’t connect to the server and when I try to launch it in debug mode I see:
/usr/local/sbin/urbackupclientbackend --loglevel debug -i
2020-01-17 09:33:13: SQLite: recovered 24 frames from WAL file /usr/local/var/urbackup/backup_client.db-wal code: 283
2020-01-17 09:33:13: ERROR: urbackupserver: Creating SOCKET failed
2020-01-17 09:33:13: Started UrBackupClient Backend…
2020-01-17 09:33:13: FileSrv: Server started up successfully
2020-01-17 09:33:14: Trying to connect to internet server “xxx.mydomain.org” at port 55415
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Connecting failed.
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Trying to connect to internet server “xxx.mydomain.org” at port 55415
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions
2020-01-17 09:33:14: Looking for old Sessions… 0 sessions

Using tcpdump I don’t see any packet from the server side. Furthermore, checking the file /usr/local/var/urbackup/data/settings.cfg it seems to be ok:

#Initial Settings. Changes will not be respected.
#48692563-17e4-4ccb-a078-f14372fdbe20^M
internet_mode_enabled=true^M
internet_server=xxx.mydomain.org^M
internet_server_port=55415^M
internet_server_proxy=^M
internet_authkey=ffpbEW4pJ0^M
computername=dns2^M
########################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
#6e7f6ba0-8478-4946-b70a-f1c7e83d28cc
Can you give me some hint in order to solve the issue?

Please note I obscured server name.
Thank you,
Marco

The question is if it has compatibility problems with your probably quite old Linux kernel. What’s the Linux kernel version? Does it support SOCK_CLOEXEC ?

Client:
uname -a
Linux ns2radius2.xxxxxx.xx 2.6.18-371.9.1.el5 #1 SMP Tue Jun 10 17:51:26 EDT 2014 i686 i686 i386 GNU/Linux

Server:
uname -a
Linux xxxx.xxxx.xx 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

It seems that kernel 2.6.18 doesn’t support SOCK_CLOEXEC. Is there some other solution in order to backup old centos 5 clients?

Could you try this one? https://beta.urbackup.org/tmp/UrBackupUpdateLinux-dbg.sh

Using this version I do not understand how to setup server params. If I launch the service with -i I have:
[root@centos-5 urbackup-bin]# /usr/local/sbin/urbackupclientbackend -i
2020-01-17 16:06:27: SQLite: recovered 24 frames from WAL file /usr/local/var/urbackup/backup_client.db-wal code: 283
2020-01-17 16:06:27: ERROR: urbackupserver: Creating SOCKET failed
2020-01-17 16:06:27: Started UrBackupClient Backend…
2020-01-17 16:06:27: ERROR: Internet mode not enabled. Please set “internet_mode_enabled” to “true”.
[root@centos-5 urbackup-bin]#

So I try to use urbackupclientctl but I have an error:
urbackupclientctl set-settings -k internet_mode_enabled -v true -k internet_server -v xxxx.mydomain.org -k internet_server_port -v 55415 -k computername -v “testclient1” -k internet_authkey -v 5XL3EA9N2j
Error creating socket for connection to backend
Error setting settings.
[root@centos-5 urbackup-bin]#

How can I set my internet server params?
Thank you

Could you run e.g. that urbackupclientctl set-settings in strace:

strace -f urbackupclientctl set-settings ...

Edit: Never mind… will upload a new version. Needs at least 1h to compile…

Thank you for your support. strace here:
https://paste.centos.org/view/61eceab3

Sorry, I forgot -f in strace. Here new results:
https://paste.centos.org/view/9e94ac5f
Anyway the problem seems related to time.h:
clock_gettime(0x6 /* CLOCK_??? /, 0xbfd174d0) = -1 EINVAL (Invalid argument)
clock_gettime(0x6 /
CLOCK_??? /, 0xbfd174d0) = -1 EINVAL (Invalid argument)
clock_gettime(0x6 /
CLOCK_??? */, 0xbfd17510) = -1 EINVAL (Invalid argument)

Thank you

Can you try this one? https://beta.urbackup.org/tmp/UrBackupUpdateLinux-dbg-2.sh

Unfortunately the utility urbackupclientctl hangs without any apparent reason.
Anyway, now I can start the service without errors and I checked with this:
netstat -tulnp | grep -i urb
tcp 0 0 0.0.0.0:35621 0.0.0.0:* LISTEN 14296/urbackupclien
tcp 0 0 0.0.0.0:35623 0.0.0.0:* LISTEN 14296/urbackupclien
udp 0 0 0.0.0.0:35622 0.0.0.0:* 14296/urbackupclien
[root@ns2radius2 urbackup-bin]#

in /var/log/urbackupclient.log I have this:
2020-01-19 21:00:58: ERROR: urbackupserver: Creating v6 SOCKET failed
2020-01-19 21:00:59: ERROR: FileSrv: Failed setting SO_REUSEADDR in CUDPThread::CUDPThread
2020-01-19 21:00:59: ERROR: Binding ipv6 UDP socket to port 35622 failed

Next I try to change settings with urbackupclientctl but it hangs. Here you can see detailed logs with strace:
https://pastebin.com/vGcWiQFY

Thank you

Can you post a backend debug log + perhaps a strace of the backend process?

Hi,
logs are really long. Can I send you through private email?

I noticed that on a centos7 working machine, port 35623 is binded to 127.0.0.1 and not 0.0.0.0
When I do strace for urbackupclientctl I see that it tries to connect to 127.0.0.1:35623 and wait for a response indefinitely. Do you think that this can be the problem?

See Having problems with UrBackup? Please read before posting w.r.t. logs. Attaching them here should work as well.

urbackupclientctl_strace.log (8.6 KB) urbackupclient.log (767.8 KB)
Here are my logs. Please note that I have an strace of urbackupclient but it is 86M. Please let me know if you need it.
Anyway, I noticed that:

  1. urbackupclient now is really cpu intensive (400%) without do nothing
  2. urbackupclientctl doesn’t send any packet to the client (I don’t see any network traffic, nor on the local loopback interface)

Thank you