리눅스에서 디스크 용량을 확인할 때 df 명령어로 확인했을 때 용량이 컸는데 du 명령어로 확인하니까 용량이 작았다.
파일을 삭제했는데 df에 반영이 되지 않은 것이다.

예를 들어, /var 용량의 경우
df 명령어로 확인했을 때 사용중인 공간이 31G 였다고 하면
du 명령어로 확인해보니 사용중인 공간이 10G 밖에 되지 않는다.

이 문제가 발생하는 이유는
보통 시스템을 오래 켜 둔 상태에서 발생한다고 한다.
그 이유는 특정 프로세스가 file descriptor 를 연 후에 file descriptor 가 가리키는 파일을 지웠는데
그 프로세스가 여전히 파일을 읽고 쓰고 있는 것이다.

따라서 lsof 명령어를 통해 문제가 있는 프로세스를 찾을 수 있다.
우선, 문제가 있는 디렉토리의 열린 파일 목록을 검색한다.

# lsof

또는 해당 디렉토리 검색

# lsof [DIRECTORY]

grep 명령어로 deleted 만 검색

# lsof | grep deleted

lsof 명령어를 통해 확인해보면 NAME 마지막에 (deleted) 라고 되어있는 프로세스를 확인할 수 있다.

이 경우에는 파일을 지웠지만 아직까지 남아있어 용량을 차지하고 있는 프로세스다.
따라서 해당 프로세스의 PID를 kill 명령어를 통해 죽이면 된다.

# kill -9 [PID]

그리고 다시 확인해보면 정상으로 돌아와있는 것을 확인할 수 있다.

df 명령어의 경우 특정 상황에서 정확한 실제 용량을 반영해주지 못하는 경우가 발생한다.
따라서 lsof 명령어를 통해 문제 있는 프로세스를 찾아 죽이는 방법을 통해 정상적으로 돌아오게 할 수 있지만
시스템 재시작이 가능하다면 재시작하는 것도 하나의 방법이 될 수 있다.

[참고 사이트]

df 용량이 실제하고 안 맞을 때

출처 : https://jaynamm.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4%EC%97%90%EC%84%9C-df-%EC%9A%A9%EB%9F%89%EA%B3%BC-du-%EC%9A%A9%EB%9F%89%EC%9D%B4-%EB%8B%A4%EB%A5%BC-%EA%B2%BD%EC%9A%B0-%ED%99%95%EC%9D%B8

Centos7 브릿지 방화벽(iptables forward) 작동안할시

Centos7 서버에 bridge 를 이용하여 iptables 방화벽을 구성

iptables  forward가 작동하지 않고 nf_contrack 에 패킷이 보이지 않는다

Centos7 에서 아래 모듈을 올려줘야 작동한다

modprobe br_netfilter

Centos6 에서는 아래 파라미터를 1로 활성화 하면 됨

/etc/sysctl.conf
# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

출처 : http://blog.servis.co.kr/index.php/2021/11/17/centos7-bridge_iptables/

gcc 에서 pkg-config 사용법 :

http://tjcplpllog.blogspot.kr/2014/08/pkg-config.html

================================================================================================

source 로 설치한 패키지의 pkg-config 정보가 인식이 안될때 아래에 사이트에 잘 정리가 되어있다.

 

http://blog.daum.net/heyjun/15705389

 

================================================================================================

 

pkg-config 의 모든 위치를 알고싶다면

locate pkgconfig

 

pkg-config 를 등록하려면

export PKG_CONFIG_PATH=/home/me/usr/libxml/lib/pkgconfig

 

제대로 설정되었는지 확인하려면

echo $PKG_CONFIG_PATH

 

pkg-config 환경변수를 매번 쳐주기 귀찮다면

~/.bashrc를 에디트 해서 export (무지무지 긴 변수)를 적어주면 된다.

 

[출처] http://s2paper.egloos.com/6212047

1. php 7.4 소스 다운로드

wget https://www.php.net/distributions/php-7.4.22.tar.gz

2. 압축 해제 및 설치에 필요한 패키지 추가 설치 및 configure 에러 보완 전처리

yum -y install sqlite-devel oniguruma-devel
ln -s /usr/lib64/libgdbm_compat.so /usr/lib/libdbm.so

[에러발생]
checking for libzip >= 0.11 libzip != 1.3.1 libzip != 1.7.0… no

