[MySQL] DB auto repair 및 optimize

제공하는 mysqlcheck로 check 및 복구, optimize를 하려면 다음과 같이 한다.

mysqlcheck -u <USER_ID> -p<PASSWORD> --auto-repair <DB_NAME>
mysqlcheck -u <USER_ID> -p<PASSWORD> --optimize <DB_NAME>

예제로 wordpress의 경우, user를 wordpress로 했다면, 다음과 같이 하면 된다.

mysqlcheck -u wordpress -pPASSWORD_HERE --auto-repair wordpress
mysqlcheck -u wordpress -pPASSWORD_HERE --optimize wordpress

근데 wordpress의 경우 테이블을 optimize를 지원하도록 만들지는 않는다…

[Ubuntu] cron-apt로 패키지 자동 업데이트 하기

cron-apt를 설치하면 오전 4시에 알아서 패키지 업데이트를 해준다.

sudo apt-get install cron-apt

/etc/cron.d/cron-apt 파일 안에서 시간 설정을 바꿀 수 있다. 나는 오전 5시로 바꿨다.

root@bamtol:/etc/cron.d# cat /etc/cron.d/cron-apt
#
# Regular cron jobs for the cron-apt package
#
# Every night at 5 o'clock.
0 5	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 *	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 *	* * *	root	test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

참고: https://help.ubuntu.com/community/AutoWeeklyUpdateHowTo

[Linux] fstab의 구조와 옵션

fstab이란?

fstab은 Linux 시스템의 file system table을 뜻한다. mount를 쉽게 하기 위한 configuration table이다.

fstab의 구조

6개의 항목이 순서대로 구성되어야 한다.

  1. 디바이스 (Device): 보통 mount되는 디바이스의 이름 혹은 UUID이다. 예를 들면, sda1
  2. 마운트 위치 (Mount point): mount될 디렉토리의 위치
  3. 파일 시스템 타입 (File System Type): 사용되는 file system의 type
  4. 옵션 (Options): mount 옵션. 여러개를 쓸 때는 콤마(,)로 구분한다.
  5. 백업 동작 (Backup Operation): 0은 백업하지 않음. 1은 dump로 backup을 할지를 결정. 오래된 backup 방법이라서 0으로 설정해서 사용하지 않도록 한다.
  6. 파일 시스템 체크 순서 (File System Check Order): 0은 fsck로 체크하지 않음. 1은 root file system, 다른 파티션들은 2로 설정되어야 한다. 3, 4, … 로 한다고 해서 순서가 되지 않으므로 순서를 설정하지 않도록 한다. 그냥 다른 모든 파티션은 2이다.

예제

proc            /proc           proc    defaults          0       0
PARTUUID=5e3da3da-01  /boot           vfat    defaults          0       2
PARTUUID=5e3da3da-02  /               ext4    defaults,noatime  0       1
UUID=678dcc13-1b44-4ee8-80cf-7f186587054d       /mnt/NAS        ext4    defaults,noatime,rw     0       2
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

다른 mount 옵션

  • auto / noauto: 부팅 시에 자동으로 mount할지 말지.
  • exec / noexec: 그 파티션이 바이너리를 실행할 수 있는지 아닌지. 보통 보안 목적으로 noexec로 설정된다.
  • ro / rw: ro는 읽기 전용 (read-only), rw는 읽기 쓰기 (read-write)
  • nouser / user: user가 mount권한을 갖을지 말지.
  • atime / noatime / relatime: access time (atime) 을 기록할지 말지. relatime은 access time이 atime data가 마지막으로 update된 (mtime) 이후에 파일이 수정되었을 때, 또는 마지막으로 access된 후 일정 시간 (기본값은 하루)이 지난 후에만 업데이트한다.
  • suid / nosuid: suid와 sgid 비트 동작을 허용할지 말지.
  • dev / nodev: character나 block special device를 interpret할지 말지.
  • defaults: 기본값을 사용. rw, suid, dev, exec, auto, nouser, async 와 같다.

참고 자료

[HTML5&CSS] CSS page layout – float, flex, grid

세가지 많이 쓰이는 layout 테크닉이 있다.

  1. float
  2. flex
  3. grid

 

float-based CSS layout은 이 셋 중 가장 오래되었지만 여전히 쓰인다.

float의 property는 왼쪽 아니면 오른쪽 어디에 둘 건지를 정한다.

float: left 혹은 float: right

float: none을 쓰기도 하는데 자주 안 쓴다. left나 right를 override하고 싶을 때 쓴다.

일반적으로 float되는 element의 width를 px나 %등을 사용해서 명시적으로 정해준다.

width: 100px 혹은 width: 50%

float이라는 이름에서 알 수 있듯이, non-floated element 위에 떠 있는 식으로 보이면서 layout이 깨지는 문제를 자주 겪는다. 많은 해결책이 있지만, 가장 간단한 해결책은 이를 감싸는 element에 다음 속성을 주는 것이다.

