[2013.09] BSD Server Maintenance

BSD Server Maintenance

서버를 설치하는 법은 수많은 사이트와 핸드북에서 설명되어 있지만, 일단 서버가 동작하게 되면 관리자가 계속 유지 가능한가? 이 글은 BSD 서버를 관리하는 기본에 대해서 설명한다. Many sites and handbooks explain how to install servers, but once a server is running, can an administrator keep it that way? This article will cover the basics of maintaining a BSD server.

---

당신이 배우게 될 것들... What you will learn...

• BSD서버를 관리하는 법. How to maintain any BSD server.

• 서버 관리의 기본 규칙. Some basic rules of server maintenance.

• 유용한 셸 명령들. Some helpful shell commands.

• 로그의 중요성. The crucial importance of logs.

• BSD 서버 백업. Backing up BSD servers.

• 보안. Security.

• 문제 찾기. Finding problems.

• BSD 또는 LPI 인증을 위해서 관리자가 준비하는 걸 도와줄 몇가지 정보. Some basic information that will help prep admins for their BSD and/or LPI certifications

당신이 미리 알고 있어야 하는 것들... What you should know...

• 기본적인 셸 명령. Basic shell commands.

• 기본적인 네트워크 개념. Basic network concepts.

• BSD와 유닉스 시스템의 이해. Understanding of BSD and Unix systems.

• 다른 서버나 데몬에 관한 일반적인 개념. General idea of the different server services and daemons.

---

많은 서버 관리자들이 FreeBSD 서버를 셋업하는 방법을 알고 있을 것이다. 하지만 일단 서버가 동작한 후에 계속 관리가 가능한가? 많은 회사들이 재고목록이나 상품가격과 같은 정보를 서버에 저장할 것이다. 만약 서버가 다운되면, 회사의 일부 혹은 전체가 다시 서버가 가동될때까지 업무를 하기 힘들것이다. 게다가 상품을 판매하는 웹사이트를 호스팅하는 서버였다면, 서버가 고쳐질때까지 고객이 구매할 수도 없을 것이다. 이것은 서버가 다시 가동될때까지 서버는 금전적인 손실을 입는다는 것을 의미한다. 만약 데이터가 손실되기라도 하면 더 많은 손해를 볼 것이다. 명백히, 서버가 다운되지 않도록 하고 자료를 안전하게 보관하는 일은 중요하다고 하겠다. 서버를 다룰때 관리자들이 제대로 이해하고 배워야할 두 디렉토리가 있는데, 그것은 바로 /etc/ 와 /var/ 이다.

 Many server administrators may understand how to set up a FreeBSD server, but once it is up, can they keep it running? Many companies may store business transactions on servers like stock lists and item prices. If the server(s) goes down, a part of or the entire company is unable to continue or perform well until the server is back up. Also, if the server is used to host a website that sells products, customers cannot make purchases until the server is fixed. This means that the company loses money until the server is back online. If the data is lost, this means the company loses more profits. Clearly, it is important to keep the servers healthy and the data safe and secure. When dealing with servers, the two most important directories that all administrators should thoroughly understand and learn are /etc/ and /var/.

NOTE

FreeBSD 9.1 버전을 기준으로 설명하지만, BSD 배포판에는 다 통용되고 상당수의 리눅스/유닉스 시스템에도 통용된다. I am using FreeBSD v9.1 for my descriptions and examples, but this article is valid for any BSD distro and many Linux/Unix operating systems.

NOTE

이 글에서는 서버 설치는 다루지 않는다. 서버 관리와 보호에 대해서만 설명할 것이다. This article will not discuss how to install a server. It will only explain server maintenance and protection.

Logs

서버를 관리할때 가장 좋은 것은 문제가 생기기전에 방지하는 것이다. 고맙게도 많은 서버들에는 로그그 시스템이 있다. 대부분의 어플과 서비스는 소프트웨어의 상태와 에러를 나열하는 로그가 있다. 에러가 탐지되면, 관리자는 충분히 시간을 들여서 조사하고 앞으로 일어날 사태를 방지해야 한다. When maintaining a server, it is best to prevent issues before problems arise. Thankfully, many servers have a log system. Most applications/services have a log that lists the software’s status and errors. When an error is spotted, the administrator should take the time to investigate and prevent future disasters.

 로그는 /var/ 디렉토리에 저장된다. 로그 파일 이름은 쉽게 내용과 목적을 알 수 있게끔 되어 있다. 예를 들어 samba 로그는 /var/log/smb.log 이다. 어떤 프로그램은 (아주가끔) 현재 유저의 홈 디렉토리에 로그를 저장하기도 한다. 로그를 찾을수 없을때는 root의 홈디렉토리를 찾아보거나 프로그램의 매뉴얼을 참조하자. Logs are stored in /var/. The logs are given names that easily identify their content or purpose. For example, the Samba log would be /var/log/smb.log. Some applications (rarely) store logs in the current user’s home folder. If a log cannot be found, check in Root’s home folder or read the application’s manual for the log location.

 만약 HTTP 서비스가 특정한 이슈가 있고 IT 기술자가 아파치 로그를 살펴보느라 많은 시간을 낭비하고 싶지 않을때는 아래처럼 검색해볼 수 있을 것이다. If the HTTP services are having specific issues and the IT tech does not want to spend a lot of time searching through the Apache log, then the tech can do a specific search like below.

grep SOME_ISSUE_TO_SEARCH /var/log/httpd-error.log

