Technic – 페이지 3 – Bohemian@Home

2019년 4월 12일2019년 4월 12일

SQUASHFS error – ASUS RT-AC68U

얼마 전부터 WordPress 플러그인인 Jetpack에서 하루에도 몇십번씩 블로그가 연결안되었다 되었다 하는 알림을 날려와서 스트레스 잔뜩 받고 있었는데, 공유기 로그를 보다 보니 아래와 같은 오류가 나고 있었습니다.

Apr 11 23:01:29 kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
Apr 11 23:01:29 kernel: SQUASHFS error: squashfs_read_data failed to read block 0x187b0a6
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:01:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:03:29 kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
Apr 11 23:03:29 kernel: SQUASHFS error: squashfs_read_data failed to read block 0x187b0a6
Apr 11 23:03:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:03:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:05:29 kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
Apr 11 23:05:29 kernel: SQUASHFS error: squashfs_read_data failed to read block 0x187b0a6
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read data cache entry [187b0a6]
Apr 11 23:05:29 kernel: SQUASHFS error: Unable to read page, block 187b0a6, size 4f78

검색해봐도 직접적인 정보는 없고 flash memory가 망가졌다거나 펌웨어에 문제가 있다고 해서 일단 수동으로 펌웨어를 재설치를 해봤지만 동일 증상이 발생했습니다.

그래서 공장초기화를 했는데, 그래도 똑같은 현상이 발생하더군요.

그럼 공장초기화한김에 다시한번 펌웨어를 업데이트를 했더니 이젠 에러로그는 안납니다. -.- 펌웨어 설치가 잘못되었던 건지…

근데 지금 글을 쓰고 있는데도 연결이 안된다고 알림을 보내는 Jetpack은 대체 뭐냐…-.-

알고보니 4/11자로 펌웨어가 업데이트 되었었네요-.- 공장초기화하고 펌웨어 업데이트를 다시 해서 된게 아니라 그 시점에 새 펌웨어가 배포가 되었던 거네요.

그래서 그런가 조금 끊어짐 알림 메일은 덜 오는 거 같긴 한데 아직 완전히 없어지진 않네요…

2019년 4월 4일2019년 4월 4일

Synology NAS 218+ RAM 증설기…

안정적인 NAS 활용을 위해서 요즘 RAM값도 싸겠다 싶어서 RAM 증설을 하려고 알아보니 218+ 모델은 DDR3L 1866 모델이 들어간다고 하더군요. 다나와 등을 알아보니 죄다 중고 아니면 해외구매…-.-

귀찮아서 아마존에서 Timetec hynyx 8G DDR3L 1866 * 2개 모델을 구매했습니다. 보통 아마존 주문하면 10일 지나서 온 거 같은데 28일에 주문해서 3일에 받았으니 일주일도 안되서 물건이 와서 좀 놀랐습니다.

made for MAC이라고 써있는데 설마 맥이라고 전혀 생뚱맞은 스펙의 RAM을 쓰겠어 싶어서 주문했습니다.

8GB 두개가 얌전히 들어가 있습니다. 국내에서 램사면 거의 대부분 은박지로 싸고 뽁뽁이비닐로 둘러서 보내주던데 노트북용 세트라 그런가 케이스에 들어서 왔네요.

NAS를 분해해야 하는데 헤라라던가 마땅한 도구를 못찾아서 결국 분해에 실패… (금속제 가이드 부러뜨릴까봐 조마조마해서 결국 못함-.-)

그래서 일단 8GB라도 설치가 용이한 바깥쪽에 달았습니다.

그리고 기동…

나머지 8기가를 갈아끼려면 NAS를 거의 분해수준으로 해야 해서 주말에 해야 할 듯-.-

헤라를 사야 하나 고민중인데 이건 뭐 배송비가 더 나가는 상황이라 집을 뒤져보니…

이런 놈들이 나왔습니다.

파리바께스 케익 칼, 배스킨31과 하겐x스 아이스크림스푼…

