technicalinfo

Mount windows share folder into AIX..

mount -v cifs -n winserver/myuser/mypassword /home /mnt
and it works fine

And that's right, it worked perfectly on my AIX server.
Of course, you had to work a little bit before that :
On your PC, you have to create a user, for simplicity let's name this user "myuser", his password is "mypassword". You also have to create a shared resource named "home" (on my PC it's named CX500).
On the AIX server, verify that you have the cxfs lpp :
CONSOLE# lslpp -l *cifs*

you should see something like " bos.cifs_fs.rte 5.3.0.50 COMMITTED Runtime for SMBFS".
If cifs is not installed, you will have to use smit install (with the AIX CD inserted) in order to install it.
And I don't use the /mnt mountpoint, I use /remote, don't forget "mkdir /remote" first.
Then, just typing the "mount" command mounts the PC/NTFS file on your AIX mountpoint.
So, everybody can "cd /mnt ; vi myfile.txt", you will see that the user has read and write permission. Which is normal, the mount command give a regular Windows username and password.
By the way, if you don't type the /mypassword part in the commandline, you are prompted for the Windows myser passwod, and you type it blindly, which is better from a security point of view.
Isn't this nice ? AIX users can startup the install of Oracle patches downloaded on the PC, and the user on the PC can read the comments from files written by the AIX/Unix users.
A nice collaboration between Unix and Windows worlds

1. Run cfgadm to view the status of the SCSI devices

a) cfgadm -al
2. Remove the failed disk.hard drive from the device tree.
a) cfgadm –f -c unconfigure c0::dsk/c0t0d0
b) cfgadm –f -x remove_device c0::dsk/c0t0d0
3. Verify the status of SCSI devices. The required of the defective disk must not appear
a) cfgadm –al

4. Verify the existing metadevices left on the disk by running

a) metastat -p | grep c0t0d0

5. If there are any replicas on this disk, remove them using
a) metadb -d c0t0d0s7 (with –f )
6. To configure the new hard drive, type the following command

a) cfgadm -c configure c0::dsk/c0t0d0
b) cfgadm -x install_device c0::dsk/c0t0d0

7. Create device special files in /devices and logical links in /dev folders

a) devfsadm (no need)

8. Verify the availability of the newly reinstalled disk, type the following command

a) cfgadm –al or with format

9. Copy the disk slice information to new disk run 'prtvtoc' to put the desired partition table on the new disk
a) prtvtoc /dev/rdsk/c0t8d0s2 > c0t8d0_prtvtoc_info (copying from working Mirrored disk)
b) fmthard -s > c0t8d0_prtvtoc_info /dev/rdsk/c0t0d0s2
c) format ; p ; p (to verify slice info)
10) Recreate any replicas on the new disk.
a) metadb -a c0t0d0s7 (-f)
11). Replace and sync the data by running metareplace.
a) metareplace -e d10 c0t0d0s3
b) metareplace -e d100 c0t0d0s0
c) metareplace -e d110 c0t0d0s1
12) Verify the data syncing process
a) metastat |grep sync
b) metastat –p
c) metasync

Please change following in /etc/default/nfs file.

Remove --> NFS_CLIENT_VERSMAX=4.
Add --> NFS_CLIENT_VERSMAX=3,

restart nfs.client service , it works fine.

Q: Why do I get the following error when running yppasswd: "can't find rpc.yppasswd server"
A: This means that you have not enabled rpc.yppasswdd on your NIS master server. Section 3.11 explains how to do this.
Q: Why do I get the following errors when running yppasswd: "RPC timed out" "yppasswd couldn't change entry, RPC call failed." or "passwd file is busy"
A: The passwd file has gotten locked. If there is genuinelly nothing else that should be using it, remove the lock file on the NIS master: %% rm /etc/passwd.tmp Q: How do I hand edit the passwd file when yppasswdd is running? A: rpc.yppasswdd's lock file is '/etc/.pwd.lock'. The admin can prevent the daemon from doing the edit by making that file unwritable ("chmod 000 file" should do it). She should see a syslog msg from the daemon (if a pw change is attempted) "...Passwd file(s) busy...". She should be sure to remove that lock file (or make it writable) when she is done with the hand edit. Another (if a bit crude) workaround is to kill the daemon and restart when the hand edit is done. 5.0: Patches The following is the list of all of the NIS related patches for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having NIS problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com.

responding for domain..."
A1: Your NIS server is currently down. Verify that you can ping it by IP address and if that works, login and check for the ypserv process. If it is not running then start it up.
A2: The netmasks file on your