예를 들어 커넥션 에러를 찾으려면, "connection"이나 "failed" 또는 "404" (HTTP 커넥션 에러 번호) 등의 비슷한 단어를 찾아라. For example, when searching for a connection error, search for words like “connection”, “failed”, “404” (HTTP connection error number), and other similar terms.

 서버 관리자는 이더넷 이슈가 있을때는 위와 비슷한 명령을 사용해서 "Ethernet"이 포함된 부팅로그를 찾아 볼수 있을 것이다. 부팅로그를 보는 전용 명령은 아래에 있는데, 이 명령은 /var/run/dmesg.boot 의 내용을 보여준다. A server maintainer may use a command like the above to search the boot-up logs for lines containing the word “Ethernet” when there appears to be an Ethernet issue. There is a command specifically for viewing the boot-up log seen below. The command below displays the contents of /var/run/dmesg.boot.

dmesg -a | less

이 명령을 이용해서 관리자는 부팅 메시지를 스크롤해서 볼수 있다. 예를 들어 USB에 관련된 항목들을 보려면 아래의 명령을 시도해보라. This command will allow the administrator to scroll through the boot messages. When searching for entries concerning the USB system, for instance, try the below command.

dmesg -a | grep usb

때때로 dmesg 명령의 결과를 살펴보는 것은 중요한데, 가끔은 에러들이 하드웨어나 부팅프로세스와 연관이 있기 때문이다. 서버가 부팅시에 문제가 있으면 회사나 네트워크에 문제가 생길수 있다. It is important to occasionally browse the output of the dmesg command, because sometimes errors may start occurring with the hardware or boot-up process. If the server has problems booting up, the network’s or company’s performance may suffer.

Paper Logs

서버실이나 다른 안전한 공간에 물리적인 로그를 보관하는 것이 좋다. 이 로그에는 변경된 파일, 인스톨한 소프트웨어, 그리고 수리한 하드웨어의 목록이 있어야 하고, 각각에 대해서 육하원칙에 따른 설명이 덧붙여져 있어야 한다. It is best to keep a physical log in the server room or some other secure storage location. This log should include a list of all files changed, software installed, and hardware repaired along with answers to the following questions – who, what, why, when, where, and how.

Who

서버를 다룬 모든 IT 담당자의 기록을 보관하는 것은 유용하다. 이 기록은 에러에 대해서 알지도 모르는 사람을 추정하는데 도움이 된다. 서버가 다시 NTP 서비스에 에러가 있다고 가정해보자. 만약 IT 담당인 Bill이 지난번에 그걸 수정했던 사람이라면 다시 Bill한테 그 문제를 체크하라고 하는게 최선일 것이고, 아니면 Bill에게 자문을 구할수도 있을 것이다. 다른 예로, 만약 Andrew가 뭔가 변경한 다음에 항상 문제가 발생한다면 그점을 조사해 보는게 최선일 것이다. It helps to keep a written record of all IT techs that have dealt with the server. This helps keep track of all who may be aware of an error. Assume the server is having errors with the NTP services again. If Bill, the IT tech, was the last one to fix it, it may be best to have Bill check the issue again since he is familiar with it or to ask Bill for suggestions. If the server always tends to break after Andrew makes changes to the server, it may be best to investigate the issue.

What

IT 담당자는 다른 담당자가 무엇을 수정했는지 조사하는게 유용할때가 많다. 만약 네트워크 커넥션 문제가 있었고 이더넷 장치를 이미 몇번 교체한 상황이라면 문제는 뭔가 다른 곳에 있다고 가정하는 것이 타당할 것이다. 또한, 만약 Samba가 문제를 일으키고 있다면 Samba 서비스의 재인스톨이 필요할 수도 있다(/usr/local/samba를 지우고 다음을 실행 pkg_add -r samba35).IT techs may find it helpful to keep track of what other techs are fixing. If there is a network connection issue and the Ethernet devices have already been replaced a few times, then it may be safe to assume the problem lies somewhere else. Also, if the reason techs are checking the server is because of reports of Samba issues, then the Samba services probably need to be completely reinstalled (remove /usr/local/samba and run pkg_add -r samba35).

Why

특정 소프트웨어나 하드웨어가 왜 업데이트되고 수리되었는지 등을 아는 것은 에러가 발생했을때 원인의 범위를 좁히는데 도움이 된다. 예를 들어, Bill이 NIS 서비스가 자꾸 lock되어서 재인스톨했다면, Casey는 다음날 다시 문제가 발생했을때, 이것을 다시 재인스톨해도 문제해결에 도움이 되지 않을 거라는걸 짐작할 수 있다. Knowing why a particular software or hardware is being updated, repaired, and so on, may help narrow down future issue origins when finding the source of an error. For illustration, if Bill reinstalled the NIS services because they repeatedly locked up, then Casey knows that another reinstallation will not fix the same issue that is occurring the next day.

When

에러가 발생한 시간이나 고쳐진 시간등은 다른 기술자들에게 도움이 될수 있다. 예를 들면, 서버가 매일 오전 5:00에 켜지고 syslogd가 오전 5:03에 죽는다면, 스타트업때 구동되는 어떤 서비스가 syslogd와 충돌할 확률이 높다. 그 말은, cron 테이블이나 /etc/rc* 스크립트를 가리키게 된다. (어떤 BSD 시스템은 다른 rc 시스템을 갖고 있다) 오전 5:03이나 그보다 약간 먼저 시작하는 어떤 프로세스가 크래시의 원인일 수 있다. 또 다른 예로, 최종 백업이 일주일 이상 전에 행해졌다면 페이퍼 로그를 본 기술자가 바로 백업을 시행하거나 다른 사람에게 일을 할당할 수도 있을 것이다. 이 타임 로그는 또한 관리자가 실제 원인을 (실수로) 배제하지 않도록 해줄수도 있다. 예를 들어 서버에 바이러스가 있다고 가정하자. 바이러스 스캐너가 원인불명의 이유로 바이러스를 탐지하지 못한다. 만약 기술자가 최근의 안티바이러스 업데이트가 3개월 이상 전이었다는걸 알게 되면 안티바이러스를 업데이트함으로써 그 바이러스를 탐지하고 제거할수 있게 될거라고 생각할 수 있다. 하지만 만약 기술자가 안티바이러스가 최신이라고 잘못된 가정을 하게 되면 다른데서 문제의 원인을 찾느라 시간낭비를 하게 될수도 있다. The time errors occur or when they were fixed can assist some techs. For example, if the server is always powered up at 5:00am and syslogd crashes at 5:03 am everyday, then most likely a service is starting up that conflicts with syslogd. This would then point to the cron tables, at tables, or /etc/rc* scripts (some BSD systems structure their rc system differently). Any process that starts at 5:03am or a little before may be causing the crash. As another example, if the last backup was performed a week earlier, then the tech looking over the paper log should perform a backup or assign the task to someone else. This time log would also keep administrators from ruling out causes that are indeed the cause. For instance, assume the server has a virus. The virus scanner is not finding the virus for some unknown reason. If the tech sees that the last antivirus update was three months ago, then the tech has a good assumption that updating the anti-virus definitions will enable the scanner to find and remove the virus. Otherwise, the tech will falsely assume the scanner is up-todate and waste precious time looking elsewhere for the fix for the problem.

