3. umount 후 다시 mount 설정하기 $ sudo umount -l /data $ sudo mount -t nfs -o vers=3 192.168.0.254:nas1 /data
3. mount 결과 확인하기 (vers=3 인지 vers=4 인지 확인하기 ) $ sudo mount ... 192.168.0.254:nas1 on /data type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys, mountaddr=192.168.0.254,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=192.168.0.254)
참고 : fstab 구문 구조 설명
(예문) 192.168.20.254:/nasvolume1 /data nfs defaults 1 2 (설명) 192.168.20.254 = {filesystem-id} ip 또는 url. NAS 또는 파일시스템에 접근할 수 있는 위치정보 :/nasvolume1 = :/{devicename} NAS 또는 파일시스템에 준비된 공유디바이스 정보, 공유폴더이름에 해당한다 /data = {mount-point} 리눅스 (클라이언트측)에 준비된 디렉토리 (폴더) 정보 여기에 NAS 공유 디바이스를 연결한다 nfs = {filesystem-type} 여러 종류의 파일시스템 타입이 있다 ext, ext2, ext3, ext4, iso9660, nfs, swap, ufs, vfat, msdos, ntfs, hpfs, sysv, ramdisk 등이 있고, 일반적으로 네트워크상의 NAS는 nfs를 표준으로 사용한다 그 외, 클라이언트측이나 파일시스템측의 특성에 맞춰 타입을 써줘야할 경우가 있다 default = {mount-option} default : rw, nouser, auto, exec, suid 속성을 모두 갖는다 auto / noauto : 부팅시 자동으로 마운트한다 / 안한다 exec / noexec : 실행파일의 실행을 허용한다 / 안한다 suid / nosuid : SetUID, SetGID 사용을 허용한다 / 안한다 ro / rw : 읽기전용 / 일기쓰기 허용한다 user / nouser : 일반사용자 계정으로 마운트를 허용한다 / 안한다(root만 허용) quota / noquota : Quota(용량제한) 설정이 가능 / 불가능하다 1 = {dump-option} 0 / 1 : dump 불가능 / 가능 2 = {fsck:file sequence check option} 0 : 무결성 검사를 하지 않는다 1 : 1순위 검사대상이 된다 (주로 root (/)에 해당 2 : 2순위 대상이 된다 ( root 폴더 이외의 경우에 해당)
command(type 1) : $ route or $ route -n or $ netstat -nr 목적지 IP 가 어느 Interface와 Gateway로 전달되는지 표시한다
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 211.111.211.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 172.16.10.1 255.0.0.0 UG 0 0 0 eth1
172.16.10.0 * 255.255.255.0 U 0 0 0 eth1
211.111.211.0 * 255.255.255.128 U 0 0 0 eth0
192.168.0.0 172.16.10.1 255.255.0.0 UG 0 0 0 eth1
$
$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 211.111.211.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 172.16.10.1 255.0.0.0 UG 0 0 0 eth1
172.16.0.0 172.16.10.1 255.240.0.0 UG 0 0 0 eth1
172.16.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
211.111.211.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0
192.168.0.0 172.16.10.1 255.255.0.0 UG 0 0 0 eth1
$
command(type 2) : $ ip route show or $ ip route list 내용은 동일하고 표현방법이 조금 다르다
$ ip route show
default via 211.111.211.1 dev eth0
10.0.0.0/8 via 172.16.10.1 dev eth1
172.16.0.0/12 via 172.16.10.1 dev eth1
172.16.10.0/24 dev eth1 proto kernel scope link src 172.16.10.45
211.111.211.0/25 dev eth0 proto kernel scope link src 183.111.198.45
192.168.0.0/16 via 172.16.10.1 dev eth1
$
$ ip route list
default via 211.111.211.1 dev eth0
10.0.0.0/8 via 172.16.10.1 dev eth1
172.16.0.0/12 via 172.16.10.1 dev eth1
172.16.10.0/24 dev eth1 proto kernel scope link src 172.16.10.45
211.111.211.0/25 dev eth0 proto kernel scope link src 183.111.198.45
192.168.0.0/16 via 172.16.10.1 dev eth1
$
리눅스 최초 설정으로 default gateway 경로가 없을 때 또는 gateway route ip가 바뀌었을 때 기존 경로 후 삭제 후 추가한다. command(type 1) : $ route add default gw (gateway-ip-address) (interface-name)
위에 설명한 일반적인 IPv4 주소체계처럼, A/B/C Class로 분류하고, 점으로 4개의 영역을 분리한 표기 방식을 Classful 이라고 말한다.
반대로, Classless는, 규격화된 구분없이 32비트 2진수로 표시하는 방식을 말한다.
Classfull Addressing=클래스풀 주소체계=클래스 있는 주소체계
FLSM(Fixed Length Subnet Masks) vs VLSM(Variable Length Subnet Masks)
Classful Addresing에서 정의한 Class 기준을 FLSM 이라 하고,
VLSM은, 특정 class 네트워크 (예를 들어 C class)를 사용할 때, 한 네트워크의 호스트 갯수가 고정되어, 사용하지 않는 호스트만큼 IP 주소의 낭비가 생긴다. IP 주소의 낭비를 줄이기 위해 SubnetMask(또는 Prefix)를 가변으로 조절하여, 네트워크를 잘게 쪼개서, IP 주소가 필요한 만큼의 네트워크로 나눠서 사용하는 것을 VLSM(Variable Length Subnet Mask)를 사용한다고 말한다.
Subnet (서브넷) : 넷마스크의 마스킹 비트수를 늘려서 네트워크 갯수를 늘리고, 각 네트워크 당 호스트 수를 줄이는 것 ( /24 --> /25 --> /26)
Supernet (슈퍼넷) : 한 네트워크의 호스트수를 default class보다 늘리기 위해, 마스킹 비트수를 줄이는 것 (/24 --> /23 --> /22)
해마다 몇차례씩 주변에서 랜섬웨어 사고 소식을 접하는 경우가 심심찮게 있는데, 평상시 철저하게 보안 솔루션을 사용하는대도, 잠깐의 방심으로 인해 랜섬웨어에 걸렸다는 얘길 듣곤 한다.
랜섬웨어 걸렸을 때 응급조치방법과 랜섬웨어 예방방법을 알아보자.
1. 백업을 해두지 않아서, 랜섬웨어 걸린 컴을 포기할 수 없다면,
기업이라면, 한국인터넷진흥원 사이버민원센터, Tel: 118, boho.or.kr)에, 개인이라면, 경찰청 사이버안전국(Tel: 02-3150-2659,cyber.go.kr)에, 위 전문가에게 먼저 먼저 연락해서 도움을 청해보자.
정부기관보다는 일반사업자인 전문가들의 도움을 받고 싶다면, 한국랜섬웨어침해대응센터 를 운영하는 보안전문 솔루션 기업들도 있다.
랜섬웨어의 종류가 많이 알려지고, 변종이 아니라면, 100% 복구는 안되더라도 일부라도 복구할 방법이 있을 가능성이 있다.
랜섬웨어가 변종이고 최신 기법으로 만들어진것이라면 도움을 못받을 수도 있다. 그럴땐 해커에게 돈(비트코인 등)을 주고 복구툴을 받는 방법밖에 없는데, 이마저도 100% 복구는 안될 수 있다는 점을 인식하자. 그리고, 한번 뚫린 경로는 해커가 또 뚫고 들어올 수 있다. 해커에게 돈을 지불해서, 해커의 활동비를 보태주면, 그 활동비를 이용해서, 해킹 시스템을 확장하고, 또 어딘가에서 해킹 피해를 유발하며, 다시 나를 해킹하지 않으리란 보장이 없으니, 악순환의 반복이 되지 않을까.
2. 랜섬웨어 걸린 컴을 포기할 수 있다면,
중요 데이터가 백업이 되어있다거나, 데이터를 포기해도 큰 피해가 아니라면, 과감하게 컴을 포기하는 것이 정신건강에 이롭다. , PC 전문가의 도움을 받아서 안전한 방법으로 디스크를 포맷하고, PC의 보안상태를 강화해서, 소는 잃었지만 외양간을 고쳐서 쓰자. PC 전문가의 도움을 받기 어렵고, 해킹당한 디스크를 다시 사용하는게 불안하다면, 디스크를 파쇄시키고, 새 디스크로 PC 새로 설치하자. 그리고, PC 보안상태를 강화하자.
3. PC보안상태를 강화해보자.
윈도우서버라면, 첨부한 "서버용 보안취약점 점검 가이드"를 이용해서 세팅할 수 있다. 윈도10 등 PC라면, 첨부한 "윈도10PC의 보안점검가이드"를 이용해서 세팅할 수 있다. 해커침투시 주변 PC로 파급이 빠르게 되는 SMB프로토콜로 PC간 파일공유나 폴더공유는 안하는 것이 좋다.
4. NAS 또는 클라우드를 활용하자.
사내 협업 업무를 위해 공유해야만 하는 데이터는, 백업과 보안기능이 있는 NAS시스템을 사용하거나, GOOGLE이나 OFFICE 등의 클라우드 드라이브를 사용하자.
NAS시스템에는 백업 복구 기능이 있고, 바이러스 차단 기능과 IP Address 제한 기능이 있으면 더 좋겠다. 클라우드 드라이브는 파일의 저장 방식이 달라서 랜섬웨어에 걸릴 확률이 낮고, 버전기능이 있다면 이전 버전의 파일 상태로 복원도 할 수 있다.
5. 윈도 OS가 아닌 PC의 보안점검 방법
윈도OS가 보급율이 높고, 취약점이 많기때문에 타OS에 비해 랜섬웨어나 바이러스 등 해커의 공격 타겟이 더 많이 되는 것이 현실이다. 그렇더라도 맥북, 리눅스 등 윈도OS가 아닌 PC의 경우에도 보안 취약점이 존재하기 때문에 보안점검과 관리는 필요하다. OS 공급자가 제공하는 최신 업데이트 및 패치를 정기적으로 확인하고, 적용해야 한다. 방화벽과 백신 프로그램이 있다면 설치하고, 윈도와 동일한 수준으로 관리하는 것이 좋다.
사족, 백신도 있고, 방화벽도 있고, 전문엔지니어도 있어도, 랜섬웨어에 걸려서 고생할 수가 있다. 해커는 최신의 보안취약점이 발견되면 백신업체 보다 한발 더 빠르게 활용해서 작업하려하기 때문에. 나름대로 문서를 보면서 보안설정을 했지만, 그래도 불안하다면, ... 댓글을 상세히 남겨주면 전문가를 소개해줄게요. 힘내세요.
사족2. 내가 랜섬웨어 걸려본적이 없어서 써보지는 않았지만, 많이 알려진 랜섬웨어의 복구툴을 제공하는 곳이 있어서 소개링크를 남겨둔다.
장애 증상은, 어느날 갑자기, 서버 전원이 저절로 꺼져버립니다. 전원버튼을 눌러서 Power On을 하면, 잠시 후 다시 꺼집니다.
서버가 켜졌을 때 로그들을 살펴보니, "Power key pressed" 그리고, "Powering Off" 메시지가 나타나면서 서버가 꺼집니다.
$ sudo cat /var/log/messages | grep Power
Jun 15 14:20:33 localhost systemd-logind: Power key pressed.
Jun 15 14:20:33 localhost systemd-logind: Powering Off...
Jun 15 14:35:04 localhost kernel: input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
Jun 15 14:35:04 localhost kernel: ACPI: Power Button [PWRF]
Jun 15 14:35:10 localhost systemd-logind: Watching system buttons on /dev/input/event0 (Power Button)
Jun 15 14:46:27 localhost systemd-logind: Power key pressed.
Jun 15 14:46:27 localhost systemd-logind: Powering Off...
Jun 15 14:54:14 localhost kernel: input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
Jun 15 14:54:14 localhost kernel: ACPI: Power Button [PWRF]
Jun 15 14:54:20 localhost systemd-logind: Watching system buttons on /dev/input/event0 (Power Button)
Jun 15 15:47:19 localhost systemd-logind: Power key pressed.
Jun 15 15:47:19 localhost systemd-logind: Powering Off...
원인은, 서버 전원모듈 어딘가에 고장이거나, 전원부 케이블 커넥터 불량이 의심됩니다. 하드웨어 A/S를 받아야하지만, 이중화되어 있지않은 싱글 서버이다보니, 서비스를 어떻게든 살려야 했습니다.
임시조치로, Power key 메시지를 OS에서 무시하는 옵션을 사용해봅니다.
$ sudo vi /etc/systemd/logind.conf
HandlePowerKey=ignore
$
또는
$ sudo echo "HandlePowerKey=ignore" >> /etc/systemd/logind.conf
그리고, 서비스 데몬을 재시작합니다.
$ sudo systemctl restart systemd-logind
결과는 . . . 성공적입니다. Power key pressed 메시지는 계속 발생하지만, Powering Off 메시지는 더이상 발생하지 않고, 서버 전원이 꺼지지 않습니다.
$ sudo cat /var/log/messages | grep Power
Jun 15 17:03:50 localhost systemd-logind: Power key pressed.
Jun 15 18:59:16 localhost systemd-logind: Power key pressed.
Jun 15 19:02:15 localhost systemd-logind: Power key pressed.
Jun 15 19:10:08 localhost systemd-logind: Power key pressed.
Jun 15 19:23:13 localhost systemd-logind: Power key pressed.
Jun 15 19:27:22 localhost systemd-logind: Power key pressed.
Jun 15 20:45:27 localhost systemd-logind: Power key pressed.
Jun 15 21:51:18 localhost systemd-logind: Power key pressed.
Jun 15 22:57:40 localhost systemd-logind: Power key pressed.
Jun 15 23:00:03 localhost systemd-logind: Power key pressed.
Jun 15 23:03:40 localhost systemd-logind: Power key pressed.
Jun 15 23:09:34 localhost systemd-logind: Power key pressed.
Jun 15 23:12:33 localhost systemd-logind: Power key pressed.
Jun 15 23:18:06 localhost systemd-logind: Power key pressed.
Jun 15 23:20:43 localhost systemd-logind: Power key pressed.
Jun 15 23:22:07 localhost systemd-logind: Power key pressed.
Jun 16 00:02:25 localhost systemd-logind: Power key pressed.
Jun 16 00:23:59 localhost systemd-logind: Power key pressed.
Jun 16 00:35:15 localhost systemd-logind: Power key pressed.
. . .
하지만, 서버 상태는 여전히 고장이 있는 것이기 때문에, 당분간은 이 상태로 서버를 살려두고, 하드웨어 A/S 신청을 하고, 서버교체 일정에 맞춰 작업 공지를 띄웠습니다.
a few hours later . . . .
작업을 마치고 집으로 돌아가는 길에~ 서버 엔지니어의 가상현실 "스탯창"에 알림이 뜹니다.
차 바꿀때 됬는데, 전기자동차 지금 사도 될까 고민이다. 전기차가 환경공해 줄이는데 도움이 된다니 나도 일조하는 의미로 참여하고 싶기도 한데, 전기충전소 이용의 불편문제도 있고, 충전중 화재사고도 자주 있고, 가솔린 경유 차 대비 고장율도 적을거라 하지만 배터리계통 문제 생기면 교체 수리 비용이 차값의 거의 절반이 나간다는 얘기에 주저하게 된다. 여러가지 문제가 제대로 해결 안되고 있는데도 친환경차를 이용하도록 세상이 부추기는 형국이다.
정부나 환경단체는 당연히 전기차 증가를 반길테지만 자동차 제조회사는 왜 이리 적극적으로 투자하고 밀어붙일까 차를 파는 입장에선 가솔린차나 경유차 파는거나 전기차 수소차 파는거나 수익에서 별 차이 없을거고, 대다수 사람들이 전기차 좋다고 두대 세대 더 사는 것도 아니라서 영업매출이나 수익면에서 크게 좋아보이는것도 없는데 말이다.
세계적 추세를 말하는 사람들의 얘기를 따라가다보면, 어렴풋이 큰 그림이 보인다. 전기차 1위 기업 테슬라를 시작으로 유명 자동차 회사들이 주도하는 신기술의 주제가 한 곳으로 집중된다. 자동차에 자율주행기술을 넣고, 보다 낳은 자율주행을 위해 고성능 신기술의 AI 컴퓨팅기술을 연결한다. 사람이 운전하는 걸 더 편하게 하는 것을 넘어서서 아예 사람이 운전 안해도 되는 자동차를 목표로 기술은 발전하고 있다. 그 너머에 자동차 기업이 추구하는 자율주행자동차의 시장을 넘어 더 큰 새로운 시장경제가 있다.
그것이 [공유 모빌리티 시장] 이라한다.
소위 자가용이라 불리는 자동차들이 넘쳐나고 있는데, 운행하지 않는 차들을 우버 쏘카 자동차렌트분야에 활용해서 경제활동을 하게 만든단다. 차주도 돈을 벌고 자동차회사 혹은 공유사업자도 돈을 벌게되는 큰 시장을 본다.
여기에는 다양한 관련 기술들이 많이 필요하게 되어,
자동차 업계뿐만 아니라 IT기업들과 하드웨어 개발 제조기업들, 서비스사업자들이 가세하여 대규모 자율주행자동차 산업생태계를 만들어가고 있단다.
배터리를 사용한 최초의 전기자동차는 1873년이라고 하는데, 배터리무게와 충전시간문제 등의 이유로 대량보급은 안되었고, 소규모 수공업으로만 만들어져왔고,
최초의 전기자동차는 1824년 헝가리의 아이노스 예들리크(Ányos Jedlik) 마차에 장착한 전기자동차 (추정)
성능좋은 기계화된 최초의 내연기관 자동차가 나온 것이 1882년 다임러와 마이바흐의 제작품이라 한다.
1885년 독일 메르세데스 벤츠의 최초의 가솔린엔진 자동차 '페이턴트 모터바겐'
현대에 들어 공해문제의 대안으로 1990년대부터 다시 전기차가 부각되기 시작했다. 이 당시까지만 해도 단순하게 화석연료를 공해적은 전기로 대체한다는 수준의 발상이었는데, 이제 '공유' 라는 주제와 연결되면서 거대한 새로운 산업이 탄생하게 된 것. 인간의 상상력이란 얼마나 무궁무진한걸까, 아...
레드썬, 다시 현실로 돌아와서, 과연, 완전 자율주행의 시대는 언제 올까 그럼, 지금 나는 어떤 차를 사야할까 테슬라? 아이오닉?