18.4 systemd-journald.service 簡介
過去只有rsyslogd 的年代中，由於rsyslogd 必須要開機完成並且執行了rsyslogd 這個daemon 之後，登錄文件才會開始記錄。所以，核心還得要自己產生一個klogd 的服務， 才能將系統在開機過程、啟動服務的過程中的信息記錄下來，然後等rsyslogd 啟動後才傳送給它來處理～ 現在有了systemd 之後，由於這玩意兒是核心喚醒的，然後又是第一支執行的軟件，它可以主動調用systemd-journald 來協助記載登錄文件～ 因此在開機過程中的所有信息，包括啟動服務與服務若啟動失敗的情況等等，都可以直接被記錄到systemd-journald 裡頭去！ 不過systemd-journald 由於是使用於內存的登錄文件記錄方式，因此重新開機過後，開機前的登錄文件信息當然就不會被記載了。為此，我們還是建議啟動rsyslogd 來協助分類記錄！也就是說， systemd-journald 用來管理與查詢這次開機後的登錄信息，而rsyslogd 可以用來記錄以前及現在的所以數據到磁盤文件中，方便未來進行查詢喔！ Tips雖然systemd-journald所記錄的數據其實是在內存中，但是系統還是利用文件的型態將它記錄到/run/log/下面！不過我們從前面幾章也知道， /run在CentOS 7其實是內存內的數據，所以重新開機過後，這個/run/log下面的數據當然就被刷新，舊的當然就不再存在了！ 18.4.1 使用journalctl 觀察登錄信息 那麼systemd-journald.service 的數據要如何叫出來查閱呢？很簡單！就通過journalctl 即可！讓我們來瞧瞧這個指令可以做些什麼事？ [root@study ~]# journalctl [-nrpf] [–since TIME] [–until TIME] _optional 选项与参数： 默认会秀出全部的 log 内容，从旧的输出到最新的讯息 -n ：秀出最近的几行的意思～找最新的信息相当有用 -r ：反向输出，从最新的输出到最旧的数据 -p ：秀出后面所接的讯息重要性排序！请参考前一小节的 rsyslogd 信息 -f ：类似 tail -f 的功能，持续显示 […]
Go 語言很好很強大，但我有幾個問題想吐槽
Go 是一門非常不錯的編程語言。然而，我在公司的Slack 編程頻道中對Go 的抱怨卻越來越多（猜到我是做啥了的吧？），因此我認為有必要把這些吐槽寫下來並放在這裡，這樣當人們問我抱怨什麼時，我給他們一個鏈接就行了。 先聲明一下，在過去的一年裡，我大量地使用Go語言開發命令行應用程序、scc、lc和API。其中既有供客戶端調用的大規模API，也有即將在https://searchcode.com/使用的語法高亮顯示器。 我這些批評全部是針對Go 語言的。但是，我對使用過的每種語言都有不滿。我非常贊同下面的話： “世界上只有兩種語言：人們抱怨的語言和沒人使用的語言。” —— Bjarne Stroustrup 1 不支持函數式編程 我並不是一個函數式編程狂熱者。說到Lisp 語言，我首先想到的是語言障礙。 這可能是Go 語言最大的痛點了。與大部分人不同，我不希望Go 支持泛型，因為它會為多數Go 項目帶來不必要的複雜性。我希望Go 語言支持適用於內置切片和Map 的函數式方法。切片和Map 具有通用性，並且可以容納任何類型，從這個意義上講，它們已經非常神奇。在Go 語言中只有利用接口才能實現類似效果，但這樣一來將喪失安全性和速度。 例如，請考慮下面的問題。 給定兩個字符串切片，找出二者都包含的字符串，並將其放入新的切片以備後用。 複製代碼 existsBoth := []string{} for _, first := range firstSlice { for _, second := range secondSlice { if first == second { existsBoth = append(existsBoth, proxy) break } } […]
本博客Nginx 配置之安全篇
之前有細心的朋友問我，為什麼你的博客副標題是「專注WEB 端開發」，是不是少了「前端」的「前」。我想說的是，儘管我從畢業到現在七年左右的時間一直都在專業前端團隊從事前端相關工作，但這並不意味著我的知識體係就必須局限於前端這個範疇內。現在比較流行「全棧工程師」的概念，我覺得全棧意味著一個項目中，各個崗位所需要的技能你都具備，但並不一定意味著你什麼都需要做。你需要做什麼，更多是由能力、人員配比以及成本等各個因素所決定。儘管我現在的工作職責是在WEB 前端領域，但是我的關注點在整個WEB 端。 我接觸過的有些前端朋友，從一開始就把自己局限在一個很小的範圍之中，這在大公司到也無所謂，大公司分工明確，基礎設施齊全，你只要做好自己擅長的那部分就可以了。但是當他們進入創業公司之後，會發現一下子來了好多之前完全沒有接觸過的東西，十分被動。 去年我用Lua + OpenResty替換了線上千萬級的PHP + Nginx服務，至今穩定運行，算是前端之外的一點嘗試。我一直認為學習任何知識很重要的一點是實踐，所以我一直都在折騰我的VPS，進行各種WEB安全、優化相關的嘗試。我打算從安全和性能兩方面介紹一下本博客所用Nginx的相關配置，今天先寫安全相關的。 隱藏不必要的信息 大家可以看一下我的博客請求響應頭，有這麼一行server: nginx，說明我用的是Nginx服務器，但並沒有具體的版本號。由於某些Nginx漏洞只存在於特定的版本，隱藏版本號可以提高安全性。這只需要在配置裡加上這個就可以了： server_tokens off; 如果想要更徹底隱藏所用Web Server，可以修改Nginx源碼，把Server Name改掉再編譯，具體步驟可以自己搜索。需要提醒的是：如果你的網站支持SPDY，只改動網上那些文章寫到的地方還不夠，跟SPDY有關的代碼也要改。更簡單的做法是改用Tengine這個Nginx的增強版，並指定server_tag為off或者任何想要的值就可以了。另外，既然想要徹底隱藏Nginx，404、500等各種出錯頁也需要自定義。 同樣，一些WEB語言或框架默認輸出的x-powered-by也會洩露網站信息，他們一般都提供了修改或移除的方法，可以自行查看手冊。如果部署上用到了Nginx的反向代理，也可以通過proxy_hide_header指令隱藏它： proxy_hide_header X-Powered-By; 禁用非必要的方法 由於我的博客只處理了GET、POST 兩種請求方法，而HTTP/1 協議還規定了TRACE 這樣的方法用於網絡診斷，這也可能會暴露一些信息。所以我針對GET、POST 以及HEAD 之外的請求，直接返回了444 狀態碼（444 是Nginx 定義的響應狀態碼，會立即斷開連接，沒有響應正文）。具體配置是這樣的： NGINXif ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; } 合理配置響應頭 我的博客是由自己用ThinkJS 寫的Node 程序提供服務，Nginx 通過proxy_pass 把請求反向代理給Node 綁定的IP 和端口。在最終輸出時，我給響應增加了以下頭部： NGINXadd_header Strict-Transport-Security “max-age=31536000”; add_header X-Frame-Options deny; add_header X-Content-Type-Options […]
搭建 Docker 环境
安装 Docker Docker 软件包已经包括在默认的 CentOS-Extras 软件源里。因此想要安装 docker，只需要运行下面的 yum 命令： yum install docker-io -y 直接yum安装，安装成功后查看版本 docker -v 启动docker service docker start 设置开机启动 chkconfig docker on 配置 Docker 因为国内访问 Docker Hub 较慢, 可以使用腾讯云提供的国内镜像源, 加速访问 Docker Hub 依次执行以下命令 echo “OPTIONS=’–registry-mirror=https://mirror.ccs.tencentyun.com'” >> /etc/sysconfig/docker systemctl daemon-reload service docker restart Docker 的简单操作 任务时间：10min ~ 20min 下载镜像 下载一个官方的 CentOS 镜像到本地 docker pull […]
优化了du性能的hadoop 2.8.1
性能提升1000+倍。 原理是使用df 代替du， wget https://www.strongd.net/dl/hadoop-common-2.8.1.jar -C /usr/local/hadoop-2.8.1/share/hadoop/common/ wget https://www.strongd.net/dl/mydu -C /usr/bin/ chmod a+x /usr/bin/mydu 然后重启hadoop就可以了。
Jenkins 环境搭建
Jenkins 简介 Jenkins 是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。 Java 安装 首先我们需要准备 Java 环境，使用下面命令来安装 Java： yum -y install java-1.8.0-openjdk-devel Jenkins 安装 为了使用 Jenkins 仓库，我们要执行以下命令： sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm –import https://pkg.jenkins.io/redhat-stable/jenkins.io.key 如果您以前从 Jenkins 导入过 key，那么 rpm –import 将失败，因为您已经有一个 key。请忽略，继续下面步骤。 安装 接着我们可以使用 yum 安装 Jenkins： yum -y install jenkins 启动 Jenkins 任务时间：5min ~ 10min 启动 启动 Jenkins 并设置为开机启动： systemctl start jenkins.service chkconfig jenkins on […]
搭建 Hadoop 伪分布式环境
软硬件环境 CentOS 7.2 64位 OpenJDK-1.7 Hadoop-2.7 关于本教程的说明 云实验室云主机自动使用root账户登录系统，因此本教程中所有的操作都是以root用户来执行的。若要在自己的云主机上进行本教程的实验，为了系统安全，建议新建一个账户登录后再进行后续操作。 安装 SSH 客户端 任务时间：1min ~ 5min 安装SSH 安装SSH： sudo yum install openssh-clients openssh-server 安装完成后，可以使用下面命令进行测试： ssh localhost 输入root账户的密码，如果可以正常登录，则说明SSH安装没有问题。测试正常后使用exit命令退出ssh。 安装 JAVA 环境 任务时间：5min ~ 10min 安装 JDK 使用yum来安装1.7版本OpenJDK： sudo yum install java-1.7.0-openjdk java-1.7.0-openjdk-devel 安装完成后，输入java和javac命令，如果能输出对应的命令帮助，则表明jdk已正确安装。 配置 JAVA 环境变量 执行命令: 编辑 ~/.bashrc，在结尾追加： export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk 保存文件后执行下面命令使JAVA_HOME环境变量生效: source ~/.bashrc 为了检测系统中JAVA环境是否已经正确配置并生效，可以分别执行下面命令: java -version $JAVA_HOME/bin/java […]
Facebook针对hbase的优化方案分析
使用hbase的目的是为了海量数据的随机读写，但是在实际使用中却发现针对随机读的优化和gc是一个很大的问题，而且hbase的数据是存储在Hdfs，而Hdfs是面向流失数据访问进行设计的，就难免带来效率的下降。下面介绍一下Facebook Message系统在HBase online storage场景下的一个案例（《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011），最近他们在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他们在使用HBase中遇到的一些问题和解决方案。该论文首先讲了Facebook的分析方法包括tracing/analysis/simulation，FM系统的架构和文件与数据构成等，接下来开始分析FM系统在性能方面的一些问题，并提出了解决方案。 FM系统的主要读写I/O负载 Figure 2描述了每一层的I/O构成，解释了在FM系统对外请求中读占主导，但是由于logging/compaction/replication/caching导致写被严重放大。 HBase的设计是分层结构的，依次是DB逻辑层、FS逻辑层、底层系统逻辑层。DB逻辑层提供的对外使用的接口主要操作是put()和get()请求，这两个操作的数据都要写到HDFS上，其中读写比99/1（Figure 2中第一条）。 由于DB逻辑层内部为了保证数据的持久性会做logging，为了读取的高效率会做compaction，而且这两个操作都是写占主导的，所以把这两个操作（overheads）加上之后读写比为79/21（Figure 2中第二条）。 相当于调用put()操作向HBase写入的数据都是写入了两份：一份写入内存Memstore然后flush到HFile/HDFS，另一份通过logging直接写HLog/HDFS。Memstore中积累一定量的数据才会写HFile，这使得压缩比会比较高，而写HLog要求实时append record导致压缩比（HBASE-8155）相对较低，导致写被放大4倍以上。 Compaction操作就是读取小的HFile到内存merge-sorting成大的HFile然后输出，加速HBase读操作。Compaction操作导致写被放大17倍以上，说明每部分数据平均被重复读写了17次，所以对于内容不变的大附件是不适合存储在HBase中的。由于读操作在FM业务中占主要比例，所以加速读操作对业务非常有帮助，所以compaction策略会比较激进。 HBase的数据reliable是靠HDFS层保证的，即HDFS的三备份策略。那么也就是上述对HDFS的写操作都会被转化成三倍的local file I/O和两倍的网络I/O。这样使得在本地磁盘I/O中衡量读写比变成了55/45。 然而由于对本地磁盘的读操作请求的数据会被本地OS的cache缓存，那么真正的读操作是由于cache miss引起的读操作的I/O量，这样使得读写比变成了36/64，写被进一步放大。 另外Figure 3从I/O数据传输中真正业务需求的数据大小来看各个层次、各个操作引起的I/O变化。除了上面说的，还发现了整个系统最终存储在磁盘上有大量的cold data（占2/3），所以需要支持hot/cold数据分开存储。 总的来说，HBase stack的logging/compaction/replication/caching会放大写I/O，导致业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写占据了主导。 FM系统的主要文件类型和大小 FM系统的几种文件类型如Table 2所示，这个是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应一个或者多个HFile文件。FM系统中有8个column family，由于每个column family存储的数据的类型和大小不一样，使得每个column family的读写比是不一样的。而且很少数据是读写都会请求的，所以cache all writes可能作用不大（Figure 4）。 对于每个column family的文件，90%是小于15M的。但是少量的特别大的文件会拉高column family的平均文件大小。例如MessageMeta这个column family的平均文件大小是293M。从这些文件的生命周期来看，大部分FM的数据存储在large,long-lived files，然而大部分文件却是small, […]
Face Recognition
Recognize and manipulate faces from Python or from the command line with the world’s simplest face recognition library. Built using dlib‘s state-of-the-art face recognition built with deep learning. The model has an accuracy of 99.38% on theLabeled Faces in the Wild benchmark. This also provides a simple face_recognition command line tool that lets you do face recognition on a […]
L2TP/IPSec一键安装脚本
本脚本适用环境： 系统支持：CentOS6+，Debian7+，Ubuntu12+ 内存要求：≥128M 更新日期：2017 年 05 月 28 日 关于本脚本： 名词解释如下 L2TP（Layer 2 Tunneling Protocol） IPSec（Internet Protocol Security） IKEv2 (Internet Key Exchange v2) 能实现 IPsec 的目前总体上有 openswan，libreswan，strongswan 这3种。 libreswan 是基于 openswan 的 fork，所以现在各个发行版基本已经看不到 openswan 的身影了。 当然也有使用 strongswan 的。 之所以要更新 L2TP 一键安装脚本，是因为随着各个 Linux 发行版不断推陈出新，原有的脚本已经不适应现在的需求。 本脚本通过编译安装最新版 libreswan 来实现 IPSec（CentOS7 下则是全部 yum 安装），yum 或 apt-get 来安装 xl2tpd，再根据各个发行版的使用方法不同，部署防火墙规则。 写在前面： […]