Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

slack : configuration management system designed to appeal to lazy admins

http://code.google.com/p/slack/wiki/Subroles 에서 참고할만한 내용만 추가로 발제함

소개

기능 (Features)

  • Subroles are denoted by dots in a role name passed to slack.
    For example, myrole.foo is a subrole of the role myrole, whereas foo, myrolefoo, and myrole-foo are completely separate roles.
  • There can be any number of subrole levels.
    For example: myrole, myrole.foo, myrole.foo.bar, and so on.
  • All subroles live entirely within the directory of the base parent role. They uses files directories with the subrole part of the name appended.
    For example, for myrole, myrole.foo, and myrole.foo.bar:
    • The files for myrole are in .../roles/myrole/files
    • The files for myrole.foo are in .../roles/myrole/files.foo
    • The files for myrole.foo.bar are in .../roles/myrole/files.foo.bar
  • Files in myrole/files.foo override files in the myrole/files directory when the subrole myrole.foo is installed.
  • Any files not present in the subrole will get inherited from the parent role.
    For example, myrole.foo will get .../roles/myrole/files/etc/otherdaemon.conf if .../roles/myrole/files.foo/etc/otherdaemon.conf does not exist.
  • New files can be added in a subrole (files that do not exist in a main role).
  • The files.foo directory can be empty or nonexistent, in which case it has no effect on the files from the parent role, and passing either myrole or myrole.foo to slack will do the same thing as far as files are concerned.
    o You can also have a files.foo.bar with no files.foo, and still use myrole, myrole.foo, and myrole.foo.bar.
  • The overlay of files is done by slack-stage in slack's "STAGE" directory, before install time, so there is no window where overridden files from the parent role appear in the ROOT filesystem.

제한사항 (Restrictions)

  • files는 subroles 에 따르게 적용되지만 scripts 는 아님. scripts 는 인수로 넘겨준 role 이름을 이용하여 서로 다른 행동을 할 수 있음
  • subroles 를 통해 파일을 추가할 수만 있지 삭제하지는 못함.
  • subroles의 파일은 동일한 이름의 부모 파일을 완전히 대체함
  • subroles 는 오직 하나의 부모 롤만 상속을 함. 단일 상속만 제공.

토론 (Discussion)

Why the Flat Layout?

The basic problem is that we are dealing with inheritance across trees of files, instead of just files.

At first, it was tempting to use subdirectories of the main role directory or the files directory to represent subroles. In some ways, this would have made implementation easier. But we decided not to, for two reasons:

  1. It would lead to namespace collisions. If we used subdirectories of the files directory, you might run into trouble if someone tried to install myrole.etc. If we used subdirectories of the main directory, we'd need to reserve names that conflicted with other directories in there (files and scripts), or protect those other directories with some special naming convention.
  2. If you have lots of levels of subroles, it makes it hard to see what's going on.

The layout ends up looking a little weird, because, when looking for files, we turn the role name string myrole.foo.bar into the directory string myrole/files.foo.bar, thus making the first dot kind of special. However, alternatives have their problems:

  1. Moving the hierarchy up one level and using .../roles/myrole/files and .../roles/myrole.foo/files at the same level as .../roles/otherrole/files would not fit the way most people use subroles; they tend to think of them as part of one module, and want them to be kept together in a way unrelated roles are not.
  2. Repeating the first role part like myrole/files.myrole and myrole/files.myrole.foo would make the simple case (no subroles) more complicated.

Why Only Files and not Scripts?

스크립트는 함께 사용.

We do this overlay for files because the filesystem doesn't already have this functionality.

The programming languages one can use for scripts, however, have a wealth of ways of providing this functionality, and any attempt on our part to provide it would pale by comparison. We're also intentionally agnostic about what language the scripts are written in (we just exec() them), so we can't do any fancy things to use any one language's features automatically.

For example, suppose we called a preinstall.subrole script after the preinstall script, and your preinstall script called rm somefile. How would you "override" this code in your second script? The file is already gone.

However, since we pass scripts the full role name, you can use conditionals or OO inheritance in your preinstall script to handle this situation, as well as much more complicated ones.

Why not Multiple Inheritance? 다중 상속을 제공하지 않는 이유는?

다중상속은 일을 더 복잡하게 만든다. 대신 여러개의 롤을 사용하면 된다.

Multiple inheritance would make things more complicated, and in most cases the desired results can be accomplished by installing multiple roles instead.

 

기타 참고사항

/etc/slack.conf 에서 ROLE_LIST 를 지정하는 부분이 있다.
ROLE_LIST=etc/roles.conf

slack 을 옵션없이 실행했을 때 아래와 같이 호스트를 찾을 수 없다는 메시지가 나온다. 그런데 이에 대해서는 man page 등에 설명이 없다.

slack 을 rpm으로 설치하였을 때 롤 항목을 가져오는 프로그램은 다음과 같다.
/usr/lib/slack/slack-getroles

해당 perl 소스를 보면 ROLE_LIST 로 정의한 파일을 읽고 hostname:role 로 구분하여 처리를 하는 것 같다.
해당 파일에 hostname:role name 형태로 입력을 하면 해당 호스트네임에 해당하는 role 을 자동으로 적용한다.
그러나 특정 호스트에 기본값을 미리 설정할 필요는 없을 것 같다.

 

slack 실행시 소스를 별도로 지정할 수 있다. 초기 테스팅을 위해서 slack-test를 이용하는 경우 유용할 것이다.
디렉토리를 지정하거나 rsync 의 module 명을 이용할 수 있다. module명을 이용하는 것이 좋을 것 같다.

 

slack 실행 동작은 다음과 같다.

  • 해당 role의 file, scripts 를 로컬로 sync
  • scripts 에서 preinstall, fixfiles 실행
  • backup 디렉토리 생성
  • files 적용
  • scripts 에서 postinstall 실행

slack rpm 으로 만들기

slack 최신버전을 다운로드 받는다.

slack 디렉토리에 들어가면 slack.spec 파일이 있다. 이 부분이 rpm으로 만들때 이용하면 되는 파일이다.

소스파일과 SPEC 파일을 rpm을 생성할 수 있는 디렉토리로 복사를 한다.

소스에서 /etc/slack.conf 에 마스터서버를 지정하는데 필요한 경우 SOURCE 에 들어가는 서버이름을 등록된 도메인을 이용하도록 변경하는 것이 필요하다.

Release 에 example 을 추가하고 slack-master 서버를 위해 /etc/rsyncd.conf.slack 예제파일도 생성하도록 하였다.
rsyncd.conf.slack 파일을 작성하여 /usr/src/redhat/SOURCES/ 디렉토리에 복사를 해준다. rsync 에서 [slack] 부분은 /etc/slack.conf 파일과 맞추어야 한다.

이제 rpm 파일을 생성한다.

/usr/src/redhat/RPMS/noarch/slack-0.15.2-1.example.0.1.noarch.rpm 파일이 생성되고 이 파일을 설치하면 바로 slack 이용이 가능하다.

만들어진 rpm 파일 목록 보기

Labels
  • No labels