linuxism

소프트웨어 추가 설치하기(RPM, SOURCE CODE, YUM)

소프트웨어 추가/삭제하기

@RPM(RedHat Package Manager)
-시스템을 운영하면서 필요한 패키지가 설치되어 있지 않은 경우 추가적으로 패키지를
 설치하거나 혹은 불필요한 패키지를 삭제해야하는 경우가 있음

-RedHat 계열의 리눅스는 RPM 형태의 바이너리 패키지로 배포가 됨

-RPM이란,Red Hat에서 만든 패키지 배포 및 관리 프로그램으로 리눅스 소스 및 컴파일 된
 프로그램의 배포, 업그레이드 관리 등을 쉽게 하기 위해 프로그램과 설정 파일 등을 하나로
 묶어 만든 것을 말함

-윈도우에서 Setup,Install등을 사용하듯이 쉽게 필요한 피키지를 설치/삭제할 수 있음

RPM의 장점
-쉬운 패키지 설치/제거 가능
-패키지 업그레이드가 간단
-설치 시간이 컴파일 하는 경우보다 빠름
-패키지의 검증이 가능
-질의를 통하여 패키지에 대한 자세한 정보 확인 가능

# rpm [option][RPM패키지 파일 이름]
OPTION
-v : 설치되는 패키지 메시지 출력
-vv : 자세한 디버깅 정보 출력
-h : 패키지를 설치할 때 해시마크(#)출력
-U : 패키지를 새로운 버전으로 업그레이드,-i 옵션과 함께 사용할 수 없음
     단, 패키지가 없는 경우에는 -i 옵션과 동일함

--replacepkgs : 패키지를 교체,패키지가 설치되어 있어도 다시 설치
--replacefiles : 동일한 파일명이 있으면 교체
--oldpackage : 예전 패키지로 교체할 때 사용
--force : --replacepkgs,--replacefiles,--oldpackage옵션을 모두 사용한 것
--percent : 패키지 파일을 설치할 때 퍼센트 표시
--includedocs : 문서 파일 포함
--excludedocs : 문서 파일은 설치하지 않음
--nodeps : 패키지의 의존성을 무시
--aid : 의존성을 검사하여 의존성 피키지를 자동으로 설치
--test : 패키지를 실제 설치하지 않고 충돌 사항을 점검하여 보고

RPM을 이용하여 패키지 설치하기
① 일반적인 패키지 설치
- # rpm -ivh [피키지파일]
② 설치되어 있는 패키지 교체
- # rpm -ivh [패키지파일] --replacepkgs
③ 의존성 에러 존재 시 무시하고 설치할 경우
- # rpm -ivh [패키지파일] --nodeps
- 패키지 의존성이란? : 어떠한 패키지를 설치할 때 패키지의 동작을 위하여 기본적으로 필요로
  하는 패키지가 있어야 하는 것을 말함
④ 의존성 에러 존재 시 의존성이 있는 패키지들을 먼저 설치한 후 자동으로 설치
- 첫번째 방법 : 에러가 나는 의존성을 따라가며 설치하기
- 두번째 방법 : rpm -ivh [패키지파일] --aid
⑤ 기존 패키지를 업그레이드 하기(설치되어 있지 않은 경우 rpm -ivh 옵션과 동일함)
- # rpm -Uvh [패키지파일]

RPM 패키지 제거
# rpm -e [option] [패키지 이름]
OPTION
--nodeps : 패지기의 의존성을 무시
--test : 패키지를 실제 제거하지 않고 충돌 사항을 점검하여 보고

① 일반적인 패키지 삭제
- # rpm -e [패키지이름]
② 삭제하기 전 의존성이나 충돌 사항 점검
- # rpm -e [패키지이름] --test
③ 의존성 에러 무시하고 강제 삭제
- # rpm -e [패키지이름] --nodeps

RPM 패키지 질의하기
# rpm -q [option]
OPTION
-a : 모든 패키지에 대해 질의를 수행
-f : 파일에 대한 패키지 질의를 수행
-p : 설치되거나 설치되지 않은 패키지 파일에 대한 질의 수행
-i : 패키지 이름,버전,설명 등의 정보 출력
-R : 대상 패키지와 의존서이 있는 패키지 목록 출력
--provides : 패키지가 제공하는 기능 출력
-l : 패키지에 포함되어 있는 파일 출력
-s : 패키지에 포함되어 있는 파일의 상태 출력.
     normal=정상,not installed=설치되지 않음,replaced=다른 것으로 교체
-d : 문서 파일만 출력
-c : 설정 파일만 출력
--scripts : 설치와 제거 과정에서 사용되는 쉘 스크립트가 있다면 쉘 스크립트 출력
--dump : 수정일,MD5 체크섬?,모드,소유자 및 그룹,설정 파일 여부,문서 파일 여부,심볼릭 링크 여부등의
         정보를 덤프(-l,-c,-d옵션 중 하나는 반드시 함께 사용해야 함)

① 시스템에 설치되어 있는 RPM 패키지 리스트 확인(모든 패키지)
- # rpm -qa
② 특정 패키지의 설치 여부 확인
- # rpm -q [패키지명]
- # rpm -qa | grep [피키지명에 포함된 패턴]
③ 특정 파일이 속해 있는 패키지 확인
- # rpm -qf [파일이름]
④ 설치된 패키지에 포함되어 있는 파일 출력(모두)
- # rpm -ql [패키지명]
⑤ 설치된 패키지 파일들의 상태 점검
- # rpm -qs [패키지명]

@YUM(Yellodog Updater Modified)
- RPM 명령의 패키지 의존성 문제를 해결

- 인터넷을 통하여 필요한 파일들을 저장소(Repository)에서 다운로드 해서 설치하는 방식,
  또한 의존성을 가지는 다른 RPM 패키지까지 알아서 다운로드하여 설치

- Update된 패키지들을 검사하고,다운로드하여 설치까지 진행

# yum [option] [mode] [패키지이름]
OPTION
-y : 설치 여부를 묻지 않고 바로 설치함

MODE
install : 패키지를 설치함
check-update : 설치된 패키지 중에서 업데이트가 가능한 패키지 목록 출력
update : 피키지를 업데이트 함
remove : 패키지를 삭제
info : 패키지의 정보 출력
localinstall : 다운로드한 RPM 패키지를 설치

① 특정 패키지 설치
- # yum install [패키지이름]
- # yum -y install [패키지이름]
- -y옵션을 사용할 경우 패키지 설치 여부를 묻지 않고 바로 설치를 진행
② 패키지 정보 보기
- # yum info [패키지이름]
③ 패키지 제거
- # yum remove [패키지이름]
- # yum -y remove [패키지이름]
- -y옵션을 사용할 경우 패키지 설치 여부를 묻지 않고 바로 제거를 진행(만약 의존되어 있는 패키지가 있다면
   모두 삭제가 되므로 주의)
④ 업데이트 가능한 패키지 검색
- # yum check-update
⑤ 패키지 업데이트
- # yum update -> 모든 패키지 업데이트
- # yum update [패키지이름] -> 특정 패키지 업데이트

@SOURCE CODE INSTALL
- Red Hat 계열의 리눅스 운영체제는 거의 모든 패키지가 RPM으로 제공되지만,제공되지 않는 경우도 있으므로
  소스코드를 이용하여 설치해야 하는 경우도 있음

- 소스코드의 설치는 각 패키지마다 그 설치방법이 다르지만,README 또는 INSTALL 파일이 소스파일 내에
  포함되어 있어 설치 방법에 대한 문서를 제공하고 있음

- 소스코드를 이용한 설치이므로 컴파일 과정에서 컴파일러가 필요함
  C컴파일러=gcc 패키지, C++컴파일러=gcc-c++패키지

일반적인 소스코드의 설치 방법(과정)
① 컴파일 환경 설정 - # ./configure
                                 # ./configure --prefix=[디렉토리] -> --prefix옵션을 사용하여 설치 디렉토리 지정 가능
- 환경 설정을 위한 옵션확인은 # ./configure -help 명령어를 이용
② 컴파일 - # make
- 만약 비정상 종료됬을 경우 make된 내용을 초기화 하기 위해 # make clean 명령어를 이용할 수 있음
③ 컴파일된 패키지 설치 - # make install

※소스코드 설치를 위하여 소스코드 구하기
-> # wget [파일이 위치한 웹주소] -> 웹 상의 URL로 바로 파일 다운로드
-> 소스코드 압축 풀기

출처 - http://hackjoo93.blog.me/100153878721

OSGi(Open Service Gateway initiative) Alliance는 1999년에 썬 마이크로시스템즈, IBM, 에릭손 등이 구성한 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 뒤 여러 해 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 이 표준 사양의 핵심은 응용 프로그램의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.

OSGi 프레임워크는 독립적인 자바/가상 머신 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 응용 프로그램 또는 구성 요소(번들, Bundle)는 다시 시동 과정 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled)할 수 있다.