configure: error: Package requirements (libzip >= 0.11 libzip != 1.3.1 libzip != 1.7.0) were not met:

No package 'libzip' found

No package 'libzip' found
No package 'libzip' found

yum 으로 설되는 libzip libzip-devel 패키지의 버전이 요구 버전 보다 낮아서 libzip 을 compile 설치 해야 함.

그러나 libzip 을 cmake 하기 위해서 또 필요한 cmake 버전이 낮아서 cmake도 컴파일로 설치를 해야 함.
 
   - libzip 필요 CMake 버전 관련 에러 메세지
    CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
    CMake 3.0.2 or higher is required. You are running version 2.8.12.2

[Cmake 상위버전 컴파일]

https://github.com/Kitware/CMake/releases 에서 설치하고자 하는 버전을 찾아 소스를 다운로드

작성글의경우 cmake-3.21.1 를 사용함.

wget https://github.com/Kitware/CMake/releases/download/v3.21.1/cmake-3.21.1.tar.gz

tar zxvf cmake-3.21.1.tar.gz
cd cmake-3.21.1
./configure --prefix=/usr/local/cmake-3.21.1
make && make install
ln -s /usr/local/cmake-3.21.1 /usr/local/cmake

[libzip 1.7.3 버전 컴파일]

wget https://libzip.org/download/libzip-1.7.3.tar.gz

tar zxvf libzip-1.7.3.tar.gz
cd libzip-1.7.3
/usr/local/cmake/bin/cmake -DCMAKE_INSTALL_PREFIX=/usr/local/libzip-1.7.3
make && make install
ln -s /usr/local/libzip-1.7.3 /usr/local/libzip
export PKG_CONFIG_PATH=/usr/local/libzip/lib64/pkgconfig (PHP가 컴파일 진행중인 창에서 실행할 것)

 

3. php 7.4 컴파일 진행

./configure --prefix=/usr/local/php-7.4.22 --with-apxs2=/usr/local/apache/bin/apxs --with-config-file-path=/etc/httpd/conf --with-iconv --with-gdbm=/usr --with-zlib=/usr --with-openssl --with-kerberos=/usr --with-imap-ssl=/usr --with-jpeg --with-png --with-zlib-dir=/usr --with-xpm --with-freetype --with-pic --with-curl --with-dbm --enable-gd --disable-libtool-lock --disable-short-tags --disable-debug --disable-ipv6 --enable-inline-optimization --enable-fast-install --enable-calendar --enable-ftp --enable-sockets --enable-gd-jis-conv --enable-dba=shared --enable-exif --with-zip --enable-mbstring --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-bcmath --enable-shmop --enable-soap --enable-xml --with-mysqli=/usr/local/mysql/bin/mysql_config --with-libdir=lib64

make && make install

ln -s /usr/local/php-7.4.22 /usr/local/php

[PHP 7.4 에서 변경되거나 사라진 컴파일 옵션]
--enable-zip  → --with-zip
--with-gd → --enable-gd
--with-jpeg-dir → -with-jpeg
--with-libxml-dir → --with-libxml
--with-png-dir → --with-png
--with-freetype-dir → --with-freetype

--with-png (옵션없음 제외)

 

[참고 자료]

https://hoing.io/archives/3844
https://manvscloud.com/?tag=php8-%EC%84%A4%EC%B9%98

'Works > 설치매뉴얼' 카테고리의 다른 글

Apache에 mod_cband 설치  (0) 2016.06.24
PHP 속도 향상을 위한 eAccelerator 설치  (0) 2016.03.18
JDK(java) & tomcat 설치 총정리  (0) 2016.01.11
php pdo-mysql 확장 모듈 설치  (0) 2015.10.28
Apache 에 GeoIP 모듈설치  (0) 2015.10.28

MySQL 서버의 time out 설정은 크게 3가지가 있습니다. 
  mysqld time out 
    - connect_timeout (bad handshake timeout)      
    - interactive_timeout (interactive 모드에서 connection time out)      
    - wait_timeout (none interactive 모드에서 connection time out)  

connect_timeout, interactive_timeout 은 튜닝과 좀 거리가 멀고, 실제로 바쁜 서버라면, 반드시 wait_timeout 을 따로 튜닝하여 설정해줘야 합니다. 