Where

이 항목은 아주 유용한 정보는 아닐지도 모르지만, 어떤 경우에는 도움이 될 것이다. 이 항목은 "어디서 접속해서 서버를 수정했는가?"에 대한 대답이다. 서버는 SSH나 다른 방법을 통해서 리모트로 접속할수도 있고 로컬로도 접속할수 있다. 만약 특정 IP로 부터 서버가 공격받는다면, This may not be a very useful piece of information, but it may help in some instances. This would answer “from where was the server managed/fixed?” Servers can be fixed or repaired locally, remotely via secure shell (SSH), or other methods. If there are suspicions that the server is being hacked from a certain IP address, but it is later seen that the log states Andrew proof-read Bill’s /etc/rc.conf edits through a remote shell using the suspicious IP address, then we can rule out that address.

How

이 항목은 중요한 정보이다. 문제가 어떻게 수정되었고 분석되었는가? DNS 서버의 하드를 교체했는가 포맷했는가? 어떤 명령을 사용했는가? 이것들이 앞으로의 문제를 수정하는데 도움이 된다. 또한 다른 기술자들에게 지금까지 서버에 뭘 시도했는지 알려주는데 도움이 된다. 또한 로그를 남길때는 어느 서버이며 어떤 OS였는지를 포함하라. 각각의 서버별로 파일을 분리하는게 도움이 될 수도 있다. 해결할수 없었던 에러가 포함된 로그는 프린트해서 장래에 참조할수 있게 해두자. 로그를 볼수 없으면 문제를 해결하는 일이 훨씬 어려워진다. This is an important piece of information. How was the problem fixed and diagnosed? Was the DNS server’s hard-drive replaced or reformatted? What command was used? This helps future problems get repaired the right way (if it worked) or differently if the issue still persists. This also helps to inform other techs what has already been done and tried with the server. Also, when making such logs, include which server (if there are more than one) and which OS (if the server is set up for a dual-boot or virtual system). It may help to have a separate file for each server. A log containing errors for an unsolvable issue should be printed out for future reference just in case the server loses its files. It will be more difficult to fix an issue if the logs cannot be viewed.

Finding Problems

만약 유저들한테 파일이나 정보를 볼수 없다는 보고가 들어오면, 가능한 많은 이슈를 배제하는 것이 현명할 것이다. If users report that they cannot access files or information, then it may be wise to rule out as many issues as possible.

몇몇 워크스테이션에서 ping <SERVER_IP_ADDRESS> 라고 타이핑 해보자. 만약 ping이 실패하면, 문제는 네트워크 연결에 있다는 뜻이다. 더 정확한 위치를 찾고 싶으면 traceroute <SERVER_IP_ADDRESS> 라고 타이핑 해보자. 이 명령은 워크스테이션과 서버 사이의 각각의 위치에 대한 정보를 출력한다. 만약 커넥션이 라우터에서 멈추면, 라우터나 그 전후의 장비가 커넥션 에러의 원인일 확률이 높다. 만약 커넥션에 문제가 없다면 서버 위치까지 제대로 출력될 것이다. On some of the workstations, type ping <SERVER_IP_ADDRESS>. If the ping fails, then this proves the problem lies in the network connection. To help better pin-point the problem area, type traceroute <SERVER_IP_ADDRESS>. This command will print each location between the workstation and server. If the connection stops at a router, then the router or the devices before or after the router may be the cause of the connection error. If the connection is fine, the last stop should be the server.

 일단 네트워크가 괜찮다고 판명이 되면, 서버 자체에 문제가 있다는 뜻이다. 만약 접근이 안되는 파일이 FTP프로토콜을 통해서 접근하는 거였다면, 관리자는 커맨드에서 다음을 타이핑해서 FTP 프로세스가 잘 되고 있는지 확인할 수 있을 것이다. Once it has been proven that the network is fine, it may mean the server itself is the source of the problem. If the inaccessible files are accessed via FTP, then the administrator may want to make sure the FTP process is still running. In a command-line, type:

pgrep ftpd

FTP데몬이 잘 실행되고 있다면, pid가 결과로 출력될 것이다. 그러면, 다음을 이용해서 데몬을 재시작할 수도 있을 것이다. If the FTP daemon is running, the administrator should get a number (the PID) as the output. Then, the tech may want to restart the daemon using the command below.

service ftpd restart

아무런 출력도 없다면, FTP 프로세스가 어떤 이유로 종료된 것이다. 실행하려면 다음을 타이핑하자. If no output is received, then the FTP process closed for some reason. To turn it back on, type:

service ftpd start