OSGi는 Embeddable(응용 프로그램 내부로 포함될 수 있는) SOA를 구현하고 있다. 이를 통해 응용 프로그램 개발에서 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할 수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)

[편집]OSGi 적용 분야

OSGi의 본래 적용 분야는 RG(Residential Gateway), 홈게이트웨이였으나 OSGi의 응용 가능성으로 인해 훨씬 폭넓고 다양한 분야에 적용 되고 있다. 현재 OSGi 표준 사양은 차세대 스마트폰 뿐만 아니라 이클립스 IDE와 같은 데스크톱 응용 프로그램에까지도 적용되고 있다. OSGi 서비스 플랫폼은 홈게이트웨이, 텔레매틱스 단말(예:BMW, SimensVDO), 모바일 단말, 산업 자동화, 빌딩 자동화, PDA, 그리드 컴퓨팅, 백색가전(예: BSH, 보쉬-지멘스 가전 합작회사의 Serve@Home), 엔터테인먼트 (예: 필립스의 iPronto), 기업 차량 관리(예: Acunia의 Fleet Management Solution), 로봇 미들웨어와 데스크톱 등에 응용할 수 있다.

[편집]OSGi 표준 사양

• OSGi Release 1 (R1): 2000년 5월
• OSGi Release 2 (R2): 2001년 10월
• OSGi Release 3 (R3): 2003년 3월
• OSGi Release 4 (R4): 2005년 10월 / 2006년 9월
  • Core Specification (R4 Core): 2005년 10월
  • Mobile Specification (R4 Mobile / JSR-232): 2006년 9월