[connect_timeout] 
이 설정은 mysqld 와 mysql client 가 연결(connection)을 맺기 위해서mysqld 가 연결 패킷을 기다리는 최대 시간입니다. 
즉 TCP 연결을 맺는 과정(3-way handshake)에서, connect_timeout 동안에도연결 패킷이 들어오지 않으면 연결이 실패(취소가 아님)되고,bad handshake 로 응답합니다. 

  *참고)  
        - 연결 실패 : 연결 과정중에서 fail 되는 경우 (Aborted_connects)      
        - 연결 취소 : 연결이 된 상태에서 강제로 close 된 경우 (Aborted_clients)  

다시 말하면 mysqld 와 mysql client 가 TCP 연결을 맺는 최대 시간으로이 시간보다 큰 경우는 모두 Aborted_connects 에 해당됩니다.(단위는 초) 
  연결 실패율(POF) =  (      Aborted_connects * 100 / Connections  ) 
  연결이 실패되는 경우        
        - 연결 패킷에 올바른 연결 정보가 없는 경우      
        - 특정 user 가 권한이 없는 데이터베이스에 접근할 경우      
        - mysqld 접근 password 가 틀린 경우      
        - connect_timeout 보다 긴 연결 과정 

연결 실패율(POF)이 높은 경우는, 대부분 권한이 없는 데이터베이스 연결이나, 틀린 password 를 사용할 경우가 많습니다. 
기본값은 대부분 5(초)로 설정되어 있으며, 따로 튜닝할 필요는 없습니다. 
mysqld 의 --warnings 옵션 사용과 xxx.err 파일에 기록됩니다. 


[interactive_timeout] 
interactive 모드에서 time out 을 말합니다. 
interactive 모드는 'mysql>' 과 같은 프롬프트 있는 콘솔이나 터미널 모드를말합니다. 
mysqld 와 mysql client 가 연결을 맺은 다음, 다음 쿼리까지 기다리는최대 시간을 의미합니다. 
설정된 interactive_timeout 까지도 아무런 요청(쿼리)이 없으면 연결은취소되고, 
그 이후에 다시 요청이 들어오면 연결은 자동으로 맺어집니다. 

interactive_timeout 안에 다시 요청이 들어오면 wait time은 0으로 초기화됩니다(CLIENT_INTERACTIVE). 

  ERROR 2006: MySQL server has gone away  No connection. Trying to reconnect...  Connection id:    12002  Current database: xxx 

이와 같은 연결 취소는 Aborted_clients 에 누계되고, wait_timeout 의결과도 함께 포함됩니다 
기본 값은 28800(8시간) 초로 설정되어 있는데 상당히 관대한 설정입니다. 
약 1시간(3600) 정도로 설정하는 것을 권장합니다. 


[wait_timeout] 
이 설정은 제일 중요한 파라메터 항목입니다. 
interactive 모드가 아닌 경우에 해당되며,mysqld 와 mysql client 가 연결을 맺은 후, 
다음 쿼리까지 기다리는최대 시간을 의미합니다. 
즉 대부분 PHP 나 C, PERL, python 등등의 API 를 이용한 client 프로그램모드를 말합니다. 
interactive_timeout 과 마찬가지로 wait_timeout 까지 아무런 요청(쿼리)이없으면 연결은 취소되고 
그 결과는 Aborted_clients 에 누계됩니다. 
wait_timeout 안에 다시 요청이 들어오면 wait time 은 0 으로 초기화 됩니다.(SESSION.WAIT_TIMEOUT) 
  연결 취소율(POC) =  (      Aborted_clients * 100 / Connections  ) 
  연결이 취소되는 경우(강제 종료됨)  
      - 종료(exit) 되기전 mysql_close() 가 없는 경우      
      - wait_timeout 이나 interactive_timeout 시간까지 아무런 요청(쿼리)이 없는 경우  

기본 값은 interactive_timeout 과 마찬가지로 28800(8시간) 초로 설정되어있는데, 역시 너무 관대한 설정이라고 할 수 있습니다. 
앞에서 연결 취소율(POC)을 계산해 보면, MySQL 서버가 어느 정도 비율로 강제종료하는지 알 수 있습니다. 
예를 들어 POC 가 1 % 이라면, 100 개의 커넥션당 하나 정도는 mysql_close()없이 강제 종료(exit)되고 있다는 의미입니다. 
이 값이 0 %에 가까울수록 좋습니다. 이 의미는 클라이언트 프로그램에서모두 정상적으로 종료했다는 의미입니다.

 

출처 : https://blog.naver.com/bomyzzang/221550485417