FTP서버가 동작할 것이다. 이제 어떤 문제로 FTP데몬이 종료되었는지 조사해볼 차례다. 먼저 로그를 확인하자. ftpd의 로그파일은 /var/logs/ftpd 이다. 이것은 그냥 평범한 텍스트 파일이다. 커맨드라인에서 다양한 방법으로 내용를 볼수 있는데, 가장 좋은 방법은 less 명령을 이용해서 위아래로 스크롤하면서 보는 것이다. 가장 최근의 10줄만 보고 싶다면 tail 명령을 사용하라. The FTP server should be back online. Now would be a good time to investigate what caused the FTP daemon to close. To do this, check the logs. The log file for ftpd is /var/logs/ftpd. This is a plain text file. In a command-line, it can be read in one of many ways. The best way is to use the less command which allows the user to scroll up and down. To see the last ten lines, use the tail command.

less /var/logs/ftpd

tail -10 /var/logs/ftpd

만약 서버가 시작될때 FTP 데몬이 구동되지 않는다면, 관리자는 /etc/rc.conf 를 살펴봐야 할 것이고, 다음의 줄이 파일에 들어있는지 확실히 해야 한다. ftpd_enable=”YES”. 만약 없다면, 그게 데몬이 구동되지 않는 이유이다. 이래도 시작이 되지 않으면 권한 파일들을 체크해보자. 관리자는 유저 각각에 대해서 서비스를 허용하거나 허용하지 않을 수 있다. /etc/ftpusers  파일은 FTP 데몬이나 서비스에 유저들이 접근하지 못하도록 한다. 만약 대부분이나 모든 유저가 여기에 나열되어 있다면, 왜 아무도 파일에 접근하지 못했는지가 설명된다. 모든 사람에게 FTP 서비스가 접근 가능하게 하려면 다음을 타이핑하라. (주의: 그전에 ftpusers 파일을 백업하도록 하자) If the FTP daemon is not starting when the server turns on, then the administrator needs to check /etc/rc.conf and make sure this line is in the configuration file ftpd_enable=”YES”. If not, then that is why the daemon never started; no script told it to start. If for some reason the above still does not help, check some of the permission files. Administrators can set up which users are allowed or not allowed to access certain services. The file /etc/ftpusers lists users that are not permitted to access any service or file provided by the FTP daemon. If many or all users are listed here, then that would explain why no one can access the files. To allow everyone to use the FTP services, type: (NOTE: Remember to keep a backup of the ftpusers file by copying it to the root’s home folder or some other designated backup location.)

echo “” > /etc/ftpusers

이렇게 하면 목록이 지워지고 모든 사람이 FTP 서버를 사용할 수 있게 된다. 만약 FTP서버에 접근해서는 안되는 유저가 있다면, 목록을 작성해서 적당한 텍스트 에디터로 ftpusers 파일에 추가하자. 많은 사람들이 Vi나 Emacs 에디터를 사용한다. BSD 서버가 모든 네트워크 장치를 인식하고 있는지 확인하려면 ifconfig 를 타이핑하고 모든 이더넷 포트와 무선 장치가 나열되어 있는지 확인하자. 만약 빠져있는 네트워크 장치가 있다면, OS에 해당 드라이버가 없거나 그 장치가 물리적으로 고장난 경우이다. This will erase the list and allow all users to use the FTP server. If there are some users that should not access the FTP portion of the server, make a list of the users and re-add them to the list using a preferred text editor. Many users use Vi or Emacs in the command-line. To make sure the BSD server is recognizing all of its network devices, type ifconfig and make sure all of the Ethernet ports and wireless devices are listed. If any of the network devices are missing, then the operating system is missing a driver or that device is physically broken.

Checking the File System

만약 파일시스템이 잘못되면, 데이터가 손상을 입고 손실될 것이다. 백업으로부터 간단히 복구하는건 할수가 없다. 파일시스템을 경치나 정원이라고 생각해보자. 만약 토양이 거칠어지고 식물한테 좋지 않게 되면, 정원사가 다시 토양을 건강하게 만들지 않고 식물을 심을수는 없다. 파일시스템도 마찬가지다. 먼저 파일시스템의 에러를 체크하려면 fsck 를 사용하자. If the filesystem goes bad, then the contained data will be damaged and lost. Performing a simple restoration from a backup cannot be done. Look at the filesystem as a landscape or garden. If the soil becomes rocky and bad for the plants, a gardener cannot replant a new plant without making the soil healthy. The same goes for a filesystem. To check a filesystem for errors, use fsck.

fsck -F ufs

이 명령은 UFS 파일시스템의 에러를 체크한다. 만약 에러가 발견되면, 즉시 백업을 만들고나서 하드를 포맷하거나 교체하는것이 현명할 것이다. 명심하라, fsck 로 파일시스템을 체크할때는 파일시스템 타입을 명시하라. 그렇지 않으면 체크가 제대로 안될수가 있다. UFS 파일시스템을 체크하면서 ZFS이길 기대한다든지. The command will check the UFS filesystem for errors. If an error is found, it may be wise to make an immediate backup of important savable files and then reformat or replace the hard-drive. Remember, when checking a filesystem using fsck, specify the filesystem type to be inspected. Otherwise, the check will not work properly if fsck is checking a UFS filesystem while expecting it to to be ZFS.

일반적으로, 잘못된 파일시스템을 복구하거나 방지하는 가장 좋은 방법은 RAID 시스템을 사용하는 것이다. 그러면 손상된 저장장치를 제거하고 새로운 장치로 교체할 수 있다. FreeBSD는 parity 시스템을 이용해서 데이터를 다시 만들 것이다. Generally, the best way to prevent or ease the repair of bad filesystems is to use a RAID system with parity. Then, the damaged storage unit can be removed and replaced with a new or repaired unit. FreeBSD will then recreate the data using the parity system.

Problems with Finding Problems