• OSGi Release 4.1 (R4.1): 2007년 3월 (별칭: JSR-291)
• OSGi Release 4.2 (R4.2): 2009년 9월

[편집]OSGi 관련 표준

• RFC-2608 (서비스 위치 프로토콜)
• Sun JINI™ (Java Intelligent Network Infrastructure)
• Sun JCP JSR-8 (Open Services Gateway Specification)
• Sun JCP JSR-232 (Mobile Operational Management)
• Sun JCP JSR-246 (Device Management API)
• Sun JCP JSR-249 (Mobile Service Architecture for CDC)
• Sun JCP JSR-277 (Java™ Module System)
• Sun JCP JSR-291 (Dynamic Component Support for Java™ SE - 별칭: OSGi 4.1)
• Sun JCP JSR-294 (Improved Modularity Support in the Java™ Programming Language)

[편집]대한민국의 OSGi 커뮤니티

• 한국 OSGi 사용자 포럼
• SERI Open OSGi 포럼
• 네이버 OSGi 개발자 포럼

[편집]주요 OSGi 적용 프로젝트

• EasyBeans - 오픈소스 EJB2 컨테이너
• 이클립스 - 오픈소스 IDE 및 RCP(Rich Client Platform)
• Nuxeo - 오픈소스 ECM 서비스 플랫폼
• JOnAS 5 - 오픈소스 Java EE 5 애플리케이션 서버
• JPOX - 오픈소스 객체 관계 매퍼
• Newton - 오픈소스 분산 OSGi/SCA 런타임

[편집]관련 서적

• OSGi Service Platform, Release 3, IOS Press, ISBN 1-58603-311-5
• Programming Open Service Gateways with Java Embedded Server(TM) Technology, ISBN 0-201-71102-8

[편집]같이 보기

• Knopflerfish
• Apache Felix

VMWare의 스프링소스 인수를 이상한 눈으로 보는 사람들이 많이 있는 것 같다. 스프링이라는 자바 엔터프라이즈 프레임워크와 VMWare 가상화 솔루션과 무슨 상관이있다고 5천억이라는 적지 않은 돈을 들여서 인수를 했을까 하는 것이다. 그냥 초고속으로 성장하면서 잘나가는 회사의 생각없는 돈지랄이라거나, 돈에 환장한 로드 존슨이 회사 팔아먹고 J사의 M처럼 먹튀하려는게 아닌가 하는 식으로 생각하는 인간들도 있는 것 같다.

내가 인수 당사자가 아니니 속사정이나 진행과정은 잘 모르겠고, 인수경쟁자가 있었는지도 모르겠다. 나를 포함해서 많은 사람들은 스프링을 초기부터 친 스프링적인 모습을 보였고(스프링 1.0시절에 등장한 TopLink스프링지원 기능은 오라클이 먼저 나서서 제공한 것이다) 심지어 스프링을 자신의 미들웨어 솔루션의 핵심 엔진으로 가져간 오라클이 인수하지 않을까 하는 생각을 했을 것이다. 

