linux - cgroups (control groups)

System/Linux 2014. 3. 2. 18:18


cgroups (control groups)은 프로세스 그룹의 리소스 (CPU, 메모리, 디스크 I / O 등)의 이용을 제한 · 격리하는 Linux 커널 의 기능. "process containers"라는 명칭으로 Rohit Seth 2006 년 9 월부터 개발을 시작 [1] , 2007 년 에 cgroups 및 명칭 변경되어 2008 년 1 월에 Linux 커널 2.6.24에 병합 된 [2] . 그 이후로 많은 기능과 컨트롤러가 추가되었다.

기능 [ 편집 ]

설계 목표 중 하나는 nice처럼 하나의 프로세스를 컨트롤하는 것부터 OpenVZ 와 Linux-VServer 처럼 OS 레벨에서 가상화까지 다양한 사례를 통일 된 인터페이스에서 제공하는 있다.

cgroups는 다음과 같은 기능을 제공하고있다.

  • 자원 제한 : 그룹의 메모리 사용량을 제한 할 수있다. 이것은 파일 시스템 캐시를 포함 [3] . 원래의 논문은 Containers : Challenges with the memory resource controller and its performance라는 제목으로 Linux 심포지엄에서 발표 된 [4] .
  • 우선 순위 : 여러 그룹에 의해 큰 CPU [5] 와 디스크 I / O 처리량을 할당하고있다 [6] .
  • 기록 : 시스템이 얼마나 자원을 시험하고 있는지 측정한다. 결제 용 등 [7] .
  • 격리 : 다른 네임 스페이스에 그룹을 분리하고 다른 그룹의 프로세스 네트워크 연결 파일이 눈에 띄지 [2] .
  • 컨트롤 : 그룹을 멈추거나 검사 점하거나 재개 할 수있는 [7] .

이용법 [ 편집 ]

cgroups은 동일한 기준으로 수집 된 프로세스의 집합이다. 그룹은 계층 구조가 각각의 그룹은 상위 그룹의 제한을 잇는다. 커널은 여러 컨트롤러 (서브 시스템)에 cgroup의 인터페이스를 통해 액세스 할 수있는 [2] . 예를 들어, 메모리 컨트롤러는 메모리의 사용을 제한하고 ns 컨트롤러는 프로세스를 별도의 네임 스페이스로 분리하고, cpuacct CPU의 사용량을 설명하는 등.

cgroups은 여러 가지 방법으로 사용 가능하다.

  • 가상 파일 시스템에 수동으로 cgroups에 액세스 할
  • libcgroup에서 제공되는 cgcreate, cgexec, cgclassify 등의 도구를 사용하여 작성 · 관리
  • 규칙 엔진 데몬을 사용하여 자동으로 특정 사용자 그룹을 이동 시키거나, 설정에 설명 된대로 cgroups 명령어를 내기도한다.
  • LXC [8] 와 libvirt 등 다른 cgroups를 이용하는 소프트웨어를 통해 간접적으로 이용한다.

네임 스페이스의 격리 [ 편집 ]

기술적으로 cgroups의 일부는 아니지만 관련 기능으로 네임 스페이스의 격리가 다른 그룹의 자원을 그룹의 프로세스는 보이지 않게 할 수있다. 예를 들어, PID 네임 스페이스는 각 네임 스페이스마다 다른 프로세스 번호를 할당합니다. 마운트, UTS, 네트워크, SysV IPC 네임 스페이스 등이 이용 가능하다. 만약 "ns"cgroup이 탑재되어있는 경우 각각의 네임 스페이스는 cgroup 계층 구조에서 새로운 그룹을 만든다.

  • PID 네임 스페이스 - 프로세스 번호 (PID)를 할당 프로세스 목록과 상세 정보를 고립시킨다. 새 네임 스페이스는 형제 네임 스페이스에서 고립되어 있지만, 부모 네임 스페이스는 하위 네임 스페이스의 과정을 볼 수있다 [9] .
  • 네트워크 네임 스페이스 - 네트워크 인터페이스 (물리적 또는 가상), iptables 방화벽 규칙, 라우팅 테이블 등을 분리한다. 네트워크 네임 스페이스는 "veth"가상 이더넷 장치에 상호 연결할 수있다 [10] .
  • UTS 네임 스페이스 - 호스트 이름을 변경할 수
  • 마운트 네임 스페이스 - 다른 파일 시스템 레이아웃을 만들거나 특정 마운트 지점을 읽기 전용으로있다 [11] .
  • IPC 네임 스페이스 - System V 프로세스 간 통신을 격리 할 것.
  • 사용자 네임 스페이스