가능할 것 같아 주말에 도전…

결국 주말까지 못참고 실행에 옮김.

오호..생각대로 파리바x트의 케익칼과 아이스크림 스푼이 제 역할을 해줘서 분리에 성공했습니다.

저 두 부분을 밀어내야 합니다. 금속제 가이드이지만 허약해서 금방 휘거나 부러질거 같더군요.

램슬롯이 가이드 안쪽에 위치하기 때문에 기판과 가이드를 다 뜯어내야 램을 설치할 수 있습니다.

다 뜯어내면 2GB가 장착된 슬롯이 보입니다. 왼쪽하단은 어제 장착한 8기가램입니다.

이제 다시 조립을 해줘야지요.

다 조립하고 켰는데 껌뻑거리기만 하고 nas인식도 안되고 부팅도 안되서 식겁했는데 다시 껐다 켰더니 정상동작합니다. 부적절항 종료가 발생했다는 메시지는 덤….

이제 좀 더 쾌적한 nas사용이 될려나요…??

2019년 3월 28일2019년 3월 28일

공유기는 공유기고 NAS는 NAS다…(?)

지난주부터 하루에 몇십번씩 jetpack은 연결끊김 알림이 오고, NAS는 접속이 되었다 안되었다 하고, 블로그도 마찬가지로 접속이 되었다 안되었다 하고….

let’sencrypt 인증서 만료 안내 메일이 와서 인증서 갱신을 하려고 했더니만 계속 접속실패떨어지고…

공유기도 몇번씩 껐다 켜주고 NAS도 몇번씩 재기동을 해줘도 현상은 나아지질 않아서…

스트레스 만빵인데 검색해보니 시놀로지 NAS에 router 설정하지 말고 수동으로 공유기에서 직접 포트포워딩을 해줘야 한다는 얘기가 보여서 밑져야 본전이니 해보자…

시놀로지 NAS의 제어판>외부 액세스>라우터구성에 이전에 설정했던 포트포워딩 항목들 죄다 지워버리고…
공유기에 포트포워딩항목에 다시 정리해서 등록했더니..

인증서 갱신도 잘되고, 하루에 30번이 넘게 오던 jetpack 연결끊김/연결 알람도 없고… NAS와 블로그 반응도 덜 버벅거리는 느낌마저 듭니다.

역시 공유기는 공유기의 역할을, NAS는 NAS의 역할을 시키는게 정론인것 같습니다.

2019년 2월 22일2019년 2월 23일

WordPress 요약글처리 및 child theme 생성

워드프레스로 글을 생성해서 메인페이지를 들어오면
사진이랑 글 내용 전체가 표시가 되어버려서 요약글로 보이게 하는 것을 이전에 어디서
뒤져보고 적용해놓고 까맣게 잊고 있었는데…

오늘 뜬금없이 Twenty Seventeen 테마가 업데이트 되었다고 해서
업데이트를 시도했더니 테마 파일을 커스터마이징해버린게 있어서
업데이트가 안되었습니다.

그래서 테마를 날리고 다시 테마 받아서 깔고 뻘짓을 하고 나서 찾아보니 테마 파일 자체를 고치지 말고 child theme를 만들어서 쓰는게 낫다는 얘기가 있었더군요… (뭘 알아야지…)

Twenty Seventeen 기준으로 작업했습니다. (혹 테마에 따라 다를 수도?)

일단 검색에 찾아본대로 child theme 디렉토리를 생성해 줬습니다.

style.css 와 functions.php를 아래 내용으로 생성

style.css

/*
  Theme Name: MyTwenty Seventeen Child Theme
  Template: twentyseventeen
*/

테마명은 대충 지어도 별 상관이 없는데 Template 명은 부모 테마명을 정확히 써줘야
하고, 이 주석문이 없어도 제대로 구동이 안되더군요.

functions.php

<?php
  function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/style.css', array( 'parent-style' ) );
  }
  add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