참조: OpenSSH Legacy Options

OpenSSH 7.0 이상에서 ssh를 사용해서 원격에 접속을 하려할 때 몇 몇 알고리듬은 보안상의 이유로 기본적으로 비활성화 되어 있다. 

NAS와 무선 인터넷 공유기의 ssh를 접속을 하려 하는데 아래와 같이 에러가 나면서 원격 접속이 되질 않는다. -o 옵션을 줘서 알고리듬을 추가 해도 된다. 또는 ~/.ssh/config에 host 정보를 추가 해주면 자동으로 적용이 된다.

no matching host key type found. Their offer: ssh-dss

My Cloud NAS 접속시 문제

krazyeom@MBP:~$ ssh root@192.168.219.18
Unable to negotiate with 192.168.219.18 port 22: no matching host key type found. Their offer: ssh-dss

ssh -oHostKeyAlgorithms=+ssh-dss root@192.168.219.18

~/.ssh/config

Host 192.168.219.18
HosKeyAlgorithms +ssh-dss

 

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

ASUS 무선 공유기 접속 문제

krazyeom@MBP:~$ ssh admin@192.168.219.5
Unable to negotiate with 192.168.219.5 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@192.168.219.5

~/.ssh/config

Host 192.168.219.5
KexAlgorithms +diffie-hellman-group1-sha1



출처: https://www.appilogue.kr/2844690?utm_source=weirdmeetup&utm_medium=original_link_on_post&utm_campaign=ssh+접속시+no+matching+key+문제+해결 [krazyeom's epilogue]

1. firewalld 중지 및 해제하기

systemctl stop firewalld
systemctl mask firewalld

systemctl status firewalld (firewalld 상태 확인)

* firewalld.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

위와 같이 나오면 정상적으로 죽은 것이다.

2. iptables service 설치

yum -y install iptables-services
systemctl enable iptables
systemctl start iptables

systemctl status iptables (iptables 데몬 상태 확인)

* iptables.service - IPv4 firewall with iptables
   Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; vendor preset: disabled)
   Active: active (exited) since 수 2021-02-03 05:14:07 KST; 1h 26min ago
 Main PID: 9989 (code=exited, status=0/SUCCESS)

 2월 03 05:14:07 localhost.localdomain systemd[1]: Starting IPv4 firewall with iptables...
 2월 03 05:14:07 localhost.localdomain iptables.init[9989]: iptables: Applying firewall rules: [  OK  ]
 2월 03 05:14:07 localhost.localdomain systemd[1]: Started IPv4 firewall with iptables.

위와 같이 나오면 정상적으로 시작 된 것이다.


MariaDB에 하이픈(-)이나 점(.)을 포함한 이름으로 데이터베이스를 만들면 에러가 납니다.

예를 들어

create database test-test;

라고 하면 다음과 같은 에러 메시지를 출력하면서 데이터베이스를 생성하지 못합니다.

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-test' at line 1

이 문제를 해결하는 방법은 데이터베이스 이름을 낮은 액센트표(grave accent)로 감싸는 것입니다. 즉

create database `test-test`;

와 같이 하면 됩니다.


출처 : https://www.manualfactory.net/10161


[증상]


CentOS7 서버에 FTP를 구축하여 처음 연결을 시도하였는데 아래와 같이 

500 OOPS vsftpd: refusing to run with writable root inside chroot()라는 메시지와 함께 

Critical error가 뜨면서 연결이 되지를 않았다.

원인은 chroot내에 쓰기 권한이 없어서 발생한 문제로써, 설정을 바꿔주면 해결되는 문제다.

 

 

[해결책]

vi /etc/vsftpd/vsftpd.conf

allow_writeable_chroot=YES 구문을 적당한 위치에 추가해 준다.

systemctl restart vsftpd.service


종종 sendmail이 설치된 장비에서, 다음과 같은 오류를 볼 수 있다. (흔하지는 않지만..)

 

[root@linux ]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

m4:/etc/mail/sendmail.mc:10: cannot open `/usr/share/sendmail-cf/m4/cf.m4': No such file or directory

 

위와 같은 오류는 sendmail.cf를 생성하기 위한 sendmail-cf 패키지가 설치되어 있지 않을 경우에 발생한다.
해결 방법은 다음과 같이 sendmail-cf 패키지를 설치하면 된다.

 

[root@linux ]# yum install sendmail-cf

원문 : http://blog.daum.net/aswip/3638513