로그는 많은 문제를 해결할때 유용하게 쓰인다. 하지만, 항상 로그가 가능한것은 아니다. 예를 들어, 서버가 잠기면 syslogd(로그 프로세스)는 로그를 쓸 수가 없을 것이다. 그렇게 되면 문제가 생긴 후에 로그를 봐도 아무것도 확인할 수가 없다. 만약 악의적인 프로그램이 하드를 지우면 로그를 볼수가 없다. 또한 하드나 파일시스템이 망가지면 마찬가지로 로그를 볼수가 없다. Logs are very useful in solving many problems. However, logs may not always be there to help. For instance, if the server locks up, syslogd (the process that makes logs) will not be able to write the logs. Then when the logs are viewed, nothing will be seen for the sequence of events that led up to the disaster. If malware erases the hard-drive, no logs will be seen. Also, if the hard-drive or filesystem is corrupted, then no logs will be seen either.

GUI

FreeBSD의 기본 설치본은 GUI가 부족한 편이다. 서버에 GUI를 설치할때 관리자는 몇가지 고려해야할 사항이 있다. GUI는 서버를 관리하고 보수하는데 편리를 제공하지만, 또한 회사의 다른 누군가가 망치는데도 편리함을 제공할 수 있다. 또한 기존의 프로그램과 충돌할 가능성이 있는 프로그램이 늘어난다는 것을 의미한다. 만약 어떤 이유로 서버에 GUI가 설치되어야만 한다면 최소한도로 하는것이 바람직하다. KDE, GNOME, Mate, Cinnamon, Unity등은 데스크탑 환경의 서버에 적합한 선택은 아니다. Afterstep, Ratpoison, Enlightenment, Blackbox, Fluxbox등이 적당하다. XFCE나 LXDE도 적당할수 있다. 하지만, 큰 인터페이스는 설치하지 않는 것이 최선이다. The default FreeBSD installation lacks a graphical user interface (GUI). For a server, the administrator must take some details into consideration before installing a GUI. A GUI would make a system easier to repair and maintain. However, this would make it easier for someone within the company to ruin the server and its data. Also, there would be more software that could cause a conflict with existing programs. If for some reason a GUI must be installed on a server, it is best to install a graphical user interface with a small footprint (uses very little resources). Clearly, KDE, GNOME, Mate, Cinnamon, and Unity are not good choices for desktop environments on a server. Some graphical interfaces suitable for a server include Afterstep, Ratpoison, Enlightenment, Blackbox, Fluxbox, and other similar interfaces. XFCE or LXDE may work well on a server, but it may be best not to install a desktop interface that large on a server.

NOTE

이 글을 쓰는 시점에서 BSD 배포자들은 최근에 GUI를 사용하기 시작했다. 하지만 그것들은 다운받고, 컴파일하고, 설치되어야 한다. BSD 시스템과 어떤 GUI는 충돌할 수도 있다. 꼭 필요한 경우가 아니면 설치하지 않는 편이 좋다. At the time of writing, BSD distros have recently started using graphical user interfaces. However, they must be downloaded, compiled, and installed. BSD systems may have problems with some graphical user interfaces. It is best to avoid desktop interfaces unless it is absolutely necessary.

Quick Fixes

만일 서버가 부팅될때 구동되지 않는 데몬이 발견됐다면, 물론, /etc/rc.conf 파일안에 써주어야 한다. 하지만 Vi나 Emacs를 좋아하지 않는 관리자도 있을수 있고 적당한 텍스트 편집기를 설치할 시간적인 여유가 없을수도 있다. 그런 경우에 간단히 다음의 명령을 사용해서 추가할 수가 있다. (역자주: >>는 파일 끝에 첨부(append)하는 명령. >는 그 파일을 없애고 새로 만드므로 유의) If a server daemon is found to not run on boot-up, of course, it needs to be added to /etc/rc.conf. However, some administrators may not like Vi or Emacs and do not have time to install a preferred text editor. Well, there is a quick fix. To quickly and easily make a daemon start when the system loads up, type the following command:

echo “apache22_enable=\”YES\”” >> /etc/rc.conf

만약 /etc/rc.conf 파일 안의 항목중 오타가 난 부분이 있다면, 그것도 재빨리 수정이 가능하다. 위의 명령중 apachy22_enabled=”YES”  부분에서 오타가 있다고 가정해보자. 아래의 명령으로 수정할 수 있다. If an entry in /etc/rc.conf is spelled wrong, it can swiftly be corrected. Assume the above command added the misspelled line apachy22_enabled=”YES”. Type the below command to make the correction.

cat /etc/rc.conf | sed -i -e ‘s|apachy22|apache22|’

이 명령은 파일내에서 찾아서바꾸기 명령을 수행한다. (변경이 바로 적용된다) 정규식이 사용되지 않았으므로 일치하는 정확한 문자열만 변경된다.

 (역자주: sed -i -e ‘s|블라블라’ /etc/rc.conf 라고 해야 원하는 기능이 수행되는게 아닌가 싶다. 본문은 약간 틀린거 같음)

관리자가 정규식에 매우 능숙하고 설정파일의 전체에 대해서 완전히 잘알고 있는게 아니라면 그런 중요한 시스템 파일에 대해서 정규식을 사용해서는 안된다. 조금만 부주의하면 어떤게 어떻게 바뀔지 알수가 없어서 서버 문제를 일으킬수가 있고 문제를 찾는데 매우 많은 시간을 소모하게 될 확률이 높다. The above command will perform a find-and-replace in file (changes take place instantly). No regex (wildcards) is used, so the exact string will be matched and changed. Unless the administrator is very skilled with regex and has thoroughly read the configuration file, no one should use regex in such an important system file. Otherwise, settings that should be left alone will get changed if the tech is not careful. This can cause the server problems, and the administrator will have to spend time finding and fixing the problem.

Updating

업데이트는 서버에 좋을수도 있고 나쁠수도 있다. 업데이트를 해서 버그수정, 새로운기능, 더 효율적인 알고리즘, 그리고 적은 리소스 사용 등의 이득을 얻어서 서버의 성능을 향살 시킬수도 있다. 하지만 업데이트에는 개발자들이 미처 파악하지 못한 버그가 있을수도 있다. 이 버그는 별거 아닐수도, 서버를 다운시킬수도 있다. 일반적으로 '테스트 서버'를 두는게 바람직하다. 테스트서버는 메인서버와 완전히 똑같이 구성하지만, 최신 업데이트가 반영되어 있다. 서버 관리자들은 새로운 설정을 테스트하거나 업데이트와 새로운 소프트웨어가 잘 동작하는지 확인하기 위해서 테스트 서버들을 사용할수 있다. 하지만 테스팅 시스템을 갖추기에는 자금이 부족하다면, 일단 인터넷을 꾸준히 확인해서 버그를 체크하는것이 도움이 될것이다. 또는 가상 시스템 소프트웨어를 설치해서 똑같은 OS를 설치하고 테스트서버로 활용하는 것도 방법이다. 완벽한 해결책은 아니지만 BSD 배포본은 가상머신에서도 잘 동작하므로 나름의 해결은 될것이다. 시스템을 업데이트 하려면 다음을 타이핑하자. Updates can be good for a server, but they can also be harmful. Updates may offer bug fixes, new abilities, more efficient algorithms, and less resource usage. So, updates may help a server’s performance. However, an update may contain a bug that the developers did not find. This bug may be minor or it could cause the system to be down for a while. Generally, it is best to have a “testing server”. This server would be exactly like the main server, but the testing server has the latest updates. Server administrators would use such a server to test out new configuration settings on services and make sure that updates and new software work properly. However, some companies may not have the funds to have this testing system. It may also help to watch the Internet for reports on major bugs. An alternative to a testing server is to have a virtual testing server. Install visualization software on a computer/operating-system of choice. Then, install BSD and test the newest updates and such on this system. This will not be a perfect test because the hardware is not the same as the server. BSD distros run very well in virtual machines, so no problem should exist here. When updating the system, type:

freebsd-update fetch; freebsd-update install

가능한 소프트웨어의 목록을 보여주고 업데이트할 것이다. 물론 루트권한이 있어야 한다. This will update the list of available software and then update the software. You must be root to apply such updates.

Log Space

반복된 얘기지만 로그는 /var/ 디렉토리 아래의 많은 공간을 소모한다. 디스트 사용량을 줄이려면 로그를 지우면 된다. 여러가지 방법으로 지울수가 있는데, 만약 로그를 저장해야 한다면 USB드라이브를 가져다가 로그를 옮기자. 혹은 logrotate 명령어를 사용할수도 있다. 이 유틸리티를 사용하면 오래된 로그를 압축하고 새로운 로그파일이 시작되게 할수 있다. 하나의 로그파일을 비우려면 이렇게 하자. Over time, logs will consume a lot of space in /var/. To reduce the disk usage, remove the logs. This can be done in a number of ways. If your company requires the logs be stored, then get a USB hard-drive and move the logs to the drive. On a command-line, you could also run the logrotate command. This utility will compress old or large logs and give the system new, empty files to start writing more logs. To empty a single log, type a command like this:

echo “” > /var/logs/SOME_LOG

이렇게 하면 로그파일이 그냥 지워진다. 지우기전에 최근의 로그에서 주목할만한 점이 있는지 확인해두자. This will empty the log and keep the file without making a copy or compressing the file. Before removing logs, check for any recent activity that should be noted.

Security

바이러스나 해커들은 밖에서부터 시스템을 깨려고 하지만, 서버 가까이에 있는 사람이 해를 끼칠수도 있다. 서버는 소프트웨어나 네트워크 레벨에서 보호되어야 하지만 물리적으로도 보호되어야 한다. 서버와 네트워크 시스템은 여러가지 다양한 레벨에서 보호될 수 있다. Viruses and hackers may try to destroy the system from the outside, or people physically near the server may cause harm. The server must be protected physically and at the software and network level. The server and network system can be secured at various levels in numerous ways.

물리적으로 보호하는데는 (자금에 여유가 있다면) 서버룸을 잠가두고 보안카메라를 설치하는 것이 최선이다. 중요한 서버가 있는 큰 회사는 경비를 고용하는것도 고려해볼만하다. 물리적으로 서버를 보호하는 많은 방법이 있지만, 그것들은 여기서 설명할 내용은 아니다. For physical security, it is best to keep the server room locked and (if funding is sufficient) set up security cameras. Large companies with very important servers may want to consider hiring security guards. There are many other ways to secure the server physically, but that is beyond the scope of this magazine.

만약 로컬 컴퓨터가 서버로 통신하는데에 와이파이를 사용한다면 와이파이는 암호화된 통신을 사용해야 하고 MAC어드레스 필터링이 가능해야 한다. 만일 /etc/rc* 시스템에 스크립트를 추가해야 한다면, 믿을수 있는 개발자가 개발한 것들만 사용하도록 하자. rc 유틸리티는 부팅시나 셧다운 그리고 다른 중요한 이벤트가 발생했을때 시작되므로 만일 여기에 바이러스가 심어지면 삭제하기 어려울 뿐더러 큰 피해를 입을 수도 있다. If local computers communicate with the server(s) via Wifi, the Wifi should use an encrypted signal and (if supported by the wifi router) enable MAC address filtering. If a script needs to be added to the /etc/rc* system, thoroughly review the script and only place executables here from trusted developers. The rc utility starts scripts at boot time, at shutdown, and during other important events. If a virus gets installed here, it may be difficult to remove it and it can cause a lot of damage.

누가 로그인했는지 보려면 last 명령을 사용한다. 이 명령은 출력이 길수 있으므로 less 를 사용해서 파이핑하는게 좋을것이다. To see who has logged in, use the last command. This command may produce a long list of entries, so it may be better to pipe the output into less.

last | less

이 명령은 또한 시스템이 언제 꺼졌는지 보여주므로 참고할만하다. 하지만 전원이 차단된 경우는 보여주지 못한다. This command above will also show when the system is powered off. This can be helpful when figuring out when the system was last powered off. If the system loses power from the power supply, that will not be seen in this log.

소홀히하면 안될 가장 중요한 보안 이슈는 안티바이러스 프로그램이다. 유명한 오픈소스 프로그램으로는 ClamAV가 있다. 안티바이러스 프로그램은 메모리를 많이 쓰기도 한다. 스캐닝 과정에서 CPU 사용량이 늘수도 있다. 가능하면 스캐닝 시간이나 업데이트는 업무시간 후에 이루어지도록 하자. 그리고 그날의 업무를 종료하면서 아래의 Listing 1 같은 스크립트를 실행하도록 하자. The number one part of security that should not be neglected is anti-virus software. A popular open-source scanner is ClamAV. Beware though, anti-virus software can use up a lot of memory. While scanning, they can consume a portion of the CPU resources. Be sure to allow the virus scanner to scan the system and get definition updates after the company’s closing time or during maintenance time. A script can be made to update the definitions and scan the system. Before leaving for the day, execute a script with contents like in Listing 1 below (remember to use root privileges). Techs may want to read the man pages for ClamAV and add the parameters that will best suit the system’s needs (Listing 1).

Listing 1. Virus Scanner Script

!#/bin/sh

#Virus Scanner Script

sudo freshclam #Update definitions

sudo clamav 2>1 /root/scan_results.txt

shutdown -p now

Backups

아무리 잘 유지되어도 때때로 서버는 다운되거나 데이터가 손실될 수 있다. 영구 손실을 방지하기 위해서는 데이터 저장 장치를 백업해야 한다. 만일 서버에 10테라바이트의 데이터가 있다면 같거나 더 많은 사이즈의 백업장치가 필요하다. FreeBSD에서 USB장치를 지원하므로 쉽게 백업이 가능하다. Sometimes, the server may crash or lose data no matter how well it is maintained. To prevent permanent loss of data, the storage units should be backed up. Administrators will need extra storage devices. If the server has ten terabytes of data, then the backup storage should be the same amount or more. With the stability of USB devices and FreeBSD’s excellent support for such hardware, this makes backups easier.

USB에 외장하드를 연결하고 적당한 백업 유틸리티를 사용하자. 백업이 끝나면 unmount 하고 백업 USB 장치를 뽑은후 건조하고 안전한 장소에 보관한다. 방화금고에 보관하는것도 최선일 것이다. 그리하면 건물에 불이 나더라도 데이터는 안전하다. Clonezilla나 Ghost등이 사용가능하다. Plug in a USB external hard-drive. Use your preferred backup utility. Once finished, unmount and unplug the backup USB device and store it in a secure, dry, safe place. It may be best to store the drive in a fire-proof safe. Then, if the building or storage room catches on fire, the company will still have the data from the last backup. Clonezilla is a live Linux disc that can be used like Ghost to make an image of the hard-drive to an external hard-drive.

때때로 /etc/, /home/, /root/ 등의 폴더와 새로 인스톨해서는 복구가 불가능한 다른 중요한 정보가 담긴 폴더만 백업하는게 최선일 때도 있다. 인스톨후에 설치한 소프트웨어나 저장장치등의 목록을 잘 보관하자. 그렇게 하면 어떠한 이유로 시스템을 재설치하게되면 기술자가 BSD 배포폰을 설치한 후 필요한 소프트웨어 등을 설치할 수 있다. For some, it may be best to only back up /etc/, /home/, /root/, and any other folders that may store important files that are needed that cannot be recovered through a fresh install. Keep a list or a storage device with all of the software installed after the original/last fresh install. Also, keep a copy of the installation disc of the preferred BSD operating system. Then, if the system must be reinstalled, the tech can install the BSD distro, install the applications, and then put the data and files back. Remember, when doing a fresh install, to reformat the hard-drive(s).

파일이스템이 포맷된지 오래되어서 파일시스템이 손상을 입어서 시스템이 크래시 될수도 있다. 시스템이 완전히 손상을 입었으면 대부분의 BSD 설치 디스크에 있는 "rescue mode"를 사용하자. 이 복구 유틸리티로 시스템이나 데이터를 복구할 수도 있을것이다. The filesystem may not have been formatted in a long time and the system crash may have been caused by, or caused, corruption of the filesystem. If the system is completely ruined, use the “rescue mode” that is on most BSD installation discs. This recovery utility may help save the system and data. When the server boots from the disc, read the menu and press the button needed to initiate rescue mode.

회사의 DB나 자료에 대해서 항상 별도의 백업을 준비하자. 해커나 알수없는 등의 이유로 데이터가 손상되면 이 백업이 매우 유용할 것이다. 회사의 자료를 보존하는것이 서버기계를 보존하는 것보다 더 중요할수도 있다. 그러므로 자료를 잘 보존하고 백업을 자주 하도록 하자. 시스템이 빠르다면 점심시간등의 휴식시간에 외부 장치로 백업하는 스크립트를 작성하는 것도 고려해볼만하다. Always make a second separate backup of the company’s databases and data. If the company’s data gets ruined from a hacker or for whatever reason, this backup will be helpful. Saving the company’s data may be more important than the server itself, so keep this data safe and make back-ups often. If the system is fast enough, make a script that will copy the data to an external or remote storage device during a lunch break or some other large break.

Important rules

서버를 관리하는데에 따라야할 몇가지 중요한 규칙이 있다. Here are some very important rules to follow when managing a server.

KISS

필요이상으로 복잡하거나 긴 스크립트를 사용하지 마라. 스크립트나 명령을 복잡하게 만드는 것은 실수를 하거나 시스템을 망칠 확률을 높인다. 스크립트가 루트 권한으로 실행될 경우에는 더욱 그렇다. 예를 들어 시스팀에 SCSI 드라이버를 업데이트해야할 필요가 있을때는 가능하면 그 드라이버 하나만 받아서 업데이트하라. 어플리케이션을 설치할때도 마찬가지 규칙이 적용되는데, 굳이 필요한 게 아니면 설치하지 마라. 종종 부팅시간을 느려지게 만들수도 있다. Keep It Simple Stupid. Do not write overly complicated scripts or use long strings of commands when a shorter or more simple script/command can be used. Making scripts/commands more complicated than they really should be can increase the chances that a coding mistake will be overlooked and do something to ruin the BSD system, especially if the script is executed in Root’s account. As another example, if a system needs to be updated only for the purpose of getting a new SCSI driver, then download and install that single driver (if possible) instead of updating the whole system. This rule also applies to deciding whether to install an application. If it is not needed, do not install it. Some installed programs can slow down the boot-up time.

NOTE

위의 설명은 작업을 할때 대충 하라는게 아니다. 작업은 완벽하고 정확하게 되어야 하지만, 오버하지 말라는 것. The above tip does not mean performing a task the lazy way. Perform tasks completely and correctly – just do not overdo it.

루트권한을 남용하지 마라. 만일 보통의 계정으로도 될수 있는 작업이라면 그렇게 하라. 어쩔수 없이 꼭 필요한 경우에만 루트권한을 사용하라. 조금이라도 실수로 시스템을 망칠 확률을 줄여준다. Do not use the name Root in vain – If a task can be completed on the server (or a workstation) using a regular account, do so. Only use Root when absolutely necessary, or else one accident can cause devastation to the server and network.

당신이 사용하는 BSD 배포본에 대해서 숙지하라. 보통 파일과 어플리케이션의 위치들은 배포본마다 같지만, 가끔은 다를 수도 있고 가끔은 쉘 명령을 지원하지 않을때도 있다. rm이나 mv같은 명령을 수행하기 전에 처리하려는 파일과 디렉토리가 일반적인 위치에 있는지 확인하도록 하자. 잘못된 디렉토리에서 작업을 하게되면 혼란을 야기할 수 있다. 고장나지 않았으면 고치지 마라. 업그레이드가 굳이 필요하지 않으면 하지마라. 고칠 필요가 없는 시스템에 대해서 그런 작업을 하는 것은 시스템의 낭비일수도 있다. 잘 돌아가던 시스템이 굳이 필요없는 업데이트를 한 후에 충돌이 날 수도 있다. Know your BSD distros – Overall, BSD distributions are the same as far as file and application locations. However, some may be different or may not support some shell commands. Before running certain commands (like rm and mv), make sure the files and directories you plan to manipulate exist in the location you are normally familiar with. Performing an action in the wrong directory can cause confusion when the system does not perform the actions it is assumed to complete. If it is not broken, do not fix it – If an upgrade is not needed, then do not do it. Updating, editing, and replacing hardware can cause issues. It would be a waste of resources to do so on a system that does not need it when the system later has issues from an unneeded “fix”. For illustration, assume Bill upgrades the BSD operating system without a specific need. Before, everything ran well but now, there is some system conflict with the new system. The conflict could have been avoided if Bill had not upgraded the system. When a system needs a repair or update, then the potential risks and problems that may result from upgrading and repairing will be more worthwhile.

Certification Prep

BSD나 LPI 자격을 취득하려고 하는 사람이 있다면 서버의 모든 데몬과 설정 파일에 대해서 이해를 하고 있어야 한다. 시스템 백업의 중요성과 어떤 식으로 백업을 할지 이해하고 있어야 한다. 중요한 시스템과 서버로그의 위치를 알고 있는것 또한 도움이 될 것이다. 이런 자격을 획득하는 것은 더 나은 직업을 얻는데 도움이 될것이다. 그리고 그러한 자격을 공부하는 것은 또한 서버관리에 필요한 지식을 습득하는 데에도 도움이 될 것이다. For those of you wanting to get your BSD and/or LPI certifications, you must understand all of the server daemons and configuration files. You must thoroughly understand the great importance of system backups and how they are performed. Learning the location of important system and server logs will also help those wanting to earn such certifications. Obtaining these certifications will help admins get better jobs. Studying for such certifications will also give admins the knowledge they must have to sufficiently manage servers.

---

Devyn Collier Johnson

Devyn Collier Johnson(DevynCJohnson@Gmail.com)은 Linux.org에 많은 글을 기고해왔고, Full Circle Magazine에 Clementine에 관한 글을 썼으며 McGraw Hill의 책 Epub: From the Ground Up의 기술 편집을 맡았다. Linux/Unix 시스템에 관해 많은 경험과 자격을 갖고 있다. 저자에 관한 더 많은 정보는 https://launchpad.net/~devyncjohnson-d 여기서 얻을 수 있다.

Devyn Collier Johnson DevynCJohnson@Gmail.com has written many articles for Linux.org, wrote one article for the Full Circle Magazine on Clementine, and was the technical editor for McGraw Hill’s book Epub: From the Ground Up. The author has some experience and certifications in Linux/Unix systems. More about the author can be found here: https://launchpad.net/~devyncjohnson-d

문의사항이 있으면 망설이지말고 이메일이나 런치패드, Linux.org, Google+ 등으로 연락하기 바란다. Feel free to contact the author via email, Launchpad, Linux.org, or Google+ for questions or article requests.

---

매달 무료로 발행되는 FreeBSD Magazine 이라는 잡지가 있는데(http://bsdmag.org/), 영문이라 제대로 읽어보지는 못하고 나올때마다 스윽 훑어보기만 했었다. 그래던 차에 그래도 달마다 한 꼭지정도는 제대로 읽어보자는 마음이 들어서 이런 식으로 발번역을해서 올릴 예정. 얼마나 오래갈지는 모르지만... 그리고, 번역실력이 허접한 관계로 원문도 삭제하지 않고 그대로 표기하려고 한다.