An NFS server is configured on both netapp and Unix. How do I see all exported file systems from netapp and unix server using Linux command line option? You need to use the showmount command to see mount information for an NFS server. This command queries the mount daemon on a remote nfs host (netapp or unix nfs server) for information about the state of the NFS server on that machine.
It is a very common requirement to have a shared Unix file system to share and process application related data in SAP environments. Scenario: SAP and ETL application development teams have decided to build file based interfaces. In this particular case we are implementing interfaces between SAP and ETL.
The basic requirements are as follows: SAP needs to be able to write files that ETL can read/delete and visa-versa ETL needs to write files that SAP can read/delete. Both servers are running UNIX. High level outline of process:.
Define Example Landscape. Create An Integration File System. Export File System and Mount. Example Issues / Scenarios.
Creating A New UNIX Group. Set Integration Directory Group Ownership and Permissions. Adjusting The Umask Define Examples SAP and JD Edwards Landscape In our example, we have an SAP development system with SAPSID ECD.
![Nfs Server And File Permissions Unix Nfs Server And File Permissions Unix](/uploads/1/2/5/4/125401060/864874882.png)
We will call this system SAPECD. We also have a ETL development system that we will call ETLDEV. In this example, we will only discuss the steps to integrate the two development servers.
You will need to repeat this process and/or modify this process to configure the rest of your landscape. Recommendations: It is not a common/good practice to share production mount points with DEV and QA systems. Also, limit NFS exports of these filesystems, have a job running from each remote server/application to push/pull data from centralized application. For example, instead of exporting and mounting this file system on 3 or more servers, have the remote applications push/pull the data using sftp from SAP server or ETL server when you have need to share this file system with multiple applications running on multiple servers.
Creating An Integration File System The first step in this process is to request to create a separate physical file system for your interfaces to use. This file system is to be separate from the OS, SAP kernel, and SAP database. This is a very important step of the process. If it not a separate file system, we run into out of space, it could impact runtime environment of business critical applications and these application may stop responding to users. The size of the file system certainly depends on a lot of project specific variables. In general, a 10 gig file system should be a good starting point (or larger if getting extra storage allocated requires several management approvals) for most SAP and other projects. However, an in-depth analysis is required to determine an appropriate amount of storage.
Export File System and Mount In our example, we have created a 10 gigabyte file system for the interfaces and have mounted it to the root of the SAPECD server as the folder /transfer. We have exported this folder from the SAPECD host and created an NFS mount to the root of the EDLDEV server as the folder /transfer. Our servers now have a shared file system between them. Example Issues / Scenarios It has been a pretty straight forward exercise so far in this example. Now we have to assign appropriate ownership, group and permission bits so each server has the correct permissions to read and write to the files. Ls –ld /transfer drwxrwxrwx ecdadm sapsys 96 Sep 25 10:23 /transfer If your permissions are set as above with read,write,execute for all, it is a very bad practice and it exposes your files to all users and you do nothave protection for your data.
This will completely open up the permission on this directory. In this example the mount point/directory is owned by SAP admin user account ecdadm. This user account has a primary group of sapsys. The permissions on this directory are set to allow any user in any group to read, write, and execute from this directory. When an ABAP program is developed to write a file, it will always write the file with the ecdadm account (ecdadm in our example).
When a file is written, it will use the default umask for the user to set the file’s permissions. If we were to write an interface file to /transfer it would look something like this in UNIX.
On SAPECD server, ls -l /transfer -rw-r-r- ecdadm sapsys 256 96 Sep 25 10:28 sapinterfacefile.txt When a ETL program is developed to write a file, it will always write the file with the etladm account. Like SAP, when the file is written it will use the default umask for the user to set the file’s permissions. If we were to write an interface file to /transfer on ETL it would look something like this in UNIX.
On ETLDEV server, ls –l /transfer -rw-r-r- etladm etladm 256 Sep 25 2009 etlinterfacefile.txt -rw-r-r- ecdadm sapsys 256 Sep 25 2009 sapinterfacefile.txt We now have two files in the directory. If you list the contents of the directory on either server you will see the two files. Ls –l /transfer -rw-r-r- etladm etladm 256 Sep 25 2009 etlinterfacefile.txt -rw-r-r- ecdadm sapsys 256 Sep 25 2009 sapinterfacefile.txt Simply mounting a file system between the SAP and ETL servvers is not enough to share files. Neither ecdadm or etladm can update, move, or delete the file written by the other server.
Specifically, sapinterfacefile.txt has -rw-r–r– for its permissions etladm can open and read this file but can not change it. Most SAP integration scenarios that are file based read the file and then archive/delete it. The same issue is true for etlinterfacefile.txt ecdadm can open and read this file but can not change it. An Easy way out to solve this issue is to add etladm to sapsys group and ecdadm to the etladm group. However, this is not a good practice from a security perspective. This would give the ETL admin authorization to SAP and SAP admin authorization to ETL. More Secure – Scenario Create a new UNIX group on both servers to own the /transfer folder, add both ecdadm and etladm as secondary group members, adjust the users umasks, and set the GID bit on the folder.
Let’s Create A New UNIX Group In our example lets call the group “transfer”. We need to add both ecdadm and etladm added to this group as a secondary group; although they both keep their primary groups, sapsys and etladm respectively. The group file contains all the groups configured for a server. In my example, I am going to assume that there is no central user configuration on your UNIX servers. Therefore, when this group is created on both the SAP and ETL server it is important that it is created with the same Group ID.
It is important that you pick a Group ID that is not used on either server. For this example we will use the group ID 300. Entry in /etc/group file transfer:.:300: Set The Integration Directories Group Ownership and Permissions Next, we need to change the ownership on the /transfer folder to have the owner group be “transfer” and not “sapsys”. Ls –ld /transfer drwxrwxrwx ecdadm sapsys 1000 Sep 25 2009 /transfer To change the ownership we run the UNIX command: chown:transfer /transfer OR chgrp transfer /transfer ls –ld /transfer drwxrwxrwx ecdadm transfer 1000 Sep 25 2009 /transfer Notice the group is now “transfer”, not “sapsys”. Next, we need to change the permissions on the /transfer folder to something a bit more secure, as well as set the GID bit. From UNIX issue the following command: chmod 2770 /transfer ls -ld /transfer drwxrws- ecdadm transfer 1000 Sep 25 2009 /transfer Notice the “s”; that is the GID bit. Setting this bit will force all files to adopt the group ownership of the parent directory not the primary group of the user.
Let’s write another file from SAP and ETL and check that file’ permissions. From UNIX issue the following command after writting a file from SAP and ETL to the /transfer directory. Ls –ltr /transfer -rw-r-r- etladm etladm 256 Sep 25 2009 etlinterfacefile.txt -rw-r-r- ecdadm sapsys 256 Sep 25 2009 sapinterfacefile.txt -rw-r-r- ecdadm transfer 256 Sep 25 2009 sapinterfacefile.2.txt -rw-r-r- etladm transfer 256 Sep 25 2009 etlinterfacefile2.txt Notice the group on both files is now “transfer”. However, we have still not fixed our problem because both files were created with 6 44 permissions.
We need our permissions to be 6 64 for every file written to this directory. We will, therefore, need to adjust the UMASK for ecdadm and etladm. Adjusting The UMASK To determine the UMASK to use, you must take the permission you want and subtract it from 777 to get your mask. In our case we would like the files to have 664 permissions.
777 – 664 = 113 You will need to set the UMASK to 113 for both ecdadm and etladm. Let’s write another file from SAP and ETL and check those files out. From UNIX, issue the following command after writting a file from SAP and ETL to the /transfer directory. Ls –ltr /transfer -rw-r-r- etladm etladm 256 Sep 25 2009 etlinterfacefile.txt -rw-r-r- ecdadm sapsys 256 Sep 25 2009 sapinterfacefile.txt -rw-r-r- ecdadm transfer 256 Sep 25 2009 sapinterfacefile.2.txt -rw-r-r- etladm transfer 256 Sep 25 2009 etlinterfacefile2.txt -rw-rw-r- ecdadm transfer 256 Sep 25 2009 sapinterfacefile.3.txt -rw-rw-r- etladm transfer 256 Sep 25 2009 etlinterfacefile3.txt.