네임 스페이스는 unshare ()와 clone ()에서 플래그를 설정하여 만들 수있다 [12] .

관련 항목 [ 편집 ]

참조 [ 편집 ]

  1. ^ Jonathan Corbet ( 2007 년 5 월 29 일 ). "Process containers" . LWN.net
  2. ^ a B C Jonathan Corbet ( 2007 년 10 월 29 일 ). "Notes from a container" . LWN.net
  3. ^ Jonathan Corbet ( 2007 년 7 월 31 일 ). "Controlling memory use in containers" . LWN
  4. ^ Balbir Singh, Vaidynathan Srinivasan ( 2007 년 7 월 ). Ottawa Linux Symposium. http://www.kernel.org/doc/ols/2007/ols2007v2-pages-209-222.pdf
  5. ^ Jonathan Corbet ( 2007 년 10 월 23 일 ). "Kernel space : Fair user scheduling for Linux" . Network World
  6. ^ Kamkamezawa Hiroyu (2008-11-19). "Cgroup and Memory Resource Controller" (PDF presentation slides) Japan Linux Symposium
  7. ^ a B Dave Hansen. "Resource Management" (PDF presentation slides) Linux Foundation
  8. ^ Matt Helsley ( 2009 년 2 월 3 일 ). "LXC : Linux container tools" . IBM developerWorks
  9. ^ Pavel Emelyanov, Kir Kolyshkin ( 2007 년 11 월 19 일 ). "PID namespaces in the 2.6.24 kernel" . LWN.net
  10. ^ Jonathan Corbet ( 2007 년 1 월 30 일 ). "Network namespaces" . LWN.net
  11. ^ Serge E. Hallyn, Ram Pai ( 2007 년 9 월 17 일 ). "Applying mount namespaces" . IBM developerWorks
  12. ^ Janak Desai ( 2006 년 1 월 11 일 ). " Linux kernel documentation on unshare " 2011 년 10 월 21 일 보기.

외부 링크 [ 편집 ]



출처 - http://ja.wikipedia.org/wiki/Cgroups




저작자표시

'System > Linux' 카테고리의 다른 글

gnome - gconf  (0) 2014.03.07
linux - saslpasswd2  (0) 2014.03.03
linux - rc.local  (0) 2014.03.02
linux - sudo  (0) 2014.02.23
linux - /var  (0) 2014.02.23
Posted by linuxism
,

linux - rc.local

System/Linux 2014. 3. 2. 17:35


How To Automatically Run Scripts On Boot Again With Fedora Linux’s systemd

PostDateIcon July 10th, 2012 | Author: jon 


Back in the good old days of Linux/UNIX, there was a file (usually) located under “/etc/rc.local” that would, after all run-level specific processes have been started, run whatever scripts were in the rc.local file. With Fedora Linux moving away from the more traditional “sysvinit” service manager, this rc.local file no longer exists for running whatever of your own bash scripts/commands you might want to run after the run-level specific processes have been started.

Luckily, you can re-enable this functionality :-) Obviously, you’ll need to be root for this so if you’re not already, elevate yourself to the root user:-

su - root

Then you need to re-create the rc.local file with:-

touch /etc/rc.local

chmod +x /etc/rc.local


Next, open the file for editing:-

vi /etc/rc.local

As this is basically a bash script itself, you need to include the bash interpreter as the first line of the file.

#!/bin/bash

You can now add whatever scripts or commands you like here – they will be run after everything else at your specific run-level has been started. In order for systemd to recognise and use this file, the systemd rc-local.service must be enabled.

systemctl enable rc-local.service

You can check the status of this service with:-

systemctl status rc-local.service

That’s all that’s required. Anything contained in this rc.local file will now be executed last-thing on reboot. Enjoy!


출처 - https://ask.fedoraproject.org/en/question/26898/what-is-the-auto-start-file-like-rclocal/

http://joshua14.homelinux.org/blog/?p=1377







[root@fedora17 etc]# systemctl enable rc-local.service

The unit files have no [Install] section. They are not meant to be enabled using systemctl.

[root@fedora17 etc]# systemctl status rc-local.service