NIS client is incorrect, and thus the netmask and broadcast addresses are being set wrong. This can be verified by booting the client single user, and then comparing the /etc/netmasks file on the client and server. They should be identical.
A3: Your server is on a different subnet from your client, and you have not followed the appropriate procedures to take this into account. Examine Section 3.6 for an explanation of what to do in this case. The machine will probably need to be booted single user before these changes can be made.
A4: If you are seeing "NIS server not responding" intermittently, but NIS is working in between these messages, your network is likely overloaded. This is a performance issue that SunService can not provide assistance on. Consult Sections 8.0 and 9.0 for alternatives in this situation.
Q: Why can a user not log into my Solaris machine, even though I can see his passwd entry on that machine with 'ypmatch his-name passwd'?
A: Your nsswitch.conf is set up wrong on the client. Section 3.5 gives info on putting the nsswitch.conf file in place when setting up a Solaris client.
4.6: ypcat Problems
Q: How come I can't ypcat a map that I know exists in NIS?
A1: You might have this problem when you try and look at a map in NIS, as follows: # ypcat netmasks no such map in server's domain This occurs because NIS maps actually have unique names that are dependent upon how the map is indexed. Certain NIS maps (ethers, group, hosts, aliases, passwd, protocols, services) have standard nicknames, to make them easier to access. Run ypcat -x to see the list of aliases: # ypcat -x Use "passwd" for map "passwd.byname" ... You can access maps without aliases by using the real name. For example, the real name for the netmasks map is netmasks.byaddr: # ypcat netmasks.byaddr If you cd into /var/yp/`domainname` on your master server, you will see the complete list of actual NIS map names. Ignore the .dir and .pag suffixes.
A2: It may also be that the server you are bound to does not have that map on it. Do a ypwhich to find out what machine you are bound to. If for example, you are bound to a slave server and you cannot ypcat aliases you should check on both that slave server and the master server in the /var/yp/'domainname' directory for the existence of files called mail.aliases.dir and .pag Chances are your master has that map while the slave does not. Follow the procedure listed in the first question in section 4.3 for how to remedy this situation.
Q: Why does ypcat show incomplete info?
A: You might find that when you do a ypcat of a map, some of the info is missing, for example: # ypcat netmasks.byaddr 255.255.255.0 255.255.255.0 In this case, you should run ypcat with the -k option, which also shows you the column that is being indexed off of: # ypcat -k netmasks.byaddr 150.101 255.255.255.0 150.102 255.255.255.0 Q: After I add an entry to a source file and run a make I don't see it in the output of ypcat? A: NIS maps are not guaranteed to list the information in the same order as it is in your source files due to the dbm format. Some other things to be sure of is that you
1) made the change on your NIS master and not on a slave machine (see next paragraph),
2) you made the change to the source file that your NIS Makefile points to and not some other local copy, and
3) the yppush or ypxfr completed in order to give the slave server a new copy of the map. ypwhich -m on any machine in the same domain should always report the same master as owning the map. If you have any discrepancies in the output you should make sure that you are only running a make on your master and not on a slave machine.
Q: Why, when I ypcat a map, do I see multiple lines that are exactly the same sometimes?
A: For example, if you see this: # ypcat hosts grep machineA 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost This is because you are not seeing the keys that the map is indexed with. You should ypcat -k the same map and grep for the same machine and you will see this: # ypcat -k hosts grep machineA machineA 192.115.12.1 machineA mailhost datehost loghost mailhost 192.115.12.1 machineA mailhost datehost loghost datehost 192.115.12.1 machineA mailhost datehost loghost loghost 192.115.12.1 machineA mailhost datehost loghost This map is your hosts.byname map and everytime a lookup for host 'datehost' or host 'machineA' is done the keys are examined in the map and then the appropriate entry is returned. The fact that you have 4 machine names that refer to the same IP address still requires you to have 4 differently keyed entries in the map.

Q: Why doesn't my new slave server get NIS maps when they are made?
A: You have not added the new slave to your ypservers map. You can verify this by examining the ypservers map: # ypcat -k ypservers Section 3.3 explains how to update the ypservers map. You may also have problems if your slave server doesn't already have copies of the maps. See the first questions in section 4.3 for how to remedy this situation.
Q: Why does my groups map not get correctly distributed?
A: Because the netid was not distributed, the groups map does not have all the correct info. Run the following on the master to ensure that the netid is also distributed: # cd /var/yp # rm netid.time # make netid For groups updates to occur, both groups and netid must be distributed. It is always best to just run 'make' and let the processes make and distribute whatever maps have changed. Running make source-file may not update all maps that require changes.
Q: Why is my change to the NIS maps not showing up?
A1: You did not do a make on the NIS master. You can verify this by examining the map with ypcat. To resolve the problem, go to the NIS master and make the files: # cd /var/yp # make A2: If make has been run, you are probably bound to a NIS slave which is not getting updates. You may wish to retry the make, in case the NIS slave was down the first time it was run. Otherwise, you probably need to update the ypservers map. Run ypwhich to see which slave you are bound to, and then examine the ypservers map to verify the problem: # ypwhich slave-3 # ypcat -k ypservers master slave-1 slave-2 If you find that the name which appears in 'ypwhich' does not appear when you look at the ypservers map, follow the instruction in Section 3.3 to update your ypservers map.

Q: Why does 'ypinit -m' crash with the following error: ...
"Running /var/yp/Makefile..." "make: Fatal error: No arguments to build"
"Error running Makefile." ...
A: /var/yp/Makefile does not exist. Copy it over before rerunning ypinit:
# cp /usr/lib/NIS.Makefile /var/yp/Makefile # cd /var/yp # ypinit -m

Q: Why does 'ypinit -s' crash with the following error, when trying to initialize a slave:
"can't bind for domain " "reason: internal NIS server or client error"
"can't enumerate maps from "
A: Your slave was not running ypbind, or it does not have access to NIS currently.
You can verify this by running 'ypwhich' you will see that you are not currently bound to
a NIS domain. Try following the procedure in Section 3.2 precisely. If that does not work,
you may be on a different subnet than your master, and need to initialize ypbind per the
instructions in Section 3.6. We have also seen the error corrected by specifying the hostname
of the master server instead of the IP address.

Q: Why does 'ypinit -s' crash with the following error, when trying to initialize a slave:
"ypxfr(get_misc_recs) RPC call to failed: RPC: Timed out."
A: ypxfrd is not running on the NIS master server. Login to the master server and start it:
# ypxfrd