使用hexo搭建静态博客 准备工作 一台云服务器或者Github账号 安装node.js和git 写博客 安装Node.js和git 在个人电脑上安装Node.js和git,然后安装hexo 安装完node.js和git后打开命令行 输入以下命令安装hexo npm install -g hexo-cli 初始化静态博客 创建一个文件夹用于存放博客源文件 在文件夹下使用hexo进行初始化 hexo init <folder> 博客配置 具体配置可以看官网文档 hexo中文文档 常用命令 新建文章 hexo new [layout] <title> 生成静态页面 hexo generate 选项 描述 -d, --deploy 文件生成后立即部署网站 -w, --watch 监视文件变动 -b, --bail 生成过程中如果发生任何未处理的异常则抛出异常 -f, --force 强制重新生成文件 Hexo 引入了差分机制，如果 public 目录存在，那么 hexo g 只会重新生成改动的文件。使用该参数的效果接近 hexo clean && hexo generate -c, --concurrency 最大同时生成文件的数量，默认无限制 其他命令 见命令文档 hexo命令 部署到github page 网络上有相关的资料，可以自己查询如何处理 同步到个人服务器上 使用github action 部署到 github page的库中时 同步在服务器中拉取静态网站的仓库即可同步 参考文章 github action

tomcat 400错误的解决 报错和现象 当url中有特殊字符时，高版本tomcat会显示400页面，页面暴露了版本信息和部分堆栈，参考部分报错关键字： The valid characters are defined in RFC 7230 and RFC 3986 如何解决 主要解决办法有如下几个： 此报错是高版本tomcat才出现，所以可以更换低版本来解决此问题，但同时需要考虑低版本tomcat是否有其他安全问题 在tomcat/conf/server.xml的端口配置下增加如下配置： relaxedPathChars='\":[]|' relaxedQueryChars='\":[]|' 同时在tomcat/conf/catalina.properties追加如下配置： tomcat.util.http.parser.HttpParser.requestTargetAllow=|{} org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true 但这两个配置文件不能解决所有问题，只能解决部分上面列出的特殊符号问题，如果有一些其他更特殊的符号未添加或者遗漏，那么仍然可能报错 3. 在tomcat/conf/server.xml的Host标签内加入以下代码： <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" /> 这种方式仍然会显示400错误，但不会输出错误堆栈，也算是比较好的解决方案了 方案对比 方案一需要回退低版本，存在其他安全风险 方案二使得列出的字符可以被正常请求，与高版本tomcat禁止这些字符来提升安全相背离 方案三是仍然禁止这些字符，但仅不显示版本和错误堆栈，可以保证服务安全

wordpress资源路径为绝对地址的问题 问题现象 因为网站还未备案，所以使用的是7443端口，但访问的时候除了第一个请求，其他请求全部丢失了7443端口，导致无法访问环境。 排查过程 一开始排查网络请求，发现是跳转后端口没有了，于是尝试在nginx上增加了部分反代时端口的适应配置，仍然无法解决，怀疑是页面本身有问题，检查页面源码，发现所有资源都是写的无端口的绝对地址，基本上能定位是这个问题 解决问题 修改wordpress前台页面文件wp-config.php,在require_once(ABSPATH . 'wp-settings.php'); 之前加入如下代码： $home = 'http://'.$_SERVER['HTTP_HOST'].'/'; $siteurl = 'http://'.$_SERVER['HTTP_HOST'].'/'; $conturl = 'http://'.$_SERVER['HTTP_HOST'].'/wp-content'; define('WP_CONTENT_URL', $conturl); define('WP_HOME', $home); define('WP_SITEURL', $siteurl);

nfs客户端文件属主为nobody的现象 环境背景 服务器版本：Centos6 nfsv4 客户端版本：Centos6或者Centos7 挂载版本为nfsv4 问题现象 客户端挂载时候选择nfsv4版本或者默认是nfsv4版本时，挂载后非root用户创建的文件属主为nobody，这样导致某些服务普通用户读写文件会有权限问题 如何解决 **方法1：**修改文件权限为777，这样的话所有用户都有读写权限，但有可能导致不安全 **方法2：**修改客户端挂载版本为nfsv3，此方法未测试可行性 **方法3：**服务端系统使用centos7，在centos7之后nfs模块/sys/module/nfsd/parameters/nfs4_disable_idmapping的值默认为Y **方法4：**在服务端系统需要使用centos6，客户端挂载版本使用nfsv4时，可尝试做如下处理： 修改服务端模块的idmap值 echo Y > /sys/module/nfsd/parameters/nfs4_disable_idmapping 增加文件/etc/modprobe.d/nfs.conf，添加如下内容 options nfs nfs4_disable_idmapping=1 options nfsd nfs4_disable_idmapping=1 第三步：重启rpcbind，nfs服务 **方法5：**尝试在客户端和服务端创建相同的用户/组，并且分配相同的uid和gid **方法6：**配置idmapd服务，配置文件/etc/idmapd.conf，还未测试可行性 关于此问题说明 因为nfsv4使用idmapd来映射客户端和服务端用户名，如果客户端与服务端文件属主不一致或者服务端无此用户那么就会映射成nobody。最后centos7上的服务端idmapd模块默认是关闭的，所以影响范围应该只有centos6的nfsv4服务端上。