Neil's Note

前情提要: 公司舊有主機當初用 vmware 建立時分配到 100G，然而實際上能用的只有(/dev/sda1)50G，但時間久了，容量不夠用，這時候從 vmware 介面去加大硬碟之後，一樣沒辦法將 /dev/sda1 變大。 # fdisk -l 處理方法與過程: 依照以前在 aws 上面的處理經驗，理論上是使用 growpart /dev/sda 1 resize2fs /dev/sda1 就可以解決，然侯事情不是我想的這麼簡單，過程中都出現 NO CHANGE 看起來是行不通了，於是！ 查了一下各路文章發現，需要把 partition table 整個洗掉，重新建立新的 partition table。 過程: 第一件最重要的事情，就是 備份 。如果不備份，失敗的話就可以跑路了XD 再來使用指令 # fdisk /dev/sda 使用了之後，會進去 fdisk 的互動模式，接著介紹指令 p => 印出目前的指定硬碟的分割表 d => 刪除指定的分割，ex: 輸入1就代表刪除 /dev/sda1 的 partition 的位置 (使用 d 的話，後面會問你要刪除哪個硬碟裝置代號) n => 新增指定的分割，ex: 輸入1就代表新增 /dev/sda1 的 partition 的位置 (使用 n 的話，後面會問你這個新的硬碟裝置代號，sector( 磁區 ) 要從哪裡開始) w => 寫入 partition table 以下是大概會出現 moses@xxx:~$ sudo su - root@xxx:~# fdisk -l Disk /dev/sda: 150 GiB, 161061273600 bytes, 314572800 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x9e13d85c Device Boot Start End Sectors Size Id T...

在每次做 apt upgrade 時，總是會出現以下類似以下的錯誤 dpkg: error processing package linux-image-4.4.0-121-generic (--configure): subprocess installed post-installation script returned error exit status 2 dpkg: dependency problems prevent configuration of linux-image-extra-4.4.0-121-generic: linux-image-extra-4.4.0-121-generic depends on linux-image-4.4.0-121-generic; however: Package linux-image-4.4.0-121-generic is not configured yet. dpkg: error processing package linux-image-extra-4.4.0-121-generic (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-image-generic: linux-image-generic depends on linux-image-4.4.0-121-generic; however: Package linux-image-4.4.0-121-generic is not configured yet. linux-image-generic depends on linux-image-extra-4.4.0-121-generic; however: Package linux-image-extra-4.4.0-121-generic is not configured yet. dpkg: error processing package linux-image-generic (--configure): dependency problems ...

ref:  https://forums.centos.org/viewtopic.php?t=68077#p285857 https://blog.51cto.com/kindit/1563889 https://cloud.tencent.com/developer/article/1463094 yum install centos-release-scl-rh yum install devtoolset-7-toolchain scl enable devtoolset-7 bash 就可以用比較新的 devtool 去編譯檔案了!

解法: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 762E3157. Ref:  https://travis-ci.community/t/then-sudo-apt-get-update-failed-public-key-is-not-available-no-pubkey-6b05f25d762e3157-in-ubuntu-xenial/1728

由於發現主機CPU時常高達400%.. 所以用先檢查一下 top => press c 或是直接 ps aux | grep redis2 發現是一隻 ./redis2 的程式 ./redis2 --donate-level 1 -o ve01.kieuanilam.me:5555 -u tt2re -p tt2re -k -B 大概追查了一下 這個形式蠻像是門羅幣挖礦在用的格式 後來去看一下相關的文章基本上可以肯定就是在挖門羅幣了 https://blog.csdn.net/qq_39919755/article/details/90258890 https://blog.csdn.net/m0_37847558/article/details/93074293 https://kknews.cc/zh-tw/tech/kbmmx98.html 後來直接使用 kill {pid} -9 直接停止 但發現變成了 zombie process (ref:  https://yq.aliyun.com/articles/34967 ) 但沒幾天又被打開挖礦程式，後來使用 find / -name redis2 發現檔案是在 redis 的 container 進去 redis 的 container 看了一下 發現裡面的 authorized_keys 內有個不知名的 key 感覺就是這個了 看起來攻擊手法是透過 redis container 去挖礦 後來改成直接在 local 安裝 redis-server 因為 docker 會讓防火牆設定直接無效 除非特別針對 DOCKER 或是 DOCKER-USER 這個角色去設定 (ref:  https://docs.docker.com/network/iptables/ ) 中間跑去檢查 /etc/passwd 有沒有多可疑用戶 跑去目前所有既有的用戶去看有沒有被新增奇怪的 ssh key 還好最後有找到!

一般讀檔的方式 $handler = fopen("file.csv"); while (($line = fgets($handler)) !== false) { // 執行相關邏輯 fwrite($handler, "test\r\n"); } fclose($handler); 物件化讀檔的方式 $filepath = "test.tsv"; $file = new SplFileObject($filepath); while (!$file->eof()) { // 執行相關邏輯 $line = rtrim($file->fgets()); $file->fwrite("12345"); } $file = null; 這樣感覺 code 有比較好看一些 XD Ref: https://stackoverflow.com/questions/13246597/how-to-read-a-large-file-line-by-line https://www.php.net/manual/en/splfileobject.fwrite.php https://www.php.net/manual/en/class.splfileobject.php