메모리를 많이 먹는 작업을 하다 보니 메모리 부족 현상이 발생한다. 이럴 때 swap 크기를 조정하여 문제를 해결해 보자.
우선, swap 크기를 확인한다.
$ swapon -s Filename Type Size Used Priority /swapfile file 2097148 0 -2
2097148 / 1024 = 2048 해서 2GiB 정도가 할당된 것을 확인할 수 있다. 우선 swap을 내려놓자.
sudo wapoff -a
그리고 16GiB 정도로 사이즈를 늘려 보자.
sudo dd if=/dev/zero of=/swapfile bs=1G count=16
16이 16GiB 할당한다는의미로 보면 된다. 이제 swap을 위한 파일로 만든다.
sudo mkswap /swapfile
그리고 swap을 다시 올려놓자.
sudo swapon /swapfile
이제 확인해 보자.
grep SwapTotal /proc/meminfo SwapTotal: 16777212 kB
좋아!
WP API를 불러다 사용할 때, 도메인이 다르면 CORS 제한에 걸리게 된다. 물론 서버에서 직접 부르면 이 제한은 없지만, 브라우저에서 직접 호출할 때는 성가신 문제가 생긴다.
그래서 보통은 서버에서 직접 Access-Control-Allow-Origin 헤더를 추가하도록 하는 팁을 발견할 수 있다. 하지만 워드프레스 WP REST API 사용할 때 굳이 이렇게까지 할 필요는 없다.
간단하다. 요청할 때 Origin 헤더를 추가하고, 거기에 브라우저에서 접속한 URL을 입력하면 된다.
원리는 이렇다. 아래는 WP REST API 응답 메시지 출력 중, CORS 헤더를 만드는 함수 구현이다.
function rest_send_cors_headers( $value ) {
$origin = get_http_origin();
if ( $origin ) {
// Requests from file:// and data: URLs send "Origin: null".
if ( 'null' !== $origin ) {
$origin = sanitize_url( $origin );
}
header( 'Access-Control-Allow-Origin: ' . $origin );
header( 'Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE' );
header( 'Access-Control-Allow-Credentials: true' );
header( 'Vary: Origin', false );
} elseif ( ! headers_sent() && 'GET' === $_SERVER['REQUEST_METHOD'] && ! is_user_logged_in() ) {
header( 'Vary: Origin', false );
}
return $value;
}Code language: PHP (php)코드에 get_http_origin() 함수에서 $origin 을 발견하면 알아서 Access-Control-Allow-Origin 헤더를 추가해 주는 흐름을 볼 수 있다.
그리고 get_http_origin() 함수 구현은 아래와 같은데,
function get_http_origin() {
$origin = '';
if ( ! empty( $_SERVER['HTTP_ORIGIN'] ) ) {
$origin = $_SERVER['HTTP_ORIGIN'];
}
/**
* Change the origin of an HTTP request.
*
* @since 3.4.0
*
* @param string $origin The original origin for the request.
*/
return apply_filters( 'http_origin', $origin );
}Code language: PHP (php)요청 헤더에서 Origin 헤더 값을 발견하면 그 값을 리턴하도록 되어 있다. 그러면 js/ts 코드에서 fetch()를 호출할 때 아래처럼 하면 된다.
const url = 'https://...' // 요청할 URL.
fetch(url, {
mode: 'cors',
headers: {
'Content-Type': '...',
'Origin': 'https://....', // 브라우저의 URL.
}
})Code language: JavaScript (javascript)이렇게 하면 워드프레스가 알아서 CORS 허용 헤더를 추가해준다. 끝!
아래처럼 명령을 입력할 수 있다.
nmcli con up "VPN_NAME"Code language: JavaScript (javascript)그리고 연결 이름을 확인하려면,
nmcli con연결이 up이니, 연결을 끊는 것이 down 인 건 자명하겠지?
Diodon은 내 리눅스 데스크탑 환경에서 사용하는 클립보드 매니저이다. 클립보드의 내용을 관리할 수 있어 종종 활용되는 유용한 툴이다.
그런데 이게 요즘 태스크바에 아이콘이 두 번 보이는 현상이 있어 고민하던 중 찾아본 것들을 여기에 노트해 둔다.
이 방법은 정확하지 않다. 하지만 기록으로는 남겨둔다.
우선 /usr/share/applications 디렉토리에 diodon.desktop 파일이 있는지 확인해 보자. [참고한 사이트]
그리고 ~/.config/autostart 디렉토리에서 diodon-autostart.desktop 파일이 있는지도 확인해 보자.
[Desktop Entry]
Type=Application
Version=1.0
Name=Diodon
GenericName[bg]=Мениджър на системния буфер
...번역...
GenericName=Clipboard Manager
Comment[ca]=Gestor del porta-retalls GTK+
Comment[cs]=GTK+ Správce schránky
...번역...
Comment=GTK+ Clipboard Manager
Icon=diodon
NotShowIn=KDE;
Exec=diodon
Terminal=false
Categories=GTK;GNOME;Utility;
StartupNotify=false
MimeType=x-scheme-handler/clipboard;
X-GNOME-Autostart-enabled=true
Hidden=false
위 내용처럼 나와 있을 것이다.
이중 Hidden=true 가 된 부분이 있는지 확인해 보자. 아마 중복 실행되는 이유는 위와 같은 diodon 자동 실행 파일이 2개 있어서이고, 그 중 하나는 설정 > 시작 애플리케이션에서는 보이지 않게 Hidden=true 로 처리되어 있을 수 있다. 적절히 중복된 2개를 해결하면 diodon은 한 개만 실행될 것이다.
랩탑 PC에서 우연히 해결한 방법이다.
먼저 Diodon의 PPC를 따로 설정하고 최신 버전으로 업데이트한다.
sudo add-apt-repository ppa:diodon-team/stable sudo apt-get update sudo apt-get install -y diodon
그다음 설정 > 시작 애플리케이션으로 가서 Diodon의 실행시간을 0초에서 5초로 변경한 다음 저장한다.
참가로 아이콘이 2개가 보이는 거지 프로세스가 2번 실행되는 것은 아닌 것 같다. ps ax | grep diodon 하면 프로세스의 갯수는 1개이다.
보통 테마는 테마의 루트에 style.css 를 둔다. 그러면 코어는 style.css 파일에서 테마의 정보를 추출한다. 이게 정석이다.
그러나 오늘 sage라는 테마를 보다 보니, sage/resources 디렉토리에 functions.php 파일과 style.css 파일이 발견되었다. 이게 어떻게 가능한 가 싶어 뜯어 보니, wp-includes/themes.php 파일에 정의된 search_theme_directories() 함수에서 이런 동작을 지원하는 것이었다.
예를 들어 wp-content/themes/foo 라는 테마 루트 디렉토리에 bar라는 하위 디렉토리를 두고 거기에 style.css를 둔다. 그러면 wp-content/themes/foo/bar/style.css로 경로가 만들어질 것이다. 이 때 코어는 wp-content/themes/foo/bar를 테마 루트로 인식하게 된다.
최근 테마 루트에 composer.json, package.json등 여러 설정 파일들이 존재하게 되고 이것들은 이 디렉토리를 포기할 수 없다. 그런데 이런 설정 파일과 테마의 템플릿이 서로 뒤섞이면 매우 지저분하다. 이것을 의식한 건 아닌가 모르겠다. 아무튼 이렇게 하면 템플릿 코드와 여러 설정 파일을 깔끔히 분리할 수 있어 좋은 방법이라고 생각한다.
코어의 유닛 테스트 코드들은 아직 완전히 최신 PHPUnit을 지원하는 건 아닌 것 같다. 대신 Yoast의 PHPUnit-Polyfills 라이브러리를 사용하여 호환성을 보장하는 것 같다. 덕분에 PHPUnit 9 최신 버전을 사용할 수도 있고, 그 덕분에 PHP 8.1 최신 버전이 사용 가능하다.
이게 된다면 앞으로 플러그인 개발시 7.4보다 더 높은 버전을 도입해서 사용할 수 있겠다! 그동안 8.0의 기능을 사용하지 못해 정체되었는데, 이제는 가능할지도.
워드프레스에는 WP-CRON이라는 스케쥴에 맞춰 특정 작업을 실행하는 API가 있다. 액션 스케쥴러는 이것에 기반해 사용하기 편리한 비동기 실행 큐 라이브러리이다. 오토매틱에서 제작하고, 우커머스나 구독 플러그인 등 다수 플러그인에서 이미 사용되고 있다.
이번에 진행하는 프로젝트에서 이것을 사용해 볼 기회가 있었다. 간단하게 비동기 큐가 필요했고, 구조를 복잡하게 하는 것보다는 간단한 프로토타이핑으로 단순한 구성을 원했기 때문이다.
액션 스케쥴러는 워드프레스 기반으로 개발할 때, 비동기 큐를 써야 한다면 훌륭한 선택이라고 생각한다. 하여 차후 액션 스케쥴러를 다시 써야 할 때를 위해 간단히 사용한 것을 정리한다. 공식 홈페이지에서 5분이면 간단하게 얻을 수 있는 정보의 복제 말고, 조금 애매했던 개념을 설명하는 포스트이다.
액션이란 특정 시간에 특정 작업을 하기 위한 수단이다.
액션의 청구라는 개념이 있다. 영어로는 대략 stake claim 정도로 표현되는데, 액션 테이블에서도 claim_id 라는 것이 발견되기도 하고, 공식 문서에서도 한 두번 정도 언급될 뿐 이것이 무엇인지 자세히 설명하지 않는다. 여기서 간단히 설명하자.
액션은 이벤트를 예약하는 수단이다. 그러나 이것이 실행 큐에서 실제로 실행되기 위해서는, 먼저 큐가 액션의 스케쥴을 파악하여 적절한 액션을 골라 실행하기로 결정하는 작업이 먼저 필요하다. 해당 시점에 적절한 액션을 골라 실행을 결정하는 과정이 액션의 청구(claim)이며, 실행 큐가 한번에 작업하기로 결정한 액션에게는 동일한 청구 ID (claim ID)를 부여한다.
실행 큐가 실행되면서 한 번에 액션 뭉치를 가져와 일괄적으로 작업하는 것을 배치(batch)라고 한다.
배치에는 배치 크기 (batch size)라는 개념이 있다. 액션을 청구할 때 한번에 이 갯수만큼의 액션을 정한다. 배치 크기의 기본값은 25이다. 기본값 대로라면 실행 큐는 한 번에 최대 25개의 액션을 가져와 작업을 진행할 것이다. 이 때 25개의 작업은 동시 작업(multitasking)이 되는 것은 아니고, for-loop 을 돌면서 순차 진행된다.
실행 큐는 WP CLI를 통해 커맨드라인으로 실행이 가능하다. 커맨드라인에서는 제한 시간의 제약기 없기 때문에 상당히 오랜 시간 동안 작업을 해도 에러만 없다면 아무 문제 없다.
실행 큐는 기본적으로는 WP-CRON의 ‘매 분 (every minute)’ 스케쥴에 맞춰 동작한다. 그러므로 리눅스 기준 매 분마다 정확하게 실행 큐가 동작하는 것을 보장하려면 아래처럼 작업을 한다.
define( 'DISABLE_WP_CRON', true ); 를 삽입.* * * * * wget --delete-after http://YOUR_SITE_URL/wp-cron.php >& /dev/nullCode language: JavaScript (javascript)참고로 훅 이름은 ‘action_scheduler_run_queue’ 이다.
실행 큐는 훅의 콜백으로 단 1개만 실행된다. 즉, 기본값 대로라면 매 분 1개의 실행 큐가 생성되어, 25개의 액션만을 청구하여 배치를 하는 것이다.
이 기본값들은 액션 스케쥴러 개발자들이 다양한 상황을 염두에 두고 매우 동작에 제약을 둔 설정이다. 만약 운영하는 서버가 성능이 보다 괜찮다면 큐를 좀 더 둘 수 있다. 이 때 ‘Increasing Initialisation Rate of Runners‘에서 말하는 것처럼 ‘action_scheduler_run_queue’ 훅에 맞춰 admin-ajax.php 에 원하는 갯수만큼의 실행 큐를 증가시켜 볼 수 있다. 간단한 로그를 찍는 코드로 테스트 해 봤을 때, 저렇게 만들어진 큐에서 작업이 진행되며 AJAX 요청을 보낸 쪽에서는 더 작업을 하지 않는 듯. 그러므로 N개를 추가시켰으면 N+1의 실행 큐가 아닌 N개의 실행 큐가 생성되는 모양이다.
여러 개의 실행 큐가 admin-ajax.php 요청을 통해 실행한다면, 비동기적으로 동시 실행되는 그림이 만들어진다. 이 때 동시 배치 (concurrent_batch)라는 정수값이 중요한 역할을 한다. 이 값의 디폴트는 1이다.
각각의 실행 큐는 각자 작업을 진행하면서, 현재 청구(claim)되어 있는 액션의 개수가 이 동시 배치를 넘는지 넘지 않는지 체크하여 초과하면, 작업을 하지 않도록 프로그래밍 되어 있다.
디폴트인 1을 바꾸지 않으면 다음과 같은 문제점이 발생한다. 설명이 복잡하니 불릿으로 나누어 설명한다.
그러므로 동시 처리 수는 (총 실행 큐의 수) * (배치 사이즈) 에 근접하게 설정해야 제대로 동시성을 기대할 수 있다. 이게 가장 핵심인 부분이다.
이 부분은 나중에 덧붙인 글이다. 동시 처리 수에 대한 개념이 부족해 보충 설명을 적는다. 위 설명은 액션이 충분히 길 때에만 적절한 설명이다. 동시 처리 수를 실행 큐 수 * 배치 사이즈에 맞추더라도 하나의 큐가 모든 작업을 하려고 들 수도 있다. 하나의 실행 큐는 자기에게 허락된 메모리량, 처리시간의 여유가 되는 만큼 최대한 액션들을 많이 가져려고 한다.
예를 들어 보자. 총 실행 큐 수는 3개, 배치 사이즈 5개, 동시 처리 수를 15개로 잡았다고 보자. 그리고 처리해야 할 액션 수는 15개라고 가정하자. 그러면 총 실행 큐 3개가 각각 액션 5개를 맡아 처리할 것 같지만, 실제로는 그렇게 동작하지 않을 수 있다.
만약 주어진 액션이 너무 간단해 하나의 실행 큐가 5개의 액션을 모두 처리한 다음엔, 그 실행 큐는 메모리와 실행 제한 시간이 허락된 선에서 추가적인 액션을 불러와 일을 한다. 만약 액션 처리가 너무 간단했다면 여전히 하나의 실행 큐가 모든 액션을 혼자 담당할 수도 있다. 다른 실행 큐가 비동기적으로 실행되기도 전에 말이다. 정말 너무 일이 간단하다면 하나의 실행 큐가 동시 처리 수와 무관하게 스케쥴 된 모든 액션들을 가져와 작업을 할 수도 있다!
액션 스케쥴러는 유연성이 상당히 높다. 액션 스케쥴러는 플러그인으로도, 내 플러그인이나 테미의 서브 프로젝트로도 사용 가능하다.
액션 스케쥴러는 원래는 wp_posts 테이블에서 액션을 관리했던 모양이다. 처음 실행하면 마이그레이션 훅을 돌리는 것이 있는데 아마 예전의 포스트 테이블의 내용을 별도 테이블로 전환하는 과정을 돌리는 것 같다. 굳이 예전으로 돌릴 필요는 없는 듯.
작업을 돌리는 데 분 단위로 동작한다는 점이 약간 제약으로 생각될 수 있다. 그러나 정말 다량의 작업량이 있다거나 지정된 스케쥴에 동작하는 것이 우선적인 목적이라면 해당 단점이 크게 부각될 것 같지는 않다. 액션 스케쥴러는 확실히 워드프레스 환경에서 상당히 괜찮은 라이브러리임에 틀림없다고 생각한다.
$wpdb->prefix 꼭 사용하라. 보통 접두에 언더바 붙어 있으니 언더바 중복하지 말고.
$wpdb->get_charset_collate() 메소드는 자동으로 CREATE TABLE (...) 구문 뒤에 들어갈 DEFAULT CHARACTER SET {CHARSET} COLLATE {COLLATE} 구문을 만들어 준다.
dbDelta() 호출 전 반드시, require_once( ABSPATH . 'wp-admin/includes/upgrade.php' ); 해야 한다. 안그러면 fatal error 먹는다.
코덱스를 참고하면 대략 다음과 같이 쓰라고 되어 있다.
dbDelta() 는 꽤나 복잡한 프로세스를 거쳐 SQL 문을 분석해 테이블의 변화를 감지한다. 그리고 자신이 어떤 일을 했는지를 배열로 리턴한다.
Array
(
[wp_temp_table] => Created table wp_temp_table
)
위 예시는 wp_table_table 을 만들었을 때의 결과이다. 그리고,
Array
(
[wp_temp_table.middle_name] => Added column wp_temp_table.middle_name
)
이 예시는 wp_temp_table 에 middle_name 이라는 필드를 추가했을 때 결과이다. 이런 식으로 필드 타입, 기본값 등등이 잘 변경되는지 확인할 수 있다.
필드가 삭제나 인덱스 삭제는 되지 않는다. 별도로 필드를 없애는 구문을 추가해야 할 것 같다.
코덱스에서는 INDEX 보다는 KEY 쓰리고 하지만, INDEX 가 안 되는 건 아니다. 당연히. 그리고 이미 만들어진 인덱스 변경도 잘 되지 않는다. 별도로 구문을 써야 한다. 마찬가지로 PK 선언시 두 칸을 띄워 쓰라고 하는데, 딱히 왜 그래야 하는지는 잘 모르겠다.
복잡한 변경은 잘 인지하지 못하는 것 같다. 예를 들어 필드의 타입과 기본값까지 동시에 변경 처리하는 경우, 그 둘의 변경점을 잘 감지하지 못하는 것 같다.
CREATE TABLE 선언시 CREATE TABLE IF NOT EXISTS 나, 별도로 테이블이 있는지 없는지 체크하는 따위의 삽질을 하지 않아도 된다. dbDelta 가 적절히 CREATE TABLE 구문과 현재 선언된 테이블의 구조를 파악해 CREATE TABLE을 그대로 사용하기도 하지만, CREATE TABLE 대신에 ALTER TABLE 를 스스로 만들어 내거나, 변경점이 없다면 아무 일도 하지 않기 때문이다.
이런 것도 한 번 체크해 보라. dbDelta() 는 까다로운 녀석이다. SQL 구문에 변경점이 전혀 없어, 딱히 변경할 것이 없어 보인다. 그래도 진짜 아무 일도 실행하지 않는지 (즉, dbDelta()가 빈 배열을 리턴하는지) 확실히 체크해 보라. 간혹, 예를 들어, 타입을 대문자로 썼다거나 하는뭔가 실수 아닌 실수가 있다면 dbDelta()는 변경할 것이 없는데도 계속 ALTER TABLE 구문을 만드는 삽질을 하고 있을 수도 있다.
db 버전을 설정하고 잘 관리하라. 예를 들어,
function update_my_table() {
$current_version = '1.1.0';
$installed_version = get_option( 'my_db_version' );
if ( $current_version !== $installed_version ) {
global $wpdb;
$sql = "CREATE TABLE .....";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
update_version( $current_version );
}
}Code language: PHP (php)같은 패턴을 쓰면 된다. 이 때 사용자는 테이블을 업데이트하기 위해 플러그인을 비활성화/활성화를 할 수 없다. 그러므로 plugins_loaded 같은 액션의 콜백에서 이 함수를 한 번 호출해야 한다.
만약 이렇게 되면 activation callback 에서 굳이 테이블을 생성하는 작업을 중복해서 할 필요는 없는 것 같다. 아, 물론 플러그인 활성화 시 바로 초기화 작업 같은 것을 해 준다면 이야기가 달라지겠지만.
급하게 테스트해보고 메모하듯이 글을 적었다. 내가 틀린 것을 적었을 수도 있다! 어쨌든 변경점이 생길 때 dbDelta()가 리턴하는 결과와 테이블의 구조를 실제로 잘 체크해야 한다. dbDelta()가 기능 개선이 될 수도 있으니 말이다.
암튼 현재 dbDelta() 함수는 다른 웹 프레임워크의 마이그레이션 솔루션 (예를 들어, 장고) 만큼 테이블 변경을 세련되게 챙겨주지는 못하지만, 그래도 간단하게 테이블 변경을 찜쪄먹기에는 나름 유용한 도구로 보인다. 다만, 이 녀석이 진짜 까다로우니 조심해서 쓰도록 하자.
iptime공유기에 국가별 차단 기능이 생겼다고 해서.. 라는 글을 보고 공유기를 업데이트 해 보니, 진짜로 IP 차단 기능이 생긴 것을 확인하였습니다.
그런데 UI가 조막만해서 IP를 일일이 관리하고 차단하기가 너무 어려웠어요. 오호라? UI를 잘 보니 규칙을 파일로 백업하는 기능이 있었지 뭡니까? 이것으로 .cfg라는 파일을 생성하는 것을 확인하였습니다.
Type=firewall # Do not modify
Version=1.0.0 # Do not modify
lang=utf-8 # Do not modify
[차단 #1]
enable = 1
schedule = 0000000 0000 0000
flag = 0
{
direction = outin
src_type = ip
dest_ip_address = {start}-{end}
protocol = none
policy = drop
}
[차단 #2]
enable = 1
schedule = 0000000 0000 0000
flag = 0
{
direction = outin
src_type = ip
dest_ip_address = {start}-{end}
protocol = none
policy = drop
}
위는 그 cfg 파일의 샘플입니다. 대략 24시간 외부에서 내부로 접속하는 특정 IP 대역을 차단하도록 설정한 예입니다. {start}와 {end}에 각각 IPv4 형태로 문자열을 넣어주면 됩니다.
처음에는 한국 인터넷 정보 센터 (KRNIC)에 가서 모든 국가별 IP 할당 대역을 파악한 후, 특정 국가의 IP를 전부 차단시킬 생각습니다. 그러나 공유기의 성능 한계가 있어 200개까지 등록되지 않는다는 제약이 있어 이렇게는 할 수 없더군요. 예를 들어, 중국의 모든 IP 대역 등록건만 해도 8000여개에 달하니까요.
그래서 이렇게 많은 양의 IP 대역에 대해 애쓰기보다는, 관리자 로그 파일을 보고 내 공유기에 천착하는 IP만 차단하기로 했습니다. IP 타임 관리자 로그를 보면 다음처럼 나옵니다.
2022/03/11 09:02:22 DHCP 서버가 IP 할당함: 192.168.10.32 (MAC : XX-XX-XX-XX-XX-XX) 2022/03/11 08:20:19 잘못된 VPN 계정 또는 암호로 접속을 시도 하였습니다(qq, XXX.XXX.XXX.XXX)
2번째줄입니다. 어디선지는 모르지만 VPN 계정이나 관리자 로그인을 노리고 집요하게 뭔가 하는 것입니다. qq라는 id로 로그인 실패를 했고, 뒤에 원격 IP가 나옵니다.
IP 조회를 해 보면, 진짜 아무 연고도 없는 곳입니다. 이제 로그 특정 부분을 따다 IP 부분만 수집합니다.
우선 아래 그림처럼 공유기 관리자 로그를 복사해 파일로 만듭니다.
파일의 로그에서 IP만 추출해 설정 파일로 만들어 주는 파이썬 스크립트를 제작했습니다. 로그 파일의 이름이 log.txt라면 이것을,
python iptime_block_from_log.py < log.txt > rule.cfgCode language: CSS (css)처럼 입력합니다. 그러면 rule.cfg 파일이 만들어 집니다. 그럼 이 cfg 파일을 공유기에 올려 두면 됩니다.
저는 이렇게 적용 후, 확실히 해당 지역에서 무단 접속이 사라진 것으로 보입니다. 효과가 나름 있는 거 같네요. 다만 공유기의 로그도 무한히 있는 것도 아닙니다. 최대 400개가 한계이니 더 다양한 IP를 차단할 수 있으려면 좀 더 로그나 IP를 쌓아두고 관리하면서 차단할 수 있어야 하겠네요. 일단 이번에는 여기까지 만들어 보고 더 나은 버전은 차후에 고민해 보겠습니다.
덧, 이후 계속 “잘못된 VPN 계정 또는 암호로 접속을 시도 하였습니다” 메시지와 차단한 IP가 기록되네요. 이 방법으로는 접속 자체를 막지 못하는 것 같습니다.
ffmpeg -i {URL} -c copy output.aac출처: Stackoverflow
워드프레스 보안 관련 사항을 지원하는 WP CLI 확장.
Roach is a complete web scraping toolkit for PHP. It is heavily inspired (read: a shameless clone) of the popular Scrapy package for Python.
Think of it as
curlfor humans.
이게 정확한 방법인지 확실한 문서화된 자료는 찾지 못했지만, 소스 코드를 뜯어 보다가 발견한 방법이다. 적당히 기록해 둔다. 공식적인 방법을 찾으면 수정하기 바란다.
H.M.R (Hot Module Replacement)은 정말 쓸만하다. 그래서 워드프레스에서 wp-script를 활용한 리액트 컴포넌트 개발할 때 사용하고자 한다.
우선, 워드프레스의 공식 스크립트를 활용한다.
pnpm add -D @wordpress/scriptsCode language: Bash (bash)포스트 작성시 @wordpress/scripts 의 버전은 23.0.0 이다.
package.json 에서 ‘scripts’ 에 ‘start’ 명령어를 등록한다.
{
...
"scripts": {
"start": "NODE_ENV=development wp-scripts start --hot",
"build": "wp-scripts build"
},
...
}Code language: JSON / JSON with Comments (json)이 때 ‘–hot’ 파라미터를 붙이는 것이 필수. start에는 위 예시처럼 NODE_ENV 환경 변수를 ‘development’로 맞춘다.
define( 'WP_ENVIRONMENT_TYPE', 'development' );
define( 'SCRIPT_DEBUG', true );Code language: JavaScript (javascript)NPM 페이지에 따르면 ‘SCRIPT_DEBUG’를 설정하라고 되어 있다.
const defaultConfig = require('@wordpress/scripts/config/webpack.config')
const isProduction = process.env.NODE_ENV === 'production';
if (!isProduction) {
module.exports = {
...defaultConfig,
devServer: {
...defaultConfig.devServer,
allowedHosts: [
'127.0.0.1',
'localhost',
'.dev.site', // NOTE: match your domain.
],
hot: true
}
}
} else {
module.exports = defaultConfig;
}Code language: JavaScript (javascript)보통 localhost나 127.0.01 같은 IP 그대로는 개발하지 않으므로 주석으로 ‘NOTE’ 친 부분을 개발 도메인으로 설정한다. 앞에 ‘.’ 이 붙어 와일드카드가 적용된다. 그러므로 이 부분을 변경하기 위해 플러그인의 루트에 webpack.config.js 를 넣어 설정을 오버라이드한다.
리액트 코드를 작성한다. 예를 들어, 나의 index.js의 최상위 콤포넌트는 아래처럼 작성했다.
import React from 'react';
import ReactDOM from 'react-dom';
import Dummy from "./dummy";
function App(props) {
const {title, you} = props;
return (
<div>
<p>Oh! Hello, new world!</p>
<p>You are {title}. {you}.</p>
<Dummy />
</div>
)
}
const wpHmrSample = Object.assign({
you: 'Unknown',
title: '',
}, window.hasOwnProperty('wpHmrSample') ? window.wpHmrSample : {})
ReactDOM.render(<App {...wpHmrSample} />, document.getElementById('wp-hmr-sample'))
if (module.hot) {
module.hot.accept();
}Code language: JavaScript (javascript)
wp-scripts에 의해 생성된 build/index.js 파일은 ‘wp-react-refresh-runtime’ 스크립트에 의존성을 가진다. 이를 확인하려면 build/index.asset.php 파일을 열어 보면 된다.
구텐베르크 플러그인을 활성화하거나, 혹은 활성화 하지 않아도 해당 스크립트의 위치를 찾아 내 플러그인에서 강제로 넣어버린다. 나는 후자를 취했다. 어쨌든 두 방식 다 구텐베르크 플러그인은 설치된 상태여야만 한다.
작성한 플러그인 샘플 코드는 github에 올려 두었다. 그리고 실행 결과도 캡처하여 비디오로 남겨 둔다.
아직 잘 모르는 부분까지 같이 비디오로도 남겼다. 영상 후반에 보면 App 컴포넌트 안에 있는 Dummy 컴포넌트를 수정하는 경우, 수정된 상황을 잘 감지는 하는 것 같지만 적용되지가 않는다. 왜 그런지는 아직 잘 모르겠다. 리액트가 변경된 컴포넌트를 렌더링하지 않아서 그런건지, 아니면 설정이 잘못된 것인지. 이것은 차차 알아가도록 하자.
sudo apt install build-essential libdbus-1-dev llvm libclang-dev libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev cmake libgtk2.0-dev libgtk-3-dev git clone https://github.com/Riey/kime cd kime scripts/build.sh -ar scripts/release-deb.sh ~ sudo dpkg -i ~/kime_amd64.deb
패키지 설치
sudo apt install pm-utils hibernate/swapfile 확인.
cat /proc/swaps
Filename Type Size Used Priority
/swapfile file 2097148 0 -2UUID 확인
findmnt -no UUID -T /swapfile
5c0028fe-edc4-4b17-93d0-b78fda1f83b8여기서 UUID 기록.
오프셋 확인
sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 2147483648 (524288 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 34816.. 67583: 32768:
1: 32768.. 63487: 67584.. 98303: 30720:
2: 63488.. 96255: 100352.. 133119: 32768: 98304:
3: 96256.. 126975: 133120.. 163839: 30720:
4: 126976.. 159743: 165888.. 198655: 32768: 163840:
5: 159744.. 190463: 198656.. 229375: 30720:
6: 190464.. 223231: 231424.. 264191: 32768: 229376:
7: 223232.. 253951: 264192.. 294911: 30720:
8: 253952.. 286719: 296960.. 329727: 32768: 294912:
9: 286720.. 319487: 329728.. 362495: 32768:
10: 319488.. 352255: 362496.. 395263: 32768:
11: 352256.. 385023: 395264.. 428031: 32768:
12: 385024.. 417791: 428032.. 460799: 32768:
13: 417792.. 450559: 460800.. 493567: 32768:
14: 450560.. 481279: 493568.. 524287: 30720:
15: 481280.. 514047: 557056.. 589823: 32768: 524288:
16: 514048.. 524287: 589824.. 600063: 10240: last,eof여기서 physical_offset: 의 처음인 34816을 기록.
/etc/default/grub 파일 수정
아래 예시처럼 변경.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=5c0028fe-edc4-4b17-93d0-b78fda1f83b8 resume_offset=34816"
GRUB 업데이트
sudo update-grub/etc/initramfs-tools/conf.d/resume 파일 생성
내용은 아래처럼.
RESUME=UUID=5c0028fe-edc4-4b17-93d0-b78fda1f83b8 resume_offset=34816
initramfs 재생성
sudo update-initramfs -c -k all재부팅 후, hibernation 확인
sudo systemctl hibernateyoutube-dl -g <url> | tail -n1Code language: HTML, XML (xml)출력으로 오디오의 URL 경로가 나온다.
위에서 얻은 URL과 연동 가능한 플레이어면 아무 거나 관계 없는데, 커맨드라인에서도 잘 동작하는 VLC를 사용한다. 개인적으로 mplayer가 좋은데, 오류가 있어 사용하지 못한다.
그리고 아래처럼 커맨드라인으로 실행하면 OK.
cvlc <URL 경로> --novideo --quiet
물론 웹브라우저를 이용해 유튜브로 직접 가서 플레이하는 것도 나쁘지는 않지만, 듣기만 하는 건데도 HD급 영상을 계속 플레이하느라 CPU 사용률과 메모리 점유가 꽤 된다. VLC로 하면 훨씬 CPU 사용률이 적다. Youtube에서 음질을 조정할 수 있지 않을까 생각해 봤는데, 아직 복잡한 옵션은 잘 모르겠다.
참고로 윈도우에서는 이렇게 해서 원하는 플레이어에서 재생 가능하다. 적당히 youtube-dl.exe와 플레이어의 경로는 편집하기 바란다.
powershell -command "&\"C:\Program Files\KMPlayer 64X\KMPlayer64.exe\" $(C:\Users\ep6tr\Downloads\youtube-dl.exe -g \"https://www.youtube.com/watch?v=KNMbDIKJ6T0\" | Select-Object -last 1)"Code language: PowerShell (powershell)미니에 우연히 적은 사연이 나옴. 이 ‘남창우’는 내가 맞음.