아무튼 VMWare가 인수했고 로드 존슨은 그것이 단순한 투자목적 내지는 인력확보를 위한 인수가 아니라 새로운 비즈니스와 기술적인 기회를 만드는 것이라고 설명했다.

스프링소스 하면 스프링 프레임워크만을 생각하기 쉬운데 이미 스프링소스는 몇낸 째 서버플랫폼과 관리를 위한 기술에 더 많은 투자를 하고 있다. 사실상 스프링의 개발은 유겐횔러 1인이 대부분 진행하고 있고, 보조적으로 몇명의 개발자들이 필요할 때만 돕는 수준이다. 그에 반해 그동안 스프링소스는 많은 인력을 각종 서버제품과 dm,tc플랫폼, 툴 등에 투입했고 Build, Run, Manage라는 구조의 엔터프라이즈 개발과 운영에 관한 종합 서비스와 플랫폼을 만드는데 힘을 쏟아왔다. 그런면에서 스프링 프레임워크 자체는 스프링소스의 가장 중요한 자산이긴 하지만 비즈니스적으로는 작은 한 부분에 불과하다.

스프링소스가 서버와 플랫폼에 치중하면서 가장 신경을 쓴 것은 바로 OSGi기반의 DM서버이다. 기존의 JEE와는 차원이 다른 진정한 "차세대" 자바 모듈 플랫폼으로서의 OSGi의 가치를 일찍 인지하고 이에 전력을 기울인 결과 스프링소스은 자바 엔터프라이즈 OSGi의 가장 앞서나가는 리더가 되었다. 이미 다음 버전 OSGi의 엔터프라이즈 서비스 표준은 스프링소스가 주도했고, 스펙을 보자면 거의 이름만 다르지 스프링 그 자체이다. 스프링은 2.0부터 스스로 OSGi호환 모듈로 패키징 되어서 제공되고 있고, 가장 방대한 OSGi호환 번들을 제공하는 리포지토리도 운영하고 있다.

OSGi의 매력은 바로 배포이다. JEE와는 비교도 할 수 없을 만큼 유연하고 안정적인 배포기술이 바로 OSGi플랫폼의 매력이다. 거기에 JEE의 솔루션을 그대로 가져다 쓸 수 있도록 만드는 Spring OSGi-DM기술이 결합하면 스프링으로 만들기만 하면 아주 손쉽게 OSGi호환 모듈로 만들 수 있고, 플랫폼에 라이브 배포와 관리가 가능해진다.  거기에 편리한 관리기능이 첨부된 SpringDM서버까지 제공하고 있다.

DM서버가 좀 서두른 감이 있긴 하지만 1.0으로 공개되고 본격적으로 발전하려는 계획을 설명하면서 스프링소스의 리더들이 언급한 것이 바로 VMWare가상화와 OSGi/DM기술의 결합이다. 소위 Cloud 시스템으로 만들어진 VMWare의 대용량 서버가상화기술과 OSGi플랫폼의 장점을 극대화하고 스프링 기반의 JEE애플리케이션을 잘 공급할 수 있는 SpringDM 기술이 결합하면 환상적인 Cloud-OSGi/DM 플랫폼을 만들어 낼 수 있는 것이다. 기껏해야 제한된 API만을 지원하고 서블릿 수준의 배포만 가능한 구글의 GAE(AppEngine)와는 차원이 다른 배포환경을 만들어 낼 수도 있다.

작년에 이미 VMWare와 스프링소스는 이 플랫폼 개발과 스프링 솔루션의 각종 가상화 기술에 대해서 파트너쉽을 맺었고 이를 공동으로 연구해오고 있었다.  SpringDM과 VMWare의 통합솔루션 진행에 대해서는 SpringOne에서 밝힌 바가 있고, 스프링 플랫폼을 가상화하는 부분에 대해서는http://www.eweek.com/c/a/Application-Development/SpringSource-Teams-with-VMware-for-Virtualized-Spring-Solutions/ 이 기사에 잘 나와있다. VMWare는 이미 그 이전부터 스프링소스의 전략적인 파트너였기도 했다.

내 생각엔 아마도 그런 공동의 플랫폼과 JEE/OSGi 환경에 대한 가상화 연구의 결과가 매우 흡족하게 나왔고, 그에 대한 충분한 비전을 공유할 수 있었기에 이번 인수가 진행될 수 있었다고 생각된다. 물론 앞으로의 진행은 두고봐야 겠지만, 비즈니스로서 스프링소스 입장에서 또 VMWare입장에서 볼 때 이번 인수는 상당히 의미있고 가치있는 것이라고 평가될 수 있을 것이다.

출처 - http://toby.epril.com/?p=892