리눅스 HW Time 변경

2018.01.28 02:23 | Posted by 로멘틱가이

OS 시간 관리를 위해 NTP를 보통 쓰는데

BIOS 시간과의 차이 때문에 NTP 업데이트가 불가능한 경우가 있다.

특히, VM의 경우에는 HW Time을 변경하기가 더 힘들기 때문에 다음 명령어를 사용하여 하드웨어 시간을 변경한다.

 

[ 하드웨어 클럭 조회 ]

hwclock -r

 

[ 하드웨어 클럭 변경 ]

hwclock --set --date="2018-01-28 02:02:00"

 

[ 하드웨어 클럭을 현재 시스템 시간으로 변경 ]

hwclock -w --utc

hwclock -w --localtime

 

[ 현재 시스템 시간을 하드웨어 클럭 시간 설정 ]

hwclock -s

 

해당 명령어로 시간을 변경 한 후 ntpupdate 명령어를 사용하여 갱신하면 된다.

Rebooting Pending 상태 확인

2016.07.27 14:27 | Posted by 로멘틱가이

http://ilovepowershell.com/2015/09/10/how-to-check-if-a-server-needs-a-reboot/


Windows Update 후 Rebooting Pending 상태 확인 Registry

TrustedInstaller 추가

2016.03.02 07:44 | Posted by 로멘틱가이

폴더 권한이나 소유자에 TrustedInstaller를 추가하기 위해서는 다음 유저로 검색해야합니다.

 

NT Service\TrustedInstaller

 

 

Shared VHDX 이슈사항

2015.10.18 21:03 | Posted by 로멘틱가이

Storage Space 기반의 Hyper-V 서버 구현 시 다음과 같은 이슈가 있습니다.

Shared VHDX 사용을 위해 다음 예외 사항을 기억해야합니다.

 

- 4K Native 의 경우 Shared VHDX 사용 불가

 

해결을 위해 Storage Pool 구성 시 다음 옵션을 줘야합니다.

(or Virtual Disk 구현 시 Logical Sector Size를 512로 줄 수 있습니다.)

 

–LogicalSectorSizeDefault 512

Ubuntu 방화벽 설정

2015.05.06 11:05 | Posted by 로멘틱가이

우분투 방화벽을 설정하다 보면 Outbound 정책을 설정해야하는 경우가 있습니다.

해당 방법을 소개 합니다.

 

> sudo ufw allow out proto tcp to <Remote IP> port <Remote Port>

 

ex)

sudo ufw allow out proto tcp from 168.126.63.0/24 to 168.168.0.10 port 68

sudo ufw allow out proto tcp to 192.168.0.2 port 80

 

똑같은 방법으로 Inbound 정책은 다음과 같이 설정할 수 있습니다.

 

> sudo ufw allow proto tcp from <Remote IP> to <Local IP> port <Local Port>

 

ex)

sudo ufw allow proto tcp from 192.168.0.0/24 to 192.168.0.1 port 80

 

Mysql Remote 설정

2015.05.05 22:36 | Posted by 로멘틱가이

Web 서버와 Mysql Server를 분리하여 운영할 경우 Web 서버와 Mysql Server간 연결을 할 수 있도록 Setting을 해야합니다.

해당 방법에 대해 알아보도록 하겠습니다.

 

1. Bind Address 설정

(1) Configuration File 위치 확인

> mysqld --verbose --help | grep -A 1 'Defaut options'

해당 명령어 수행 시 아래 Default options 밑에 다음 파일을 읽는다고 명시되어 있습니다.

해당 순서대로 Mysql에 대한 설정을 읽어 옵니다.

확인 결과 /etc/mysql/my.cnf 파일 만 존재 합니다.

해당 파일을 보면 includedir에 두 개의 폴더가 존재하며 해당 폴더 중 /etc/mysql/mysql.conf.d/ 폴더만 존재 합니다. 해당 폴더로 가봅니다.

 

해당 폴더에 있는 파일 중 mysqld.cnf 파일을 열어보면 아래와 같이 bind-address가 있습니다.

 my.cnf에 해당 내용이 있는 줄 알고 한참을 해매고 찾은 내용입니다.

내용을 보면 port가 3306을 사용한다고 되어 있습니다. 해당 port 내용은 방화벽 설정 시 알아보도록 하겠습니다.

 Mysql은 로컬에서 기동된다는 가정하에 DB 를 127.0.0.1로 기동하게 됩니다.

만약 Remote에서 DB를 연결해야하는 경우 기동되는 IP를 0.0.0.0으로 변경해야 합니다.