overflow: hidden

 

flex-based CSS layout은 float-based CSS layout을 좀 더 개선한 새로운 대안이다. flex에서는 float에서와 같은 floating element의 clearing 문제를 걱정할 필요가 없다. 사용을 위해서는 개별 item을 담는 flex container에 다음을 적용하면 된다.

display: flex;

기본값으로 한 줄에 모든 element를 두도록 되는데, 이를 바꾸기 위해서는 다음 속성을 적용한다.

flex-wrap: wrap;

flex item들의 width를 정하기 위해서는 다음과 같이 한다.

flex-basis: 25%;

 

grid-based CSS layout은 세가지 중 가장 최신 기술이다. grid container에 다음을 적용한다.

display: grid;

그리고 grid 내에 몇 개를 둘 건지, 크기는 어떻게 할지, 몇 개의 열을 둘 것 인가를 정한다. 아래처럼 하면 4개의 같은 크기를 가지는 열을 갖게 된다.

grid-template-columns: auto auto auto auto;

float나 flex에서는 item들의 width를 정해주어야 했지만, grid-based CSS layout에서는 그럴 필요가 없다.

 

구글도 한다. 자동 checkpatch!

작년 8월부터 10월에 “개발 환경 개선 Git + Gerrit + checkpatch + cleanpatch” 에서 이야기했던대로
회사에서는 아무도 나에게 이런 것을 하라고 한 적은 없지만,

1. Gerrit 시스템 상에서 리눅스 커널에 대한 Change는 자동으로 checkpatch.pl 를 실행해서 해당 결과를 자동으로 comment하고, Error 나 Warning이 있는 경우 해당 패치셋에 -1로 리뷰 점수를 부여하고,
2. White space error, 소스 코드, Kconfig, Makefile 등의 파일의 Execution 권한 에러 등이 있는 경우 자동으로 수정해서 새로운 Patch set으로 올려주는

시스템을 구현해서 도입했다(나중에 연말 임원 회의 때 “우리 부서의 자랑” 같은 발표를 하려고 했던 것으로 알고 있다. 했나?).

그런데 올해 2월 초부터 구글의 gerrit 시스템에도 비슷한 것이 보이기 시작했다. “Kernel code style” 이라는 사용자 이름으로 checkpatch 결과가 붙기 시작한 거다. 내가 구현한 위의 것에서는 1단계까지의 것으로 보인다. 보자마자 ‘어라? 이것들 나랑 비슷한거 만들었네?’ 란 생각에 흥미로움을 감출 수 없었다. 더 재밌는 건 내 스크립트가 comment 하는 형식과 구글의 comment 형식이 거의 같다는 거다. 난 너무 많으면 길어서 내용을 좀 자르긴 했다. 도입 초기에는 에러가 3만개, 6만개씩 있는 패치들도 있었으니까! ㅎㅎㅎㅎ

그래서 찾아보니 구글의 커널 개발자 Brian Swetland 가 2009년 9월에 이를 할 수 있으면 좋겠다는 이슈를 올렸었고, 2010년 2월에 hooks 를 이용할 수 있다는 답변으로 closed 되었다. 답변으로 달린 방법이 거의 정확히 1단계를 위해 내가 구현한 방법과 일치하는데, 구글 내부 gerrit 에서도 사용했었는지는 알 수 있는 방법은 없다. 그런데 Nexus S때도, Galaxy Nexus 때도 2월 이전에는 쓴 적이 없단 말이지… ㅎㅎㅎ

동작하는 방식을 조금 보니 아마 커널 Change를 올리는 개발자 그룹이 있어서 해당 그룹에 속한 개발자가 Change를 올리면 checkpatch로 체크를 하는 것 같다.

이글을 쓰다가 TI 커널 브랜치에서부터 시작이 된 것 같아서 찾아보니 TI Gerrit(http://review.omapzoom.org/)은 2011년 7월부터 Ruslan Bilovol 이란 개발자가 자기 Bot을 사용해서 Change-Id check와 checkpatch를 자동으로 돌리는 것을 시작했었다! 난 작년 7월에 산호세에 있었고 7월 말부터 이 일을 맡아서 시작했었으니! 오! 세계 최초라 한 것이 부끄럽구나! …근데 자동으로 고쳐서 올려주는 건 아직 나밖에 안했잖아???? ㅎㅎㅎㅎ

아무튼 내가 생각한 것과 비슷한 생각들, 그리고 비슷한 구현물들을 세계 이곳저곳에서 발견할 수 있다는 게 너무나도 재밌다!!!

p.s.: 나한테 더 성능좋은 PC, 서버들이 더 많이 주어진다면, 아마 더 많은 일을 할 수 있을텐데…