SUBJECT: Solaris 2.x - NIS+ Environment
Description :
CONTENT: chapter 9.1 - NIS+ Environment
1. 개요
Network의 사용이 늘어나고, 그곳에 연결된 시스템의 수가 증가함에 따라 network의
각각의 시스템들은 그들의 network에 관련된 관리해야할 정보의 수가 증가하게
된다. 즉, network상의 모든 시스템의 주소들을 알아야 하고, mounting을 위한 정보
들과 일반적인 password에대한 정보들을 알아야 하고, client들은 server에 대한
정보를 알아야하고 server들은 그들의 client에 대한 정보를 알아야 한다. 하지만,
이러한 정보들의 관리는 소규모의 network상에서는 용이하였지만, 대규모의 network
상에서는 힘들게 되었다. 이러한 문제점을 해결하고자 한것이 NIS+로 NIS의 향상된
버전이다.
2. NIS+란 ?
NIS+는 사용자, workstation, network resource들에 관한 정보들을 제공하는
service를 말한다. 이것은 적정한 Security를 유지하면서 정보들을 제공한다.
3. NIS+ Client-Server Model
3.1 Client
client는 network에서 정보를 사용하기위한 request를 보내는 시스템 혹은
process를 말한다. 이런 process들은 request를 만들기위해 RPC library들을
call하여 사용한다.
3.2 Server
server는 client process에대한 정보를 돌려주고, database에서 request 정보를
조사하고, client process request를 가지는 process라고 할수있다.
모든 domain은 하나의 master server와 0개 이상의 replica server들을 가져야 한다.
3.2.1 Master server
master server는 table의 형식에서 database information에 대한 master set을
가진다. 이런 table의 변경 혹은 생성은 replica server에게 자동으로 push된다.
3.2.2 Replica server
replica server는 master server가 down된 경우에 정보에대한 backup source를
제공하고 , client request들에 대하여 응답하는 부담을 분산하기위한 table들의
복사본을 유지한다.
4. Hierarchical NIS+ Domains
시스템들의 집합과 그런 시스템들에게 제공되는 정보들을 domain이라고 부른다.
NIS+ domain은 하나의 조직에 대한 계층적인 구조를 실제로 반영한 subdomain으로 나누어
질수 있다.
- Hierachical Domain의 예
예를들면, Acme Inc가 여섯개의 division으로 나누어질때의 모습은 다음과 같다.
acme.com.
|
|
+-----------------------------+----------------------------------------------+
| | | | | |
hardware.acme.com. | marketing.acme.com. | finance.acme.com. |
| | |
software.acme.com. sales.acme.com. legal.acme.com.
|
|
+------------------------------+
| |
testing.software.acme.com. engineering.software.acme.com.
- NIS+ Objects
NIS+ namespace는 NIS+ 정보가 저장된 계층적 구조이다. 각각의 namespace는
namespace의 상위에 있는 root domain을 제공하는 root master server를 가진다.
그리고, NIS+ namespace는 NIS+ command로만 access된다.
NIS+ object의 세가지 일반적인 유형은 directory objects, table objects, group object
가 있다.
- Directory object는 namespace의 주요 구성요소이다.
이들은 다른 directory object , table object , group object를 포함한다.
- Table object는 NIS+ namespace에 정보를 저장한다. Solaris 2.X 환경은 사용자들,
workstation들 , network에대한 resource에대한 정보의 다른 유형을 저장하는 각각의
16개 유형의 table을 제공한다. NIS+ table들의 집합은 단지 특정 domain만을 위한
정보들을 저장하는 것이다.
- Group object는 NIS+ security를 위해 사용하는 것이다. NIS+ group은 NIS+ security
를 유용하게 사용하기위해 단일 이름에 의해 확인되는 사용자들 , workstation들의
집합이다.
5. Directory Objects
Directory Object는 namespace의 framework를 만든다. namespace의 최상위에 있는
directory object는 root directory라고 불리운다. root directory name은 namespace의
계층구조에서 root(top) domain을 나타낸다.
org_dir directory는 NIS+ table object들을 저장한다.
group_dir directory는 NIS+ gropup object들을 저장한다.
NIS+ domain은 NIS+ table의 집합을 가진 org_dir subdirectory와 group_dir subdirectory
로 구성된다. Topmost directory는 root directory이다. 만약, namespace가 flat하면,
단지 하나의 directory이지만, 그 directory는 root directory이다.
6. Using NIS+ Object Names
NIS+ object name들은 그들의 이름을 root directory name에 추가함으로 구성된다.
이것은 소위 fully qualified name이라고 부른다.
- partially qualified names
partially-qualified NIS+ component name은 상대 path-name에 비유되고 , 단지 그것은
component의 이름이다. ( hosts )
- Fully qualified names
fully qualified name은 구성요소들의 완벽한 이름이다.
ex) auto_home.org_dir.sales.acme.com.
- root domain name
root domain name은 dot를 가지고 끝나는 두가지 구성요소를 포함하고 있어야만 한다.
ex) acme.com.
7. NIS+ servers and client
NIS+ namespace에 있는 object들은 NIS+ server상에 저장된다. server들은 request를
요청하는 client들에게 정보를 제공한다. 모든 NIS+ doamin은 자신의 domain안에서 정보를
제공하는 server에대한 list를 명시해야만 한다. 하나의 NIS+ client는 어떤 NIS+ domain
안에 속하게 된다. client가 초기화될때, 그것의 domain name은 확인되며, kernel에
저장되게 된다. 그때에, coldstart file은 client를 위해 만들어지게 된다. 이런 화일은
client의 domain을 지원하는 모든 NIS+ server들에 대한 list이다.
client가 자신의 domain 에 request를 보낼때, 그 domain을 지원하는 server에게 보내지게 된다.
어떤 NIS+ server 는 client가 될수있고, 그리고 그것은 domain을 지원하는것처럼 domain에 속하게 된다.
server가 속한 domain은 root domain으로 다루어질때를 제외하고는 , 그것을 지원하는 doamin
위에 항상 있게된다. root doamin을 지원하는 server는 root domain에 속하게 된다.
+-------+
| queen | acme.com.
+-------+
|
|
+--------------------+----------------------+
| |
+------+ +------+
| king | sales.acme.com. | jack | eng.acme.com.
+------+ +------+
|
|
+----------+
| princess | west.sales.acme.com.
+----------+
+-------------------------------------------------------------------+
| server | Belongs to | supports |
+-------------------------------------------------------------------+
| queen | acme.com. | acme.com. |
+-------------------------------------------------------------------+
| king | acme.com. | slaes.acme.com. |
+-------------------------------------------------------------------+
| jack | acme.com. | eng.acme.com. |
+-------------------------------------------------------------------+
| princess | sales.acme.com. | west.sales.acme.com. |
+-------------------------------------------------------------------+
8. NIS+ Master servers and Replica servers
위의 예는 하나의 server에 의해 지원되는 각각의 domain을 보여주고 있다. 사실, NIS+
domain은 하나의 master server 혹은 하나 , 그이상의 replica server에의해 지원되고
있다. 위의 예에서 보면, 하나의 root server ( master server - queen )가 있다.
두개의 master와 replica server는 NIS+ table information을 저장하고 client request에
응답한다. 하지만, 단지 master는 table에대한 master copy를 저장한다. Replica는 master
복제본의 중복을 저장하는 것이다. replica server를 가지는 하나의 이점은 안전성이다.
만약, master server가 request를 handle할수 없다면, replica server들중의 어떤것이
reply를 할수있다. 다른하나의 이점은 시스템관리를 쉽게할수 있게 하는 것이다. 관리자는
하나의 위치에서 table information을 load하고, 그 master server는 replica server에게
그것을 전파한다. 비슷하게, update는 master server에의해 만들어지고, master server는
replica server에게 update사항을 전파한다.
9. NIS+ Security
9.1 NIS+ Principals
NIS+ security는 unauthorized access로부터 정보를 보호한다. Access는 NIS+ 원칙에
따른다.
NIS+ principal은 다음과 같다.
- NIS+ client에 login하는 user
혹은
- NIS+ client상에서 root로 login하는 user
NIS+ security를 이루기 위해서, 어떤 사용자는 root처럼 login할수 있어야 한다.
+-----------------------------------------------------------+
| 결국, NIS+ principal은 일반사용자이거나 workstation 임 |
+-----------------------------------------------------------+
NIS+ security privilege는 두단계의 NIS+ principal으로 나누어 진다.
1) principal을 확인하는 credential은 domain의 cred table에 저장된다.
2) namespace상에 있는 각각의 object는 다른 범주의 NIS+ principal에 access 권리를 부여한다.
이런 security information은 object definition에 저장된다.
principal request가 object에 access될때, NIS+ server는 특정한 object에 의해 access 권리가
principal에 부여되었는지를 확인한다.
만약, access 권리가 일치하면, server는 그 request에 응답한다.
만약, 일치하지 않으면, server는 request를 부인하고 error message를 돌려준다.
9.2 NIS+ Security
NIS+ server가 NIS+ client로부터 request 요청을 받을때, 우선 principal을
확인한다. 그때, NIS+ server는 principal이 access하기 원하는 object를 찾고
pincipal이 그 object에 적절한 접근권한을 가졌는지 여부를 결정한다.
만약, object의 정의가 principal이 올바른 접근권한을 가졌다면,
server는 접근을 허가한다.
+---------------------------------+
| Principal이 NIS+로 access 요청 |
+---------------------------------+
|
|
+------------------------------------------------------+
| server는 credential을 조사하고 principal을 확인한다 | --> authentication(증명)
+------------------------------------------------------+
|
|
+---------------------------------+
| server는 object 정의를 조사한다 | --> authorization(인증)
+---------------------------------+
|
V
+------+ +---------------------------+ +------+
| NO | <-----| principal은 acces되는가 ? |------>| YES |
+------+ +---------------------------+ +------+
| |
V V
+----------+ +----------+
| server는 | | server는 |
| 접근을 | | 접근을 |
| 거부한다 | | 허가한다 |
+----------+ +----------+
principal을 확인하는 절차는 authentication으로 알려져 있다. object에 대한 access
권한을 검사하는 절차는 authorization으로 알려져 있다.
9.3 Authentication
authentication은 NIS+ server로 요청하는 principal을 확인하는 절차이다.
authentication의 목적은 object로의 access 권한이 조사될수 있도록(authorization process)
principal name을 얻는것이다.
NIS+ server는 자신의 crendential을 검사함으로써 principal을 확인한다.
NIS+는 두가지 형태의 crendential을 수용한다.
- LOCAL credentials : LOCAL credential은 client의 UID를 NIS+ principal name으로
만드는데 사용된다.
LOCAL credential은 password record로부터 client user의 UID,GID를
추출하여 만들어지고, 만들어진 crendential들을 자기 domain의
cred table에 저장한다.
- DES credentials : DES credential은 principal을 확인하기 위해 요구되는 additional password
(or key)상에서 만듬으로써 생성된다..
이런 additional key가 제공되지 않는다면, principal은
unauthenticate되는 것으로 고려되고, object를 access하는것이
거부된다.
항상 principal의 login password와 DES key는 같다.
NIS+ principal을 확인키 위한 정보는 cred table에 저장된다.
각각의 NIS+ domain을 위해 하나의 cred table이 있다.
cred table은 특정한 domain을 access하기를 원하는 NIS+ principal을 위한
authentication information를 저장된다.
9.4 Authorization
NIS+ authorization은 NIS+ principal이 NIS+ object에 대한 access권리를 인정하는 절차이다.
access 권리에는 네가지 유형이 있다.
========================================================================
Access Right Description
========================================================================
Read principal은 object에대한 내용들을 읽을수
있다.
Modify principal은 object의 내용을 수정할수 있다.
Create principal은 table 혹은 directory안의 새로운
objects을 만들수 있다.
Destory principal은 table 혹은 directory안의 object
들을 파괴할수있다.
========================================================================
NIS+ access권리는 file permission과 같은 것으로 생각될수 있다.
9.4.1 Access Rights
authorization의 목적과 access 권리들을 인정키 위해
principal들을 4가지 형태로 분류한다.
=================================================================
category Description
=================================================================
owner single NIS+ principal
group NIS+ principal의 집합
world NIS+에 의해 확인된 모든 principal
nobody unauthenticate principal
=================================================================
access권리는 16자리 문자 list로 표시된다.
이런 access권리는 object들의 정의의 한부분으로 명시된다.
r--- rmcd rm-- r---
Nobody ----
owner ----
group ----
world ----
NIS+ group은 security convenience을 위해 함께 구성된 하나이상의 NIS+ principal이다.
NIS+ group에 대한 정보는 모든 NIS+ domaind의 subdirectory인 groups_dir하에서
NIS+ group object에 저장된다.
참고로 NIS+ group table에 저장되는 것은 아니다. 여기서 말하는 group은 UNIX group이다.
모든 access권리는 nisls command를 이용하면 나타나게 된다.
10. NIS+ Security Levels
위에서 언급한 authorization scheme의 실행은 security에 대한 domain level에 의해 결정된다.
NIS+ server는 세가지의 security level중의 하나로 작동이 된다; 0 , 1 , 2
이런 security level들은 principal의 credential이 검사되는 정도를 결정하는 것이다.
=====================================================================================
security level Description
=====================================================================================
0 principal의 credential에 대한 검사가 행해지지 않는다.
어떤 client도 작동을 수행하도록 한다.
이 level은 초기의 NIS+ namespace들을 setting하고 testing
하기위한 목적으로 사용된다.
=====================================================================================
1 principal의 credential을 검사하고 LOCAL 혹은 DES
authentication을 수용.
local credential들은 쉽게 위조될수 있기때문에, untrusted server
들이 access할지 모르는 network상에서는 이것을 사용하지 말아야 한다.
=====================================================================================
2 principal의 credential을 검사하고 DES authentication만을 수용.
이level은 최상의 security level을 제공하고 , NIS+ server에서는
default level이다.
=====================================================================================
NIS+ server에서 수행되는 rpc.nisd라 불리는 NIS+ service daemon은 /etc/init.d/rpc script로
부터 수행된다. Default security level은 2이다.
test하는 목적으로 lower security level의 NIS+ 환경으로 운영한다면, root master
server의 rpc script를 -S option을 가지고 운영하면 된다.
/usr/sbin/rpc.nisd -r -S 0 ( -r => root server로서 운영하기 위한 daemon option )
11. Name service switch process
Name service switch process는 NIS+ client가 /etc 혹은 NIS+ table들과 같은 하나이상의
source들로부터 정보를 얻게 해준다.
Name service switch configuration인 /etc/nsswitch.conf file은 15종류의 information list와
이런한 source들이 찾어지는 순서를 포함하고 있다.
그 화일의 형태는 다음과 같다.
group source(s)
hosts source(s)
passwd source(s)
- Sources
하나이상의 source들이 각각의 database를 위해 명시될수 있다.
==============================================================================
sources Description
==============================================================================
files client들의 local /etc file들
nisplus NIS+ table
nis NIS map
compat password와 group의 old-style인 "+"를 지원
dns hosts entry에만 적용
==============================================================================
example ) /etc/nsswitch.conf file
passwd: files nisplus
group: files nisplus
이런 syntax는 만약 local의 passwd와 group file들을 조사하여 없을때 NIS+ passwd와
group file들을 조사하라는 것이다.
단지, local passwd와 group file에 국한해서 access를 제한한다면 nisplus항목을 삭제하면 된다.
example ) cat /etc/nsswitch.conf
#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any naming service.
#
#"hosts:" & "services:" in this file are used only if the /etc/netconfig
# file contains "switch.so" as a nametoaddr library for "inet" transports.
passwd: files
group: files
hosts: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the system will
# figure it out pretty quickly, and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
12. Name service switch status / action values
- return status
각각의 source는 NIS+ infromation을 요청하는 사용자에게 value를 return하는
status code를 돌려준다.
================================================================================
status code Description
================================================================================
SUCCESS request된 entry를 발견
UNAVAIL source가 사용불가능함
NOT FOUND source는 어떠한 entry도 포함하고 있지 않음
TRY AGAIN source는 " I'm busy, try later " message를 return함
================================================================================
- Actions
각각의 status code를 위해, 두가지 action이 가능하다.
=============================================
action description
=============================================
continue 다음 source를 시도
return entry 조사를 멈춤
=============================================
Default action은 다음과 같다.
- SUCCESS = return
- UNAVAIL = continue
- NOT FOUND = continue
- TRY AGAIN = continue
ex) cat /etc/nsswitch.conf
...
hosts: nisplus [NOTFOUND=return] files
...
이 syntax의 의미는 NIS+ hosts table만이 조사될수 있다는 것이다.
local table과 NIS+ table둘다 조사하려면, [NOTFOUND=return]의 부분을 지우면 된다.
13. Name service switch configuration file
name service switch configuration file의 네가지 version이 Solaris 2.X release에
포함되어 있다.
- /etc/nsswitch.conf file은 network 정보를 위해 조사되어야 할 source로서, install시
선택된 name service를 명시한 default configuration file이다.
- /etc/nsswitch.files file은 local system의 /etc file들만 조사하는 대체
name service switch file이다.
- /etc/nsswitch.nis file은 먼저 local file을 다음에 NIS database가 참조되는 passwwd,
group,automount,aliases map같은 것을 제외한 모든 정보에대한 primary source로서
NIS database를 사용한다.
왜냐하면, passwd와 group file을 위한 조사는 local file을 먼저 찾고, 나중에 NIS
database를 찾기때문에, passwd file에는 "+"표시가 필요가 없다.
- /etc/nsswitch.nisplus file은 local file을 먼저 찾고, 나중에 NIS database가 참조되는
passwd,group,automount,aliases table을 제외하고 모든 정보를 위한 primary source로
NIS+를 사용한다.
Default /etc/nsswitch.conf file은 install동안 어떤 name service가 선택되는지에 따라 결정된다.
위에서 언급한 다른 switch file들은 name service configuration이 변경될때 /etc/nsswitch.conf
file에 복사하여 사용할수 있다.
SUBJECT: Solaris 2.x - NIS+ Environment
CONTENT: chapter 9.2 - configuration the NIS+ Environment
1. Configuring an NIS+ Root Master
1) NIS+ root master상에 root로 login
2) path를 setting.
# PATH=/usr/lib/nis:$PATH ; export PATH
3) domain name을 set.
# domainname solar.com.
# domainname > /etc/defaultdomain
4) NIS+ source들을 포함하는 name service switch file을 변경.
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
5) root master를 초기화.
# nisinit -r ( -r => NIS+ root server로 초기화)
6) security level 0로 NIS+ domain을 시작.
# rpc.nisd -r -S 0
( security level 0는 setup과 testing을 위해 사용되는 것 )
( security level 0에서는, 어떤 user도 NIS+ map을 edit할수 있음)
7) NIS+ directory structure를 setup.
# nissetup solar.com.
8) NIS table들에 data file information을 추가
# cd /etc
# nisaddent -r -f hosts hosts ( -r => 현존하는 entry 삭제후 다시 만듬)
# nisaddent -r -f passwd passwd
# nisaddent -r -f rpc rpc
# nisaddent -r -f services services
# nisaddent -r -f netmasks netmasks
# nisaddent -r -f bootparams bootparams
# nisaddent -r -f ethers ethers
# nisaddent -r -f group group
# nisaddent -r -f timezone timezone
# nisaddent -r -f protocols protocols
# nisaddent -r -f mail_aliases mail_aliases
# nisaddent -r -f sendmailvars sendmailvars
# nisaddent -m -f shadow shadow ( -m => file or map을 NIS+ table과 merge)
# nisaddent -r -f /etc/auto_master -t automaster.org_dir key_value 'domainname'
( -t table => table은 NIS+ table이 되야 함)
9) NIS+ table들을 검증.
# niscat hosts.org_dir
# niscat passwd.org_dir
10) NIS+ value를 set.
# NIS_PATH='org_dir.$:$'
# export NIS_PATH
# niscat passwd
2. NIS+ Replica server를 setup.
1) /etc/inet/hosts file에 NIS+ master를 추가.
# vi /etc/inet/hosts
ip_address master_name
2) NIS+ root master로 login하고 replica server를 인식시켜줌.
# rlogin master_name
# nismkdir -s replica_hostname solar.com. ( -s => hostname이 replica 임을 지칭)
# nismkdir -s replica_hostname org_dir.solar.com.
3) NIS+ replica server상에 root로 login.
4) domain name을 set.
# domainname solar.com.
# domainname > /etc/defaultdomain
5) NIS+를 포함하는 name service switch file을 변경.
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
6) client처럼 replica server를 초기화.
# nisinit -c -H master_name ( -c => NIS+ client로 초기화
-H hostname => hostname이 진정한 NIS+ server로서 contact 되야함)
7) NIS+ daemon을 시작.
# rpc.nisd
8) NIS+ root master상에서, replica server에대한 table들을 복제.
# nisping solar.com.
# nisping org_dir.solar.com.
3. NIS+ client를 setup.
1. NIS+ client상에 root로 login.
2. doamin name을 set.
# domainname solar.com.
# domainname > /etc/defaultdomain
3. NIS+를 포함하는 name service switch file을 변경.
# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
4. /etc/inet/hosts file에 NIS+ master를 추가.
# vi /etc/inet/hosts
ip_address master_name
5. client를 초기화.
# nisinit -c -H master_name
4. NIS+ client를 구성.
1. domain name을 set.
2. master server를 위한 /etc/inet/hosts entry를 추가.
3. nisinit command를 운영.
5. NIS+ client commands
1) nisls command
- NIS+ directory의 object들의 list를 보여줌.
- syntax : nisls [ -l ] [ directory_name ]
1 column : type
2 column : permissions
3 column : owner의 principal name
4 column : create되는 일시
5 column : object name
# nisls -l
org_dir.solar.com. :
...
T ----rmcdrmcdr--- venus.solar.com Thu Jun 9 11:37:43 1994 auto_master
T ----rmcdrmcdr--- venus.solar.com Thu Jun 9 11:37:43 1994 auto_home
....
2) niscat command
- NIS+ table의 내용을 display.
- syntax : niscat [ -h ] tablename
- ex) # niscat passwd.org_dir
root::0:1:0000-Admin(0000):/:/sbin/sh:
# niscat -h passwd.org_dir
# name:passwd:uid:gid:gcos:home:shell:shadow:
root::0:1:0000-Admin(0000):/:/sbin/sh:
3) nismatch command
- shell script들이 NIS+ table을 조사하는것을 허가함.
- syntax : nismatch key tablename
- ex) # nismatch rimmer passwd.org_dir
rimmer::113:110:Arnold J.Rimmer:/export/home/rimmer:/bin/sh:
4) nisgrep command
- syntax : nisgrep colname=keypat tablename
- ex) # nisgrep 'uid=11[234]' passwd.org_dir
lister::112:110:Dave Lister:/export/home/lister:/home/sh:
rimmer::113:110:Arnold J.Rimmer:/export/home/rimmer:/bin/sh:
kryten::114:110:Keyten Model 3500:/export/home/kryten:/bin/sh:
5) nispasswd command
- NIS+ passwd table안의 entry들을 변경.
- nispasswd는 local /etc/hosts와 /etc/shadow를 수정하거나 읽지는 않는다.
nispasswd는 NIS+ server와 통신하기 위해 secure RPC를 사용하고, network상으로 unencrypt된
password를 절대로 보내지 않는다.
- ex) nispasswd
6) nisdefaults command
- default NIS+ value를 보여줌.
- ex) # nisdefaults
Principal Name : venus.solar.com.
Domain Name : solar.com.
Host Name : venus.solar.com.
Group Name :
Access Rights : ----rmcdr---r---
Time to live : 12:00:00
Search Path : solar.com.
6. NIS+ table상에 data를 추가.
- data들은 몇가지 다른 방법으로 NIS+ table에 추가됨.
. admintool
. nisaddent command
. nistbladm command
7. Administration Tool
- user account manager : NIS+ set
- database manager : auto_home을 nis+로 set
8. NIS+ server & client를 초기화
1. /usr/sbin/nisinit command는 NIS+ client 혹은 server를 초기화.
syntax : nisinit -r
nisinit -c -H host | -B -C coldstart_file
ex) # nisinit -r
This machine is in the solar.com. NIS+ domain.
Setting up root server ...
All done.
# nisinit -c -H venus
This machine is in the solar.com. NIS+ domain.
Setting up NIS+ client ...
All done.
2. nissetup command
NIS+ directory에 있는 표준의 table의 empty version을 만드는 shell script.
ex) # /usr/lib/nis/nissetup solar.com.
org_dir.solar.com. created
groups_dir.solar.com. created
auto_master.org_dir.solar.com. created
auto_home.org_dir.solar.com. created
3. nisaddent command
/usr/lib/nis/nisaddent command는 source file 혹은 standard input으로부터 읽어 NIS+
table에 data를 추가하는 명령.
syntax : nisaddent [ -r ] -f file type [ domainname ]
ex) # cat /etc/passwd | nisaddent passwd --> /etc/passwd 내용을 passwd.org_dir table에 첨가
ex) # nisaddent -rv -f /etc/inet/hosts hosts --> hosts.org.dir table을 /etc/hosts내용으로
대체함
# nisaddent -mv -y myypdomain passwd nisdomain --> myypdomain 의 passwd map을
passwd.org_dir.nisdomain table과 합침
/var/yp/myypdomain directory가 yppasswd.map을 포함한다고 가정함
# nisaddent -m -y myypdomain -Y auto.master -t auto_master.org_dir key_value
--> myypdomain의 auto.master map과 auto_master.org_dir table과 합침
# nisaddent -d hosts --> hosts.org_dir table을 dump함
4. nismkdir command
/usr/lib/nis/nismkdir command는 존재하는 NIS+ domain안에 새로운 NIS+ sub-directory
(sub-domain)를 만들때 사용한다.
이 명령어는 replica server를 위해 directory structure를 만드는데 필요함.
syntax : nismkdir [ -s hostname ] directoryname
ex) nismkdir -s saturn solar.com. --> solar.com. domain안의 root master상에서
replica server saturn을 위해 필요한 directory를 만듬
ex) nismkdir -s saturn org_dir.solar.com.
5. nisping command
/usr/lib/nis/nisping command는 모든 replica server에 ping을 보내는데 사용.
syntax : nisping -f solar.com.
ex) # nisping -f solar.com.
Pinging replicas serving directory solar.com. :
Master server is venus.solar.com.
Last update occurred at Thu Jun 9 11:43:58 1993
Replica server is saturn.solar.com.
Pinging ... saturn.solar.com.
ex) # nisping org_dir.solar.com
Pinging replicas serving directory org_dir.solar.com. :
Master server is venus.solar.com.
Last update occurred at Thu Jun 9 11:42:59 1993
Replica server is saturn.solar.com.
pinging ... saturn.solar.com.
Revison History
작성일자 : 96.11.19
작성자 : 이진수