(2) Bind Address 변경

netstat로 3306 포트로 확인해보면 디폴트로 127.0.0.1로 서비스가 기동되고 있음을 확인할 수 있습니다.

 

위의 bind-address를 0.0.0.0으로 변경 후 mysql 서비스를 restart하면 우리가 원했던 0.0.0.0으로 변경됨을 확인할 수 있습니다.

 

2. 방화벽 Open

(1) 방화벽 Port Settng

3306 포트를 사용하기 때문에 3306 / TCP 를 오픈합니다.

 

3. Web Server에 연동 Module 설치

(1) php5-mysql 모듈 설치

apt-get 을 사용하여 php5-mysql 을 설치합니다.

 

4. Mysql 설정

(1) 데이터베이스 설정

> mysql -u root -p

mysql 로그인

 

> CREATE DATABASE wordpress;

wordpress Database 생성

 

> CREATE USER wordpress@localhost;

User 생성

> Drop user wordpress@localhost

User 삭제

 

> SET PASSWORD FOR wordpress@localhost=PASSWORD("<Password>");'

패스워드 설정

 

>GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost IDENTIFIED BY '<Password>';

wordpress Database에 wordpress 유저에 대해 모든 권한 할당

 

> Select user, host from user;

user별 권한 할당 host 확인

 

> FLUSH PRIVILEGES;

Mysql 리플레쉬

(2) Remote 접속 Test

mysql -u [user 명] -p [Password] -h [서버 IP]

우분투 Firewall Rule 삭제

2015.05.05 12:58 | Posted by 로멘틱가이

Ubuntu 방화벽을 관리하다보면 해당 Rule 을 삭제해야하는 경우가 생깁니다.

 

일반적으로 Rule의 상태를 조회하기 위해서는 다음명령어를 사용하면 됩니다.

 

 

 

위의 룰중 3306에 해당하는 Rule을 삭제하기 위해서 ufw에 대한 help page를 보면 다음과 같이 설명이 나옵니다.

위의 명령어를 보면 delete RULEINUM 이라는 명령어를 사용하면 해당 RULE을 삭제할 수 있다고 나옵니다.

 

그럼 RULEINUM은 무엇인가?~!

방화벽 등록 리스트를 보는 명령어 중 status numbered라는 명령어가 있습니다.

해당 명령어를 사용하면 각 Rule이 숫자로 구분되어 나오게 됩니다.

 

삭제를 하기 위해서는 맨앞에 있는 [ 숫자]로 구분하여 삭제를 하면 됩니다.

만약 3번에 있는 3306을 삭제하기 위해서는 다음과 같이 하면 됩니다.

 

위와 같이 해당 숫자를 입력한 후 3306을 삭제한 것을 볼 수 있습니다.

 

또는 해당 포트와 TCP/UDP구분, IPv4/IPv6 구분 없이 모든 포트에 대한 Rule을 삭제하기 위해서는 다음 방법을 사용합니다.

 

Ubuntu의 방화벽관리는 Redhat 계열의 IPTABLE보다 훨씬 간단한 것을 알 수 있습니다.

 

Ubuntu Apache2 재설치 방법

2015.05.04 01:21 | Posted by 로멘틱가이

Ubuntu Server에서 Apache 서버를 관리 Test를 하다보니 다음과 같은 문제가 발생하였습니다.

Apache2에 대한  Setting을 초기화한 후 Test를 하려고 Apache2 Package를 다음 명령어를 사용하여 삭제하였습니다.

 

> sudo apt-get autoremove apache2

 

삭제 후 살펴보니 /etc/apache2 폴더가 그대로 남아 있어 해당 폴더를 다음 명령어를 사용하여 수동 삭제 하엿습니다.

 

> sudo rm -rf /etc/apache2

 

그 다음 새로 apache2를 설치하였습니다.

 

> sudo apt-get install apache2

 

설치 후 /etc/apache2 폴더 아래를 보면 apache2.conf 파일이 없으며 설치 후 폴더만 존재하는 현상이 발생합니다.

(물론 apache2.conf파일이 없어 apache2 Service도 기동되지 않습니다.)

 

해당 이슈를 해결하기 위해 다음 명령어 수행이 필요합니다.

 

> sudo apt-get remove --purge apache2

> sudo apt-get clean

> sudo apt-get install apache2

 

기본적으로 debian 계열(우분투)는 설정 파일은 별도로 관리하고 있습니다.

해당 파일 삭제를 하기 위해서는 --purge 옵션을 사용한 경우에만 제거가 가능합니다.

 

 

Ubuntu Package 조회