?>

요기까지 하면 일단 테마 생성은 되고 괸리자페이지>외모>테마에 가면 생성된 child theme 확인이 가능합니다.

child theme 디렉토리에 screenshot.png 를 채워 넣으면 미리보기 이미지로 보인다는데 귀찮아서 패스…

그리고 원래 하려고 했던 요약글 처리를 content.php 를 부모테마와 똑같이 child theme 에 디렉토리 만들어 주고 내용 수정.

즉, ../web/wordpress/wp-content/themes/twentyseventeen-child/template-parts/post/content.php 을 만들어야 한다는 것이죠.

부모 theme의 content.php를 복사해놓고 그걸 고칩니다.
entry-content 부분을 찾아 수정했습니다. (바탕색 다른 부분이 추가한 부분)

content.php

	<div class="entry-content">
		<?php
/* preview post 20190222 - start */
			if ( is_single() ) :
/* preview post 20190222 - end */		
				/* translators: %s: Name of current post */
				the_content(
					sprintf(
						__( 'Continue reading<span class="screen-reader-text"> "%s"</span>', 'twentyseventeen' ),
						get_the_title()
					)
				);

				wp_link_pages(
					array(
						'before'      => '<div class="page-links">' . __( 'Pages:', 'twentyseventeen' ),
						'after'       => '</div>',
						'link_before' => '<span class="page-number">',
						'link_after'  => '</span>',
					)
				);
/* preview post 20190222 - start */
			else :
			the_excerpt( sprintf(
			__( 'Continue reading<span class="screen-reader-text"> "%s"</span>', 'twentyseventeen' ),
			get_the_title()
			) );

			wp_link_pages( array(
			'before'      => '<div class="page-links">' . __( 'Pages:', 'twentyseventeen' ),
			'after'       => '</div>',
			'link_before' => '<span class="page-number">',
			'link_after'  => '</span>',
			) );
			endif;				
/* preview post 20190222 - end */		
		?>
	</div><!-- .entry-content -->

2019년 1월 17일2019년 2월 22일

Synology NAS, WordPress NGINX로 구동 설정

아무것도 모른 상태에서 블로그 살리겠다고 검색과 삽질을 통해 블로그를 구축은 어찌어찌 성공했는데…

php 5.2, php 7.0이 같이 돌고 있고, apache 2.2, apache 2.4 가 죄다 돌고 있어서 synology 자체에서 쓴는 nginx까지 세개가 돈다는 게 뭔가 좀 이상하다는 생각이 들더군요.

php 5.2는 phpadmin 종속이라 어쩔 수 없다고 치고, apache 2.2보다 2.4가 낫대서 깔다보니 쓸데없이 몇개씩 돌고 있어서 또 검색의 힘과 삽질의 근성으로 도전…

가상호스트의 http 백엔드 서버만 바꿔주면 되는 줄 알았더니 메인페이지만 나오고 서브페이지만 들어가면 404에러를 뱉어내더군요…

서버를 몇번씩 수정하고 재기동하고 난리를 쳐서 결국 성공하고 그 이력을 기록해 둡니다. (또 까먹을까봐)

더 헤매게 된 이유가 모델과 dsm버전이 다르면 환경도 다른 경우가 있나보더군요. 검색한 정보를 토대로 암만 찾아도 내껀 그런게 안나오는게 있고 하더라구요.

적용한 환경입니다.

모델 : DS218+
DSM 버전:DSM 6.2.1-23824 Update 4
사전에 가상호스트 등은 전부 설정해서 워드프레스가 멀쩡히 돌아가는 것 확인한 상태

/etc/nginx/app.d 에서 server.webstation-vhost.conf 읽기

가상서버를 여러개 돌린다면 항목중에 server_name 내도메인; 으로 되어있는 server { } 항목을 찾아서 include 로 시작해서 .conf로 끝나는 부분을 찾습니다.