rc-local.service - /etc/rc.d/rc.local Compatibility

 Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)

 Active: inactive (dead)

 CGroup: name=systemd:/system/rc-local.service


#ln -s /etc/rc.d/rc.local /etc/rc.local







리눅스나 유닉스는 워낙 종류가 많아서 뭐라 딱잘라서 답하기 힙듭니다. 그래서 5 가지로 요약해 보았습니다.


1) /etc/rc.local 

이 파일은 컴퓨터가 시작할때 모든 프로그램들을 시작하고나서 따로 시작하고 싶은 시스템 프로그램이 있을때 씁니다.  보통 간단하게 끝낼수 있는  customized 된 system command 를 씁니다. 사용방법은 그냥 ㅤㅁㅐㅌ 밑줄에 실행 파일 이름을 써주시면 됩니다


2) /etc/init.d/프로그램들

여기는 시스템 서비스(daemon) 로 들어가는 프로그램들을 모아두는 곳입니다. 대부분 여기에 모아놓고 run level 에 따라서 /etc/rc/ rc.1, rc.2, rc.3, rc.4,rc.5 로 가서 적절한 프로그램들을 실해 시킵니다. 여기는 service 나 daemon  전용입니다.


3) /etc/bashrc 

이건 유저들이 bash 를 쓴다고 가정을 할때, 모든 유저들에게 해당하는 부분을 시작하는 겁니다. 예를 들면 라이브러리나 path 설정 같은거요


4) ~/.bashrc

이건 2) 번 과 똑같은거 이지만 개인 유저들에만 적용되는 것입니다. 보통 여기를 젤 많이 건드립니다.


5) 유저 하기 나름


말씀 드렸듯이 이게 linux 의 통상적으로 적용되는 룰 입니다. 보통 시스템 레벨 프로그램은 rc.local 에 가장 많이 넣지만, daemon 으로 만들고 싶으면 /etc/init.d 에 넣고 시간이 걸리더라고 daemon 으로 만드는 방법을 찾아 보시면 됩니다.

그냥 유저 레벨에서 사용하고 싶으시면 ~/.bashrc 에 넣고 하시는게 젤 편하구요.


참고로 명령어 뒤에 &  를 넣으면 background 에서 돌아간다는것도 염두에 두셔야 할겁니다. 왜냐면 순처작으로 script 가 진행이 될때에는 특정 라인의 command 가 끝나지 않으면 다음으로 가지 않을수 도있기 때문입니다.


그리고 ubuntu 가 뭘 어떻게 하는지는 저도 잘 몰겠네요. 말씀 드렸듯이 워낙 할수 있는 방법이 많아서요, source 를 보기 전에는 정확히 말씀 못드리겠네요. 참고로 저는 fedora 광팬입니다 ^^ Redhat 이 돈받기 시작하면서 부터 그냥 쭉 fedora 써 왔거든요


출처 - http://k.daum.net/qna/view.html?category_id=QCE003&qid=3ZwUa&q=%B8%AE%B4%AA%BD%BA+%BD%C3%C0%DB%C7%C1%B7%CE%B1%D7%B7%A5&srchid=NKS3ZwUa






저작자표시

'System > Linux' 카테고리의 다른 글

linux - saslpasswd2  (0) 2014.03.03
linux - cgroups (control groups)  (0) 2014.03.02
linux - sudo  (0) 2014.02.23
linux - /var  (0) 2014.02.23
linux - install problem wine in fedora 17  (0) 2014.02.16
Posted by linuxism
,

mongodb - User Privilege Roles

DB/MongoDB 2014. 2. 23. 23:31


User Privilege Roles in MongoDB

New in version 2.4: In version 2.4, MongoDB adds support for the following user roles:

Roles

Changed in version 2.4.

Roles in MongoDB provide users with a set of specific privileges, on specific logical databases. Users may have multiple roles and may have different roles on different logical database. Roles only grant privileges and never limit access: if a user hasread and readWriteAnyDatabase permissions on the records database, that user will be able to write data to the recordsdatabase.

Note

 

By default, MongoDB 2.4 is backwards-compatible with the MongoDB 2.2 access control roles. You can explicitly disable this backwards-compatibility by setting the supportCompatibilityFormPrivilegeDocuments option to 0during startup, as in the following command-line invocation of MongoDB:

mongod --setParameter supportCompatibilityFormPrivilegeDocuments=0

