Unable to connect to Linux client from Windows server

[Jan_Mattila]

I'm running BackupExec 10.1 rev 5629 on a Windows XP SP2 (and latest updates) server. My client is a Linux machine running kernel 2.6.9-34 and RALUS version 5629 (according to ralus.ver) installed from the package Q180968.BE.RALUS.10.1.5629.3.ESD.tar.gz.

I am able to connect to the Linux client by creating a "User-defined Selections" entry. This allows me to browse the contents of the Linux client. The connection to the host as well as the username and password thus work. The beremote is listening in port 10000, there is nothing else running on the server in port 10000, the login account is root, there is a beoper group, everything should be fine.

However, after selecting anything from the client and running a test run, I get this error:

Credentials Check
Device : \\10.0.0.3, \\10.0.0.3\
Check status : Error: e000846b, The job failed with the following error: The resource could not be backed up because an error occurred while connecting to the Backup Exec for Windows Servers Remote Agent.
Make sure that the Remote Agent is installed on the target computer and is running.

I have read support articles 240971, 253058 and 258982, which contain the error code, but they were of absolutely no use. Changing any of the Options settings has no effect.
(If this was an installation problem, why is it possible to browse the contents of the Linux client.)

I have changed firewall settings both in BackupExec as well as a software firewall running on the server. I've even tried the test run with the third-party software firewall off completely, this had no effect. This is not a third-party firewall problem.

What's up? How can I make BE spill out more info? There is nothing (no lines of text) in beremote.service.log on the Linux client, even with debug level set to 1 in ralus.cfg on the Linux client.

I can post you the contents of a tcpdump of the traffic between the two hosts, if you think that will be helpful.

[Jan_Mattila]

The default startup script attempts to write its log by using I/O redirect, with no parameters passed to beremote. This results in exactly nothing being printed to the log file, as beremote is not started with the necessary "--log-file filename" switch.

To fix this, change the startup script to start the beremote up with the logging switch and a filename like this:

/path/to/beremote --log-file /path/to/beremote.logfile &

Now we have logs. Still no answer to why the backup fails.

BTW, beremote on the Linux host claims to be a "Remote agent for NT 5.1".

[Jan_Mattila]

Who made this software? Who is responsible for coding the link between BE and ralus?

There is apparently a HARDCODED MAXIMUM LENGTH for the results of the uname check:

ERROR: ndmpdConfigGetHostInfo: uname error: File name too long.

At that moment, my 'uname -a' was 117 characters long. After this, I dropped my domain from my HOSTNAME setting and ended up with a 95 character 'uname -a'.

I don't know (and don't care) which parameters are passed to uname. If it is -a, then it appears that there is a maximum size of somewhere between 117 and 95 characters, that breaks the agent's ability to do anything useful.

For some reason this is not an issue when building the selection list, but becomes a single point of failure, when running a test run or trying to back anything up.

And _naturally_ the error message in BE says jack useful about this.

The debugging of this is a complete pain. Not only is your default init script unable to create the logfiles in the first place, once you fix that by passing the --log-file filename parameter to beremote it will not STOP logging even after you set the Software\VERITAS\Backup Exec\Engine\Logging\RANT NDMP Debug Level=0
and restart the service.

I'm expecting you to respond to this and state when there will be a patch available that fixes both the init script, the logging non-functionality and the hardcoded maximum length of uname output.

[Ajit_Kulkarni]

Hello Jan,


What is the version of Linux you are using ?

Have you added the IP Address and Name of Backup Exec server in Hosts file on Linux server and vice versa ? If not then please do so.

You have mentioned that the test run is failing, but have you tried running actual backup job ? If not then please do so and check the results.

Kindly update.


Regards


NOTE : If we do not receive your reply within two business days, this post would be marked "assumed answered" and would be moved to "answered questions" pool.

[Jan_Mattila]

> What is the version of Linux you are using ?

The version of my Linux is 2.6.9-34.

> Have you added the IP Address and Name of Backup Exec
> server in Hosts file on Linux server and vice versa ?

Do you know what a Hosts file is used for? Do you know what uname does? Do you know how the beremote daemon works?

What does the "IP Address and Name of Backup Exec server in Hosts file" have to do with the failing uname check, the dysfunctional startup script or the broken debug switch?

And why would you even need to have anything in the Hosts file of the Windows server? The User-defined Selections have been created with an IP address and not a hostname or anything requiring name resolution, a fact which I've demonstrated in the opening post of this thread (this part: Device : \\10.0.0.3, \\10.0.0.3\ )? Everything the Hosts file could be used for is ALREADY GIVEN to the BackupExec running on the Windows server.

Besides, it's not failing a lookup, as I mentioned in the opening post of this thread (this part: I am able to connect to the Linux client by creating a "User-defined Selections" entry.), so this can not even be the root of the problem.

> You have mentioned that the test run is failing, but
> have you tried running actual backup job ?

What would be the point of having a test run feature, if the test run might randomly fail, while a backup run might randomly succeed? What could you possibly test by the test run? Do you already know, that the quality of the product you are supporting is so miserably low, that this seems like a viable suggestion, or are you just making stuff up, hoping that the thread will go unnoticed until the 48 hour time limit runs out?


Replying to your answer has been a complete waste of my time. You have provided no useful information whatsoever, no insight into the workings of the broken Linux client and no information about a patch or update or anything of the sort to fix the problems detailed in my earlier posts to this thread.

I consider this thread still not answered and am awaiting an answer from a person with a more thorough understading of the workings of their own product.

[priya_khire]

Hello Jan,

You could decrease the size of the linux server hostname to something smaller than 30 characters.

You can also subscribe to our enhancement site to suggest enhancements in this product:

Welcome to the Symantec Product Enhancement Program
http://enhancement.veritas.com/

You may also subscribe to our Email Notification Service for latest updates and new releases:


Note : If we do not receive your reply within two business days, this post would be marked �assumed answered� and would be moved to �answered questions� pool.

Regards.