Mabuhay

Hello world! This is it. I've always wanted to blog. I don't want no fame but just to let myself heard. No! Just to express myself. So, I don't really care if someone believes in what I'm going to write here nor if ever someone gets interested reading it. My blogs may be a novel-like, a one-liner, it doesn't matter. Still, I'm willing to listen to your views, as long as it justifies mine... Well, enjoy your stay, and I hope you'll learn something new because I just did and sharing it with you.. Welcome!
Showing posts with label NFS. Show all posts
Showing posts with label NFS. Show all posts

Monday, July 14, 2008

NFS

I thought it was just another NFS request. Well, technically, it is. What I meant was another mount, and there it goes. But, I was wrong [again]! Just like the other aspect of my life. Hmm, forget it!

Ok. Let's check on the request.

Request: Mount /var/opt/edis/idocs/directory1 to server2 from box1.

Simple? May be.

Steps:
1. Entry was added to exports
2. run `exportfs -a` but error was generated:
parent directory already exported

Several attempts [solution] were tried but none succeeded.
1. comment the parent directory
2. manually exporting the child directory

A colleague thought of a brilliant idea. It was a dull day so I never bother to explore such. Anyway, he suggested to add the client to the parent directory's list, as well as make a root entry for it, then export the FS. Successful, at least the initial part.

Login to the client side. Made a copy of the fstab [a great practice, just in case a stupid me does a stupid thing]. Then add it as:

# cp -p /etc/fstab /etc/fstab.backup.`date`
# vi /etc/fstab

...
/var/opt/edis/idocs/directory1 /var/opt/edis/idocs/directory1 nfs rw ...
...
~
~


The entry added for the client was specific. It means, although the "whole" parent directory was exported, I think it is possible to just put the specific directory to be accessed. At least for this case. I think, no! I need to review more about NFS. Adios!

Thursday, April 10, 2008

Ignite backup

I was surprised to receive a PM from my colleague. As part of the process we follow, we need to make an ignite backup of system we do patching on. Most of the time, it goes smooth but they can never be perfect, 82-0 is just impossible. Anyway, I have encountered this issue a couple of times already. I've read some discussions on this but still trying to understand. Way to far, to many to learn! Going back, here's the error:

...
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

Permission denied
ERROR: Unable to mount or write
server1:/var/opt/ignite/recovery/archives/client_svr1
On server1 you may need to:
mkdir -p /var/opt/ignite/recovery/archives/
client_svr1
chown bin:bin /var/opt/ignite/recovery/archives/client_svr1

vi /etc/exports (add or modify an entry). The /etc/exports file on
"server1" should contain the entry:
"/var/opt/ignite/recovery/archives/client_svr1 -anon=2,access=client_svr1
".
After editing the /etc/exports file, run exportfs -av

If you need to change the owner of the directory,
you will also need to re-export the directory.

See make_net_recovery(1M) for more information.
ERROR: Failed to Create NFS mount Archive directory.

======= 04/10/08 09:07:54 SST make_net_recovery completed unsuccessfully

[root@server1:/var/opt/ignite/recovery]
#

I followed the suggestion here: `mkdir`; `chmod`; and `exportfs` but to no avail. Well, the workaround is NOT to limit access to the specific client, i.e., delete the entry "access=client_svr1" from /etc/exports; then run re-export the FSes. Now, it's working well. As mentioned earlier, it's just a workaround. So we need to restore the entries in the config files.

Read on: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1017493&admit=109447627+1207790553782+28353475

World Clock