In general, you should set this option if your deployment does not need to support legacy user documents. Typically legacy user documents are only useful during the upgrade process and while you migrate applications to the updated privilege document form.

See privilege documents and Delegated Credentials for MongoDB Authentication for more information about permissions and authentication in MongoDB.

Database User Roles

read

Provides users with the ability to read data from any collection within a specific logical database. This includes find() and the following database commands:

readWrite

Provides users with the ability to read from or write to any collection within a specific logical database. Users with readWritehave access to all of the operations available to read users, as well as the following basic write operations: insert(),remove(), and update().

Additionally, users with the readWrite have access to the following database commands:

Database Administration Roles

dbAdmin

Provides the ability to perform the following set of administrative operations within the scope of this logical database.

Furthermore, only dbAdmin has the ability to read the system.profile collection.

userAdmin

Allows users to read and write data to the system.users collection of the user’s database. Users with this role will be able to modify permissions for existing users and create new users. userAdmin does not restrict the permissions that a user can grant, and a userAdmin user can grant privileges to themselves or other users in excess of the userAdmin users’ current privileges.

Important

 

userAdmin is effectively the superuser role for a specific database. Users with userAdmin can grant themselves all privileges. However, userAdmin does not explicitly authorize a user for any privileges beyond user administration.

Note

 

The userAdmin role is a database-specific privilege, and only grants a user the ability to administer users on a single database. However, for the admin database, userAdmin allows a user the ability to gain userAdminAnyDatabase. Thus, for the admin database only, these roles are effectively the same.

Administrative Roles

clusterAdmin

clusterAdmin grants access to several administration operations that affect or present information about the whole system, rather than just a single database. These privileges include but are not limited to replica set and sharded cluster administrative functions.

clusterAdmin is only applicable on the admin database, and does not confer any access to the local or config databases.

Specifically, users with the clusterAdmin role have access to the following operations:

For some cluster administration operations, MongoDB requires read and write access to the local or config databases. You must specify this access separately from clusterAdmin. See the Combined Access section for more information.

Any Database Roles

Note

 

You must specify the following “any” database roles on the admin databases. These roles apply to all databases in a mongod instance and are roughly equivalent to their single-database equivalents.

If you add any of these roles to a user privilege document outside of the admin database, the privilege will have no effect. However, only the specification of the roles must occur in the admin database, with delegated authentication credentials, users can gain these privileges by authenticating to another database.

readAnyDatabase

readAnyDatabase provides users with the same read-only permissions as read, except it applies to all logical databases in the MongoDB environment.

readWriteAnyDatabase

readWriteAnyDatabase provides users with the same read and write permissions as readWrite, except it applies to alllogical databases in the MongoDB environment.

userAdminAnyDatabase

userAdminAnyDatabase provides users with the same access to user administration operations as userAdmin, except it applies to all logical databases in the MongoDB environment.

Important

 

Because users with userAdminAnyDatabase and userAdmin have the ability to create and modify permissions in addition to their own level of access, this role is effectively the MongoDB system superuser. However,userAdminAnyDatabase and userAdmin do not explicitly authorize a user for any privileges beyond user administration.

dbAdminAnyDatabase

dbAdminAnyDatabase provides users with the same access to database administration operations as dbAdmin, except it applies to all logical databases in the MongoDB environment.

Combined Access

Some operations are only available to users that have multiple roles. Consider the following:

sh.status()
Requires clusterAdmin and read access to the config database.
applyOps, eval [1]
Requires readWriteAnyDatabase, userAdminAnyDatabase, dbAdminAnyDatabase and clusterAdmin (on the admindatabase.)

Some operations related to cluster administration are not available to users who only have the clusterAdmin role:

rs.conf()
Requires read on the local database.
sh.addShard()
Requires readWrite on the config database.
[1]The mongo shell provides db.eval() as a helper for the eval command. As a wrapper, db.eval() requires the same privileges.


출처 - http://docs.mongodb.org/manual/reference/user-privileges/#dbAdminAnyDatabase


저작자표시

'DB > MongoDB' 카테고리의 다른 글

mongodb - $all, list/array에서 검색  (0) 2014.03.21
mongodb - $elemMatch, list/array에서 검색  (0) 2014.03.21
mongodb - backup  (0) 2014.02.23
mongo - TTL  (0) 2014.01.15
mongodb - 콜렉션 필드 형변환 (How to change the type of a field)  (0) 2013.10.07
Posted by linuxism
,

티스토리툴바