2015.05.04 00:13 | Posted by 로멘틱가이

Ubuntu에서 설치된 Package를 조회하는 방법입니다.

 

> dpkg --get-selections | grep -v deinstall

 

설치한 List를 확인하는 방법입니다.

apt-get에 list가 있을줄 알았는데 없네요

Disk 개념 for Storage Space(5)

2015.02.24 11:22 | Posted by 로멘틱가이

오늘은 Storage Space에서 사용하는 LRC(Local Reconstruction Code)에 대해 알아보겠습니다.

 

일반적으로 Raid 6는 2개의 Parity를 가지고 있습니다.

일반적으로 Raid 구성 시 사용하는 Reed-Solomon(RS) Algorithm의 경우 2개의 Data영역 Failure가 발생해도 안전한 구성입니다.

물론 Parity가 두 개라는건 한 개의 Parity에 비해 Write 시 I/O 비용이 증가합니다.

(두 개의 Parity 영역까지 계산해야하기 때문이죠)~

 

JBOD 시나리오에서는 2개의 Disk Failure까지 커버할 수 있습니다.

심지어 JBOD 2개 Failure까지 커버할 수 있습니다.

일반적으로 Disk Fault가 1개가 발생하기 때문에 과도한 리소스 사용일 수 있습니다.

 

이런 점을 개선하기 위해 LRC 알고리즘이 Storage Space에서는 사용되었습니다.

 

그럼 LRC는 무엇이냐?

Local Parity와 Global Parity라는 개념을 두어 안정성과 성능 두가지를 잡기 위한 알고리즘 입니다.

우선 안정성 측면에서 살펴보겠습니다.

위와 같이 RAID 5와 같이 Local Parity가 사용되어집니다.

단, RAID 5와 다른 점은 Global Parity가 존재합니다.

 

일반적인 Data Disk Fault의 경우 Local Parity를 사용하여 Data를 복원합니다.

예를 들어 다음과 같이 Data가 구성되어 있다고 가정하겠습니다.

 Disk 명

 Data 

 D11 

 1 

 D12

 2 

 D13 

 3 

 D14 

 4 

Local Parity P1 = 10

 

만약 D11이 Fault가 난 경우 다음과 같이 Data가 복구되어 집니다.

10 - (2 + 3 + 4) = 1

 

일반적인 RAID 5와 동일하다고 보시면 됩니다.

 

그럼 Global Parity의 용도는 무엇일까요?

위와 같이 JBOD Enclosure가 4개로 분할되어 있는 경우를 예로 들업보겠습니다.

여기서 1번 Enclosure가 H/W 장애로 죽게되면 Local Parity를 사용하여 복원이 가능합니다.

 

만약 1번 Enclosure가 장애가 나고 D12 Disk가 Fault 가 나면!!!?

RAID5로는 복구가 불가능하게 됩니다.

(이럴때 RAID6로 할걸이란 후회를 하게 되겠죠;;)

 

하지만 LRC 알고리즘에는 Global Parity가 존재합니다.

D23, D24, P2, G1을 사용하여 복구가 가능하게 됩니다.

 

LRC 알고리즘은 결국 RAID6의 안정성과 RAID5의 성능을 혼합하여 만든 알고리즘이라는 것을 알 수 있습니다.

 

다음으로 성능 측면으로 알아보도록 하겠습니다.

위와 같이 12 + 3 + 1 구성인 경우 RAID6는 Storage 용량이 18개가 필요합니다.

LRC의 경우 16개가 필요하죠

즉 2개의 용량을 절약할 수가 있습니다.

(간단하게 갯수로 알아보아 2개뿐이네 라고 생각할 수 있지만 LUN의 단위가 100GB라고 하면 200GB를 절약할 수 있기 때문에 적은 용량은 아닙니다.)

 

Parity 연산에 사용하는 비용은 동일하다고 봐도 될거 같습니다.

(Local Parity 연산 + Global Parity 연산)

 

단 Disk Fault 시는 위에 설명한 대로 Reconstruction I/O는 줄어들며 Enclosure + Disk 장애 or Disk 2개 이상 장애 시는 Reconstruction I/O도 동일하다고 보면 됩니다.

 

2 개 이상의 Disk가 동시에 Fault 날 확률이 적다고 가정 했을때 일반적인 Disk Fault 시에도 성능에 우위를 가져 올 수 있습니다.

 

이렇게 Storage Space에서는 LRC라는 Algorithm을 도입하여 Storage 용량과 성능을 최적화하기 위해 노력하였다는 것을 알 수 있습니다.