include /usr/syno/etc/security-profile/tls-profile/config/vhost_b2944df6-4fe4-4afd-9211-f654ed87ce44.conf*;

…당연히 고유id니까 다 다른 값으로 채워졌겠죠.

다음으로 위에서 찾은 vhost_ 와 .conf를 제외한 고유아이디를 /usr/local/etc/nginx/conf.d 디렉토리에 user.conf.wordpress-permalink 파일을 생성합니다. (권한 문제로 su vim user.conf.wordpress-permalink 으로 실행해야 할 겁니다.)

location /{
         try_files $uri $uri/ /index.php?$args;
 }

위의 텍스트를 입력하면 됩니다.

이제 설정을 적용했으니 nginx를 재기동 해야합니다 :

sudo synoservice --restart nginx

apache 2.4를 삭제해도 잘 도는 걸 보면 멀쩡히 잘 되고 있음을 알 수 있습니다.

이제 php 5.6하고 apache 2.2를 지울 수 있는 방법을 찾아봐야지…

2019년 1월 14일2019년 2월 8일

Windows 10 OEM 라이센스키 확인 방법

(맨날 까먹어서 적어놔야 함…-.-)

언제부턴가 브랜드 노트북에서 윈도우즈10 시리얼을 안알려주고 복구영역으로만 되돌리게 해서 이런저런 이유로 복구영역 날려먹으면 난처한 상황이 되는데 예전에 어딘가에서 OEM 윈도우즈 키 확인 방법이라고 찾은 걸 적어 놓음. (브랜드에 따라 안되는 놈도 있을 지도?)

도스창(cmd, powershell)를 열고 다음 명령어를 입력 :

wmic path SoftwareLicensingService get OA3xOriginalProductKey
참고로 OEM이 아닌 윈도우즈를 설치하면 다음과 같이 나옴

2019년 1월 11일2019년 12월 6일

NAS에 개인도메인 설정하느라고 한 짓들

도메인(hemiani.com, jjumdol.com)
- 구매한 도메인에 ns설정 : ns11.dnszi.com
  ns22.dnszi.com
  ns37.dnszi.com
  ns53.dnszi.com
  ns77.dnszi.com
- 신청한 ddns서비스페이지에서(https://dnszi.com) A레코드를 도메인에 당시 IP 배정
- 고급관리에서 인증키발급 및 저장
공유기 : (공유기 밑에 NAS가 위치함)
- 포트포워딩 설정 : 443, 80
NAS
- 웹스테이션
  - 가상호스트 설정
    - 80/443
    - HSTS
    - Apache
    - PHP (7.0)
- 보안
  - 인증서 설정 : hemiani.com jjumdol.com (let’s encrypt)
- 작업스케줄러 :
  - /bin/wget -q -O – ‘http://ddns.dnszi.com/set.html?user=내아이디&auth=인증키&domain=도메인&record=’
  - 3시간마자 설정해도 큰 문제 없어보임
- phpMyAdmin
  - wp_option에 siteurl, home 설정변경
WordPress
- 설정

추가사항-.- 도메인 연결하니까 해킹시도가 그새 여러차례 들어와서 추가적인 조치를 함
1. 국가별 접속을 알아보기 위해 WP statistics 플러그인 설치 및 설정
2. NAS 보안에 “중국” IP 차단 (…죄다 중국발 해킹 시도-.-)

[카테고리:] Technic

SQUASHFS error – ASUS RT-AC68U

이것이 좋아요:

Synology NAS 218+ RAM 증설기…

이것이 좋아요:

공유기는 공유기고 NAS는 NAS다…(?)

이것이 좋아요:

WordPress 요약글처리 및 child theme 생성

이것이 좋아요:

Synology NAS, WordPress NGINX로 구동 설정

이것이 좋아요:

Windows 10 OEM 라이센스키 확인 방법

이것이 좋아요:

NAS에 개인도메인 설정하느라고 한 짓들

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요:

이 글 공유하기:

이것이 좋아요: