Re: [Veritas-bu] DR report email after successful catalog backup is not being generated [ Netbackup 6.5.6 on Solaris 10 ]

2011-05-08 Thread Saran Brar
DR file also get saved a path which is mentioned in the catalog policy. Did
you checked that file path if DR files are getting saved there.

On Fri, May 6, 2011 at 9:20 PM, Bhangui, Sandeep - BLS CTR 
bhangui.sand...@bls.gov wrote:

 Yes to both.those two items have been checked and are correct.

 Thanks
 Sandeep

 -Original Message-
 From: Mark Glazerman [mailto:mark.glazer...@spartech.com]
 Sent: Friday, May 06, 2011 9:14 AM
 To: Bhangui, Sandeep - BLS CTR; veritas-bu@mailman.eng.auburn.edu
 Subject: RE: [Veritas-bu] DR report email after successful catalog backup
 is not being generated [ Netbackup 6.5.6 on Solaris 10 ]

 Starting from the basics, have you checked that in the catalog policy
 (under Disaster Recovery), you have the correct email address(es) specified
 and that you have checked the box stating you want send the DR file in an
 email attachment to those email addresses ?

 Mark Glazerman
 Desk: 314-889-8282
 Cell: 618-520-3401
 P please don't print this e-mail unless you really need to

 -Original Message-
 From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:
 veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Bhangui, Sandeep -
 BLS CTR
 Sent: Friday, May 06, 2011 6:48 AM
 To: veritas-bu@mailman.eng.auburn.edu
 Subject: [Veritas-bu] DR report email after successful catalog backup is
 not being generated [ Netbackup 6.5.6 on Solaris 10 ]

 Hi
Solaris 10 Master/Media server.running Netbackup Ver
 6.5.6.it seems everything functionality wise is working fine but the DR
 report which is send via email once you do a catalog backup is not being
 send via email to the address defined in the catalog backup policy.

 The catalog backup is being done successfully.

 Mail is working fine on the box as I do receive emails once a backup is
 completed or if it fails...with the status codes

 Can someone please let me know what can I check to troubleshoot this
 issue

 Thanks in advance.

 Sandeep

 ___
 Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
 http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
 ___
 Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
 http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf?-RESOLVED (yes actually resolved this time)

2011-05-08 Thread Marianne Van Den Berg
Hi Jeff

If you don't mind - please set the record straight on the Symantec Ideas page?

https://www-secure.symantec.com/connect/ideas/bug-report-netbackup-name-resolution-hp-ux

Regards

M.

-Original Message-
From: veritas-bu-boun...@mailman.eng.auburn.edu 
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Lightner, Jeff
Sent: 03 May 2011 07:29 PM
To: Girish Jorapurkar
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf?-RESOLVED 
(yes actually resolved this time)

The patch (PHCO_30030) has been superseded more than once and we have one of 
the superseding patches PHCO_37369 so would already have the bug fix the 
poster at the link mentioned.

However, I'd like to thank you as your pointer helped me resolve the issue:
1)  By downloading and compiling his source code I was able to see that I did 
have the same issue with his binary as that poster did.   (That is to say this 
binary like the NetBackup binaries did not resolve from /etc/hosts first but 
rather from DNS.)
2)  On reviewing the /var/adm/sw/products/PHCO_37369/pfiles/README file that 
came with the later patch I saw the following (which is from another patch this 
one supersedes so is incorporated):
PHCO_29287:
( QX:QXCR1000523428 SR:8606308071 CR:JAGae71107 )
If IPv6 is enabled on a system, the Internet Services
commands use the APIs getipnodeXX() or get*info() to
resolve the name instead of the APIs gethostbyXX().
The APIs getipnodeXX() and get*info() look into the
ipnodes directive of the /etc/nsswitch.conf to resolve
the name/address.  As the NIS/NIS+ backends do not
respond to the ipnodes directive, the resolution of
IPv4 addresses fails for NIS and NIS+ sources.

While we aren't doing anything with NIS/NIS+ the other info about IPv6 was 
informative.  Turns out that in addition to the standard hosts: line in 
/etc/nsswitch.conf HP-UX is expecting an ipnodes: line for binaries that use 
the above APIs.

After modifying /etc/nsswtich.conf so it now has both the following lines:
hosts: files [notfound=CONTINUE] dns
ipnodes: files [notfound=CONTINUE] dns

The new binary resolved correctly from /etc/hosts and on testing so did 
bpclntcmd.   Based on that I restarted the backup that had been going across 
the primary LAN previously and it is currently running on the expected backup 
LAN.

Presumably this means the 7.1 NetBackup binaries are using the above referenced 
APIs on HP-UX where the 6.5.4 binaries didn't.

We never saw this issue on HP-UX up through version 6.5.4 and in testing 
yesterday I'd copied the 6.5.4 binary and its associated libraries to another 
directory on my HP-UX host and it resolved from /etc/hosts.

I added the ipnodes entry to /etc/nsswitch.conf on the other HP-UX 11.11 media 
server and the HP-UX 11.23 client I'd recreated the error on previously.   On 
adding the line both hosts correctly resolved the backup LAN IP from /etc/hosts 
instead of going to DNS.

FYI:  ITRC is going away so I'm not sure if the link will still be accessible 
in the future.   Accordingly I'm including the source code that poster had made 
so it is available from this forum.

His source code file was called:  114249.c and I compiled it by running:
cc -o testresolver 114249.c.   Usage is simply testresolver hostname.   
The source code is as follows:

/* Test program to test IP resolution for domain names
 */


#include stdio.h
#include sys/types.h
#include sys/socket.h
#include arpa/inet.h
#include netdb.h
#include string.h


/* Function to get IP address for hostname
 ** hostname - (i/p) - Hostname to find IP address
 ** buffer   - (o/p) - Buffer filled with IP address
 ** buffer_len - (i/p) - Length of buffer
 ** Return APR_SUCCESS on success
 **/
int get_ip_from_hostname(char *hostname)
{
int status = 0;
struct addrinfo hints, *ai, *ai_list;
char host_ip[INET_ADDRSTRLEN];
const char *ret = NULL;

memset(hints, 0, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
status = getaddrinfo(hostname, NULL, hints, ai_list);
if (status)
{
printf(Failed to resolve IP address for %s \n , hostname);
printf(Error: %s \n, gai_strerror(status));
return status;
}

ai = ai_list;
if(ai)
{
struct sockaddr_in *in = (struct sockaddr_in *)ai-ai_addr;
host_ip[0] = '\0';
ret = inet_ntop(AF_INET, in-sin_addr, host_ip, sizeof(host_ip));
}
freeaddrinfo(ai_list);

if(host_ip)
{
printf(Hostname \%s\ resolves to IP \%s\ \n, hostname, host_ip);
status = 0;
}
else
{
printf(Failed to resolve IP address for %s \n, hostname);
status = -1;
}

return status;
}

void usage()
{

printf(resolve_hostname hostname \n);

return;
}

int main(int argc, char *argv[])
{

char hostname[1024];

if(argc2)
{

[Veritas-bu] Encryption key store

2011-05-08 Thread Harry Tirrell
I ammigrating from solaris to enterprise linux.  How do I mave the
encryption key store?

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


[Veritas-bu] Encryption Key Store

2011-05-08 Thread Harry Tirrell
I am migrating from solaris to enterprise linux on 7.0.1.  What is the best
way to migrate the key store?

 

Harry

ha...@tirrell.org

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


[Veritas-bu] DR report email after successful catalog backup is not being

2011-05-08 Thread rmg
When this happened to me, it was because of a buffer size limitation in 
NetBackup. The bug is described here:

http://www.symantec.com/business/support/index?page=contentid=TECH68219

I took the recommended step of removing some policies from the critical 
policies list to make this report smaller, and it started working again.

+--
|This was sent by r...@ua.edu via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu