Indescribable Place
[2013.10] Migrating from Linux to FreeBSD 본문
Migrating from
Linux to FreeBSD
이 글에서는 내가 서버를 데비안 리눅스에서 FreeBSD로 바꾸면서 배웠던 경험을 공유하고자 한다. 일반적인 문제와, 시스템을 바꿀때 고려해야할 사항, 그리고 왜 내가 이런 '모험'을 하게 되었는지를 설명할 것이다. In the following article, I will share with you what I learned when I have converted my servers from Debian to FreeBSD. I will explain the common problems you could have, what you should consider before changing the system and what motivated me for this “adventure”.
알게 될 것... What you will learn…
- 데비안 리눅스와 FreeBSD사이의 호환성 문제. Compatibility problems between Debian and FreeBSD.
알고 있어야 하는 것들... What you should know…
- 시스템 관리 기초 System administration basis
- 약간의 개발 관련 지식 Some development knowledge.
이 글을 시작하기에 앞서서 이해를 돕기 위해 먼저 배경 설명을 하려고 한다. 나는 작은 회사의 시스템 관리자이다. 나는 매일 두명의 개발자와 함께 서버에 접속해서 일을 한다. 개발자들의 OS에 관한 지식은 꽤 훌륭하다. 우리 회사의 큰 고객에게 제공되던 서버 전체를 새롭게 바꿔야할 필요가 생겼다.
To begin this article, I need to set up the background, so that you can fully understand what follows. I am a system administrator in a small company. I work every day with two developers using my servers. Their knowledge about operating systems is quite good. I had to renew a whole set of servers, used for a high availability service for our biggest client.
지금까지는 모든게 데비안 리눅스에서 돌아갔지만, 나는 그동안 계속 동료들에게 FreeBSD에 대해서 얘기해 왔고 이번에 새로운 서버를 FreeBSD로 변경하는게 어떨지 제안했다! So far, everything is running with Debian GNU/Linux, but I am always talking about FreeBSD to my colleagues. This time, I proposed switching to FreeBSD for our new servers!
이 글은 결정과 선택 그리고 '철학'에 관한 글이다. 어떻게 데비안 리눅스에서 FreeBSD로 변경하는 가를 설명하는 글이 아니다. 이 글은 어떤걸 사용할지 결정하는데에 도움을 줄수는 있지만 별다른 명령이나 스크립트를 설명하지는 않는다. What follows is about decisions, choices and “philosophy”. This article is not a how-to switch from Debian to FreeBSD. It may help you decide what to use; it may help you find answers; but you won’t find any commands or scripts.
가능한 중립적인 입장에서 쓰려고 노력했다. 내 선택에 몇가지 실수가 있을지도 모른다. 이런 것들에 대해서 공유하고픈 생각이 있다면 메일을 보내주기 바란다. I am trying to write this article while being as neutral as possible. I may make some mistakes in my choices and reasons, but they are mine. You can send me an email if you want to share a thought or if you think that I said something wrong.
Why change?
OS를 바꾸려면 명령어를 공부하는 것을 포함해서 많은 추가적인 일거리가 생길것이 뻔하기 때문에, 나는 그럴듯한 이유가 필요하다는 것을 알고 있었다. I knew that I would need a good reason to switch operating systems, because this will certainly create extra work with regard to compatibility, finding packages, and learning the operations of the operating system.
그래서 나는 장단점 목록을 만들어서 왜 내가 지난 몇년간 FreeBSD를 쓰고싶어 했는지를 설명하려고 했다. 그리고 가능한 정직하게 그 목록을 작성하려고 노력했다. That is why I made a Pros/Cons list to explain why I would like to use FreeBSD for the next few years. I tried to be as honest as possible, not trying to sway you to FreeBSD with only pros, while Linux would have had only cons. Linux has been working well, so why change it?
장단점 목록: Pros and Cons list:
• FreeBSD와 리눅스는 기본적으로 같게 동작한다. 그리고 우리가 보통 오픈소스 프로그램을 사용하기 때문에 호환성 문제도 접하지 않을 것이다. 하지만 저작권이 있는 프로그램을 사용한다면 잘되지 않을 수도 있다는 것을 알아야 한다. FreeBSD and Linux are equivalents and they basically perform the same. As we are using open-source software only, we should not encounter compatibility problems, but we must be aware that if we need to use proprietary tools, it may not work.
• FreeBSD로 바꾸는 것은 쉽지 않다. 소스코드의 일부를 바꿔야 할지도 모르고 사람들에게 새로운 명령이나 특징을 가르쳐야 할수도 있다. 어떤 명령은 다를수도 있다. Switching to FreeBSD may not be that easy. We may have to change some of our source code and may need to teach people new operations or features. Some user commands may be different.
• FreeBSD는 유닉스 철학을 유지하는 유닉스 시스템이다. FreeBSD is a Unix system, keeping Unix philosophy.
새로운 버전이 나오더라도 시스템 관리는 바뀌지 않는다. 지난 몇년동안 리눅스는 진화했고 유닉스 철학에서 멀어지고 있다. 새로운 버전이 나올때마다 많은 요소가 바뀌고 많은 서비스가 포함된다. 미래에는 더욱 복잡해질지도 모르겠다는 느낌을 받는다. System administration does not change with every new release. Linux, over the last few years, has been evolving and moving away from the Unix philosophy. Every new release changes many components, or includes more services and applications. I have the feeling that things may become more complicated in the future.
• FreeBSD는 고가용성의 서비스를 호스트당 단 두줄의 설정만으로 제공할 수 있다. 우리는 heartbeat/pacemaker/corosync와 씨름할 필요가 없다. FreeBSD is able to provide high-availability service, with two lines of config per host. We do not have to struggle with heartbeat/pacemaker/corosync.
• FreeBSD는 포트 시스템을 사용한다. 컴파일에 시간이 걸리지만, Poudriere 소프트웨어를 사용하면 집중될것이다. FreeBSD is using a port tree. Compilation takes time, but it will be centralized with the software Poudriere.
우리는 사용하고자 하는 프로그램의 버전이나 컴파일 태그를 선택할수가 있다. We will be able to choose compilation flags, the versions of postgresql and PHP that we want to use. We have had surprises with Debian in the past: old PostgreSQL, PHP missing some features.
• FreeBSD는 하나의 완전한 패키지로 개발되며 핸드북이나 매뉴얼등이 잘 되어 있어서 좋은 참고가 될수있다. FreeBSD is developed as a complete package and is coherent, with man pages that are up-to-date. The FreeBSD handbook is a good source of documentation and best practices also.
보면 알겠지만 이 목록은 성능이나 테크니컬한 차이 보다는 철학이나 개념등을 얘기하고 있다. 우리 회사에서는 심플한걸 선호하는 편인데 우리는 리눅스가 복잡한 방향으로 가고 있다고 느꼈다. As you see, my list is mostly talking about philosophy concerns rather than performance or technical differences. In my company, we like to keep things simple, and we have the feeling that Linux is going in the opposite direction.
The deal
상사가 FreeBSD로 옮기는 의견을 수락했다. 가능한 최소한의 수정만 하기로 합의했는데, 예를 들면 모든 Bash 스크립트를 수정할 시간이 없으므로 symlink나 alias를 활용해서 동작하도록 하려고 한다. My boss accepted the idea that we move to FreeBSD. We agreed that this should work with as few modifications as possible of scripts / software / makefiles / users habits, etc. For example, I do not have time to fix every Bash script, but adding a symlink could fix the problem
The migration: from Debian to FreeBSD
이 파트에서는 내가 직면했던 이슈들과 어떻게 그것들을 해결했는지를 공유한다. In this part, I shall share some issues that I had, and how I fixed them.
The Shell
시스템의 가장 중요한 부분은 쉘이다. FreeBSD는 기본적으로 그다지 친숙하지 않은, 히스토리나 컬러가 지원이 안되는 csh을 사용한다. 유저들에게 csh을 사용하라고 강요할수는 없는 노릇이라 bash을 설치하고 설정파일을 가져오기로 했다. An important part of the system is the shell. By default, FreeBSD uses the unfriendly csh, which does not keep history and no color. I will not be able to advocate FreeBSD to my users with just csh. I decided to install bash as we are used to and importing our bash config files.
Where are my commands?
OS를 변경한다면 변경된 OS에 대해서 공부할 필요가 있다는 사실을 사람들이 이해할거라고 생각하지만, 그렇지 않다. 한 개발자는 나에게 "free 명령이 안되는데 왜죠?" 하고 물었다. You would think that people would understand that if you make a change to the operating system, then they will need to learn about this, but they don’t. A developer asked me “The command free doesn’t work, why?”
리눅스에서 이 명령은 메모리 사용량을 보여준다. 나는 "free는 FreeBSD에 없으니까 vmstat을 사용하면 될거에요. 혹은 top명령을 쓸수도 있겠네요" 라고 말했다. 유저들은 몇가지 새 도구를 배워야 할 것이다. Under Linux, this command shows you information about memory usage. I just told him: “free does not exist in FreeBSD. You can use the vmstat command and you will get everything you need. You can also use top.” Users will have to learn a few new tools.
What’s wrong with putty?
윈도우즈에서는 보통 ssh 클라이언트로 Putty를 사용할것이다. 나는 Putty에 있는 기본 FreeBSD 프로필이 사용자에게 전혀 친숙하지 않다는 점을 인정해야만 했다. 많은 key들이 기대했던 대로 동작하지 않는다. 블라블라... 인터넷검색을 통해서 서버쪽에 몇가지 수정을 했고 겨우 사람들을 만족시킬수 있었다. On Windows, you are likely to use the ssh client Putty. I have to admit that Putty with the default FreeBSD profile is not user friendly at all. A lot of keys are not doing what you would expect them to do. For example, typing “home” or “end” will display a “~”, typing “delete” will add a character, console dialogs (like the one in ports or the frame in tmux) are made of weird characters etc...
After a quick search on the Internet, the fix was made on the server-side. People are now happy with their Putty.
Paths of death
시스템의 변화에서 매우 중요한 변화는 파일시스템의 구조다. FreeBSD에서는 설정파일이 /etc 와 /usr/local/etc 에 나누어져있고, 데비안리눅스에서는 /etc 에 전부 있다. /var/www 폴더는 없다. /usr/local/www 로 대체된다. 패키지 바이너리는 /usr/local/bin/ 아래에 있다. One extremely important change between the systems is the filesystem hierarchy. In FreeBSD, configurations files are separated between /etc and /usr/local/etc, while Debian stores everything in /etc. The folder /var/www does not exist, it is replaced by /usr/local/www. Packages binaries are under /usr/local/bin/.
시스템에 설치된 패키지 관련 항목은 전부 /usr/local/ 폴더에 있다. 이 폴더 외에 있는것은 기본 시스템들이다. Everything installed on the system with packages is installed in /usr/local/. Files outside this folder come from the base system.
B.1 Compilers
우리는 작업할때 컴파일러를 사용하고 C와 C++에 의존한다. gcc 컴파일러를 사용하는 많은 makefile에 문제가 있었다. 이전 시스템에서 gcc는 4.6버전이었는데, FreeBSD에서는 4.2.1버전이었다. Our work uses compilers and we rely on C and C++. We had a problem with a lot of makefiles, using the compiler “gcc”. “gcc” command was a 4.6 GCC on the previous system, while on FreeBSD “gcc” is a 4.2.1 version. If we add a new compiler, its full name must be used e.g.: gcc46 for GCC 4.6 etc.
gcc가 호환성 이슈로 컴파일이 잘 안되는 스크립트들을 수동으로 고쳐야했다. I had to fix manually some scripts where “gcc” was not compiling, due to compatibility problems.
버전낮은 GCC문제외에 헤더와 라이브러리 패쓰 문제로도 씨름했다. 링커가 그전에는 /usr/lib 폴더에서 찾아야했던 라이브러리 파일을 /usr/local/lib 폴더에서 찾아야했다. 헤더파일도 같은 종류의 문제가 있었다. In addition to the outdated GCC, I have been struggling with include and libraries paths too. The linker could not find the libraries located in /usr/local/lib instead of /usr/lib as before. The same kind of error was happening with includes files.
여러시간이 흐른뒤에, 나는 문제를 해결하기 위해서 GCC에게 몇가지 path를 더 알려주는 환경변수를 사용하기로 했다. 이 해결책은 그닥 makefile을 범용적으로 만들어주지는 못하지만, 우리는 우리 코드를 공유할 생각이 없었기 때문이다. After some hours, I decided to use an environment variable telling GCC to add a path by default to fix the problem. I know this solution makes the makefile not very portable because the paths will not be right without the environment variable. But, the makefile was not actually portable, and we do not plan to share our code.
We have scripts!
우리는 많은 스크립트를 사용하는데 모든 스크립트는 #!/bin/bash! 를 사용한다.We have a lot of scripts, doing various things. Every script is using #!/bin/bash!
모든 스크립트에서 이 부분을 수동으로 바꾸는건지 얼마나 지겨울지 상상하는건 어렵지 않을 것이다. 이래서 누군가가 sed를 만든거다. (역자주: FreeBSD에서는 bash가 /usr/local/bin 아래에 있음) You can imagine how boring it would be to fix every script manually. That is why someone wrote a “sed” script.
나는 bash를 /bin/bash 에 링크를 만들어서, 기존의 스크립트들이 참조하도록 했다. 사람들이 왜 /bin/bash 가 안되는지 알아내느라 시간을 낭비하지 않아도 되었다. I preferred to link Bash to /bin/bash, which is the path that our previous scripts were expecting. People did not have to waste time searching why their scripts using /bin/bash do not work.
스크립트를 쓸때는 bash의 풀 패쓰를 쓰지 말고 #!/usr/bin/env bash 를 사용하도록 하자. Please, when you write scripts, use #!/usr/bin/env bash instead of bash full path. And if you use Linux, if you link to /bin/sh, be sure to really be using /bin/sh and not a disguised Bash.
FreeBSD crash course
유저들이 사용하는 툴을 바꿔줄때는 최소한 친절해라. 뭐가 변경됐고, 왜 그렇게 변경했는지 설명하고 새로운 툴의 기본에 대해서 알려줘라. 일전에 얘기했던 'free' 명령이 없다는 것이라든지, 바이너리는 /usr/local/bin/ 에, 서비스 스크립트는 /etc/rc.d 나 /usr/local/etc/rc.d 에 있다는 것, 기본 설정 파일은 /etc/rc.conf 라는것 등. 사용자들은 새로운 FreeBSD 시스템에 대해서 알게되서 좋아했고, 당황해하지 않았다. 시간을 들여서 뭐가 바뀌었는지 설명하고, 적응할 시간을 주면 다 잘 될 것이다. When the time comes to change users tools, at least, be kind. Explain to them what changed and why you did it and teach them the basis of their new tool. Like I said before, the command “free” does not exist, binaries are in /usr/local/bin/ path, services scripts are either in /etc/rc.d or /usr/local/etc/rc.d, /etc/rc.conf is the main configuration file etc. My users were happy to learn a few things about their new FreeBSD system, they did not feel lost or abandoned. Take time to explain to them what changed, give them some time to learn and it is all good.
Where are my packages
패키지 관련해서 약간의 재미(혹은 안좋았던 뉴스)가 있었다. 우리는 대부분 오픈소스 프로그램이나 우리가 만든 프로그램을 사용한다. I had some fun (or bad news, I do not know) with the packages. We are mostly using open-source software, or our own programs.
Hello, I am an old closed source Linux library
우리가 꼭 써야하는 프로그램 하나가 1997년에 종료된 리눅스 라이브러리에 의존하고 있는게 밝혀졌다. 이미 그전에 리눅스 서버에서 사용할때도 제대로 동작하게 하기 위해서 약간 고쳤어야 했었다. 이 라이브러리는 우리 사업에서 매우 중요한 것이라서 이게 제대로 동작하지 않으면 FreeBSD를 사용하는 생각은 접어야 했다. I found ONE program relying on a 1997 closed source Linux library that we MUST use. Even on the previous Debian server, we had to do some hacks to make it work! This library is very important to our business and we must use it. If we cannot use it, bye bye FreeBSD.
다행히도 리눅스 에뮬과 몇가지 깔끔하지 않은 수정을 거쳐서 동작하게 만들수 있었는데, 몇달후에 우리는 그걸 다른걸로 교체할 예정이었다. Luckily, I got it working with Linux emulation and some dirty hacks that I would have preferred to skip. Also, in a few months, we will trash it because it is getting replaced.
얼마후에는 다른걸로 대체될 거란걸 알고 있는 프로그램을 동작시키기 위해서 많은 시간을 소비하는 건 꽤 좌절스러운 일이다. This is a bit frustrating to spend a lot of time getting a program working, when you know it will be removed soon
Hello, I am away from ports
나는 우리의 어플리케이션을 위해서 필요한 것들을 하나씩 설치하고 있었다. The other case is funny too. I was installing the dependencies of our application and I knew exactly what was needed, installing them one by one.
... 그런데 port 시스템에서 최신 라이브러리를 찾을수 없는 걸 하나 발견했다. 아무리 찾아도 나오지 않았다. …Until that moment when I could not find the latest library in ports! I have been looking on my favorite search engine “mylibrary + freebsd”, and found no answer.
개발자들을 저주했다. "아무도 쓰지 않는 이런걸 어디서 찾아낸거야?" 결국 port를 작성하는 법을 알아내서 내가 만들어야만 했다. (공유해야하겠지만 너무 지저분한 코드라서...) I have been cursing the developers. “Where did you find this? No one is using it! It’s not even in the freebsd ports!” And then I had to learn how to write a port that compiled. (I know I should share my port, but it is an ugly one actually).
Surprises!
이제 필요한 것들은 다 설치되었고 서비스가 잘 돌아가는지 체크하려는 참이다. (OS를 바꾸면 당연히 모든것이 예측대로 잘 되는지 확인해야 할것이다.) Now, all my dependencies are installed, services are running awaiting to be checked. (Yes, you should really consider checking if everything works as expected when you change your operating system and your servers!
그러던 차에, 누군가 당신에게 뭔가 이상한 점을 발견했다고 알려준다. Then, when everything is done, someone comes to tell you he found something strange.
My program A does not work as expected
FreeBSD에서 정상적으로 종료하다가 멈추는 프로그램을 발견했다. 스레드의 차이점 때문으로 파악되었고 컨트롤-C 를 눌렀을때 제대로 종료되도록 프로그램을 수정했다. We have a program that stopped terminating correctly on FreeBSD. This seems to come from a difference with threads, and exiting was not killing all the threads. We made a little change so the application was terminating correctly with
이건 왜 그런지 이유는 모르겠는데, 우리 프로그램중에 메모리를 많이 사용하는 게 있었는데 FreeBSD에서는 30퍼센트 적게 메모리를 사용하게 되었다. I do not have an explanation for this one. One of our applications consumes a lot of memory by loading shape files (with libshape), and with the same data, the new FreeBSD consumes 30% less memory than the previous Debian system.
이건 아마도 shapelib 이라는 라이브러리가 FreeBSD 시스템에서는 더 최신버전이고 시스템에 최적화되어 컴파일 되었기 때문인게 아닌가 싶다. 우리는 매우 만족했다. I assume this difference is coming from the shapelib, which is newer on the FreeBSD system, and which is compiled with optimizations for the server itself. We were very happy to see this behavior!
Valgrind needs to be recompiled...
디버깅을 위해서 valgrind를 사용하고 있었는데 뭔가 결과가 이상해서 포트 시스템에 우리가 수정한 코드를 적용해서 새로 인스톨했다. To debug the application, I was telling before, we used valgrind. After a day spent running the program under valgrind, we were not able to use the results – valgrind gave us an error. Valgrind has been monitoring too much memory that a compile-time limitation was reached. We had to recompile Valgrind with a modification in the source code to increase a value.
I have been happy to tell the developers that ten minutes later, I compiled valgrind from ports with a patch of mine, and that it was installed on the servers!
Conclusion
간단히 말해서, FreeBSD가 이전시스템에 비해서 더 많은 자유를 제공한다고 할수 있다. 개발자들이 원하는걸 제공할 수 있었다. In a nutshell, I would say that FreeBSD gives us more freedom than our previous systems. I can really provide the developers with the tools they want.
But, when it comes to using proprietary tools, I have to admit that FreeBSD may not be the best option. I have not had this problem (except for one library).
만일 내가 솔라리스나 NetBSD 또는 다른 리눅스 배포판등을 사용했다면 다른 비교를 할수 있었을 것이다. 하지만 FreeBSD는 좋은 성능을 보여주고, 하드웨어 호환, 완벽한 핸드북, 놀라운 안정성 그리고 깔끔하게 잘 설계된 시스템을 갖고 있다. If I would have been using Solaris, NetBSD, or another Linux distribution, I think I could have had a working result. But FreeBSD comes with good performance, server hardware compatibility, a complete handbook, incredible stability, control over packages and a clean and well-designed system.
Charles RAPENNE
Charles Rapenne는 프랑스의 작은 회사에 있는 리눅스/FreeBSD의 시스템 관리자이다. 그는 BSD시스템들을 사용하고 Common LISP으로 어플리케이션을 작성하기를 즐긴다. 그는 오픈 소스 소프트위에를 주로 사용한다. Charles Rapenne is a Linux, and now FreeBSD system administrator in a small company in France. He enjoys using *BSD systems and writing applications in Common LISP. His servers rely only on open source software.
나는 본문과 반대로 FreeBSD에서 개발한 것들을 퍼블리셔가 제공한 리눅스(CentOS)서버에 옮기는 작업들을 주로 했던터라 반가운 마음에 가져와봄...