Jenkins部分汉化处理方法

0x01

最近换了个新项目组,因为在虚拟机上安装的CentOS,在上面安装的JenKins,因为需要给开发跟测试的同事使用,所以选择汉化一下界面。

0x02

安装好两个插件Locale Plugin、Localization:Chinese(Simplified)后,在Manage JenKins > Configure System 里面设置为zh_CN后发现只有部分汉化,网上找了一圈都是把语言改成英文后重启,再改成中午,发现不管用。无奈之下只能自己找原因了。

如图把默认语言改成中文

0x03

苦找半天,最后发现是因为网络的原因汉化插件没有下载完全,删除后重新下载,也是下载不完全,只能去到/root/.jenkins/updates/default.json找到插件的下载地址,用迅雷下载好插件后把文件丢到/root/.jenkins/plugins里面,重启jenkins后终于看到了熟悉的汉化界面。

圈起来的三个文件可以删除后去/root/.jenkins/updates/default.json里面找到下载地址,用迅雷下载好后放到/root/.jenkins/plugins目录下

0x04

/root/.jenkins/是主目录,可以在Manage JenKins > Configure System第一行里面找到这个目录。

Docker上跑Mysql的配置

ox01

最近在把项目往Docker上迁,些一篇文章来记录一些值得注意的问题。

0x02

在测试环境Docker上跑Msql时,用如下命令根据镜像创建容器.

docker run --name mysql \
 -p 3306:3306 \
 -v $PWD/Docker/mysql:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD=root \
 -d mysql:latest

用Navicat连接时,登录会提示2058。

网上找了一圈基本上是,用以下命令

docker exec -it  CONTAINER_ID  bash

进入容器里面修改一次数据库的密码

mysql -uroot -proot #登陆

use mysql; #选择数据库

ALTER USER 'root'@'localhost' IDENTIFIED BY 'password' PASSWORD EXPIRE NEVER; #修改加密方式

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password'; #更新用户密码

FLUSH PRIVILEGES; #刷新权限

修改后问题就解决了,可以登录成功;只是这个方法不适合集群部署。也可以直接在创建镜像的时候添加以下参数来解决;

--default-authentication-plugin=mysql_native_password

0x03

因为创建数据库的时候没有选择默认字符集、排序方式,创建表后varchar类型,输入中文时会变成??????,点设计表后发现创建表的默认字符集是latin1,所以中文乱码了,想要在创建容器时添加如下参数来指定默认的字符集。

--character-set-server=utf8mb4 \
--collation-server=utf8mb4_unicode_ci

0x04

本来以为上面的设置已经万事大吉了,结果跑了一段时间后发现数据库的时间不对了,少了8个小时。检查了一下发现时用系统的默认时区,中国是东八区UTC+8。需要在创建容器的时候添加时区映射。

-e TZ="Asia/Shanghai" 

0x05

汇总后创建容器的语句如下:

docker run --name mysql \
-p 3306:3306 \
-e TZ="Asia/Shanghai" \
-v $PWD/Docker/mysql:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql:latest \
--default-authentication-plugin=mysql_native_password \
--character-set-server=utf8mb4 \
--collation-server=utf8mb4_unicode_ci

解决Docker容器控制台乱码

0x00

今天在用Rancher安装Graylog时发现都安装好了,登录Graylog控制台查看日志时发现中文的都是??????乱码,去网上找了好多文档,发现不是很稳。

ox01

找了好多都说要添加环境变量

LANG = en_us.UTF-8

我也是按着添加了,也重启了容器,硬是不行,最终发现需要进入容器里面查看容器支持的编码,再去设置为支持的编码才行(8e7dd064fa6b为容器ID)

docker exec -it 8e7dd064fa6b bash

进去容器后执行命令可以查目前容器支持的编码

 locale -a

再选择一个支持编码去设置LANG,设置好重启容器就正常了

0x02
网上说的其实都对,就是没有把关键的说出来,LANG = 需要设置为当前容器支持的编码,每个镜像打出来的容器,支持的编码都不尽相同,如果设置为一个容器不支持的编码,那设置了等于没有设置。

Docker设置时区

最近项目的环境换成了docker,用Rancher去管理,项目管理方便了一些,其中也遇到了一些问题,特此记录一下。

项目输出的日志时间不对。查看日志发现镜像里面没设置时区,是默认的时区,在容器里面添加环境变量:
TZ="Asia/Shanghai" 
把时区设置为上海,重启容器后发现时间正确了。

网易相册停运

今天在查看个人邮箱的时候发现收到了网易相册的邮件,吸引我的注意,打开看了发现是一个停止运营的公告。印象中接触网易相册是在07 08年的时候,班级去旅游,老师就把出游的照片上传在网易相册里面的,让我们自己去下载。现在已经是19年了,10多年过去,网易相册已到了谢幕时间。特此记录一下陪伴了我十多年的相册。

网易相册从2003年开始上线,那时候开始就只是国内最大的、知名度最高的免费网络相册。

2019年5月8日,网易相册将会全面停止运营,关闭服务器。

亲爱的网易相册用户,很遗憾的通知您,网易相册将会在2019年5月8日00:00全面停止运营。请您在停运之前将需要保存的图片进行下载以防丢失。

腾讯云CND的一次异常记录

0x00

现在的项目一直在做微信公众号的业务,因为经常有推文,会有短时大流量的访问,就使用的腾讯云的CDN加速来减少源站的压力。在昨天下午的时候发现很多请求出现504点情况。因为我们前端采用腾讯云的LB去做集群,根据URL去转发到后端服务器去处理。第一时间检查了了结群的服务器,没发现有异常的服务器。再排查了一遍LB的设置,检查了后端服务中间件的超时时间设置。初步判断为腾讯云的CDN出了问题。

0x01

拿浏览器测试了一下,刷新页面资源随机返回504,同一资源会50%左右的概率返回504。因为我们配置的http跟https,发现http的都是正常返回200的,就是https的不正常。再拿Fiddler来模拟请求,还是50%的概率返回504。郁闷了半天,都没发现问题就是莫名的返回504,最后之间修改电脑的Hosts文件,把域名直接指向腾讯云LB后,都正常的了,于是提交了工单。

0x02

大概过了半个小时腾讯云工程师回复测试其中一个节点暂时没出现504。需要测试下我这边的异常节点。可以通过ping去获取CDN节点。

测试后回复工单

腾讯云工单回复CDN对于504返回码是直接透传的(为源站返回),同时这边进行绑源测试,直接访问源站也是有出现504的情况,请您核实源站情况。

我们修改本机hosts文件直接指向我们的回源ip,就不会出现504的情况。

您好,您可以这样,下载一个mtr工具,然后输入您的域名(接入cdn的)然后抓个400个包左右,然后截图,重复以上的步骤,域名绑定您源站host然后抓400个包左右看是否有丢包。

然后我下载了WinMTR分别测试的,启用CDN情况:

直接回源:

核实您源站是LB而LB后端机器是个机器比较多的集群,您看下LB监控有出现异常状态的机器吗?

LB后端的机器是正常的,目前是深圳的用户反馈出现504异常。我用南京联通的网络测试没有出现504.

深圳用户访问的节点我这里刚刚也测试了下,通过节点访问也是没问题的,504这种错误码CDN已经规避了所有出现这种问题的可能,只会透传源站返回的状态,我这里看了下回源日志确实有几百次504,但都是源站返回的。因为您源站是个lb这里不太好判断具体那台机器给返回的。

解析记录添加CDN时候的接口测试:

目前我们已经修改了解析记录为A记录,直接解析到LB上,测试结果:

按照目前的情况来看,我们只能停用CDN了…

0x03

您添加CDN的时候是在深圳测试测试的吗?其他地区有反馈吗?

我们的CDN很早就已经添加了,只是昨天下午开始深圳地区反馈很多请求出现504,其他地区还没有反馈异常。

您这个是用什么测试的?有更像的信息吗?确实很奇怪,我们这面504是透传源站的,但是您直接访问源站又没问题。肯定那块有问题,还需要详细查下。

这个是我用Fiddler直接请求接口地址的,解析了CDN就会出现504的情况,我们的网站是支持http跟htts的目前就是htts的出现504的情况,http都是正常的。这个借口地址,我跟了一下整过请求的过程,请求到LB后,LB做了URL转发 /front/ 只交给后端的一台去处理的。后端的的服务器的日志我排查了一遍,没发现504的情况。目前请求返还的504页面是LB返回的页面。然之间请求LB却不会出现504情况。

0x04

目前还在等腾讯云工程师定位问题。后续定位到问题再更新~

关于cannot open shared object file: No such file or directory的解决

0x00

今天在安装Nginx的时候发现openssl、pcre、zlib都装好了,启动的时候发现如下提示

# ./nginx ./nginx: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
# ./nginx: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory -bash: ./nginx:: No such file or directory

然后在百度找了一通发现解决的方法很多,自己记录了一下解决的方法如下:

0x01

如果共享库文件安装到了/lib/usr/lib目录下,那么需执行一下ldconfig命令

0x02

# cat /etc/ld.so.conf include ld.so.conf.d/*.conf
# echo “/usr/local/lib” >> /etc/ld.so.conf
# ldconfig

0x03

/lib/usr/lib” 目录下,但是又不想在/etc/ld.so.conf中加路径(或者是没有权限加路径). 那可以export一个全局变量LD_LIBRARY_PATH,然后运行程序的时候就会去这个目录中找共享库

可以添加用户环境变量来解决

export LD_LIBRARY_PATH=/usr/local/mysql/lib:$LD_LIBRARY_PATH

巴黎圣母院大火

0x00

巴黎圣母院,耸立在塞纳河的西堤岛上,拥有850多年历史,始建于1163年,并在1345年完工。2013年,圣母院庆祝兴建850周年。圣母院建筑总高度约超过130米,是欧洲历史上第一座完全哥德式的教堂,具有划时代的意义,也是巴黎历史悠久最具代表性的古迹,被联合国教科文组织列入世界遗产名录

今天早上起来打开微博时发现都是在说法国巴黎圣母院当地时间2019年4月15日下午6点50分左右被大火烧了,整座建筑损毁严重。着火位置位于圣母院顶部塔楼,大火迅速将圣母院塔楼的尖顶吞噬,很快,尖顶如被拦腰折断一般倒下。

0x01

巴黎当地时间2019年4月15日下午6:50。正搭起脚手架进行维修工程的巴黎圣母院遭遇大火,滚滚浓烟遮蔽了塞纳河畔的天空。 火势蔓延速度很快,难以控制。在紧张围观的人群注视下,巴黎圣母院标志性的尖顶被烧断,坍塌倒下。

事故时间点
2019-04-15 18:50,根据法国消防部门消息,巴黎圣母院大教堂屋顶上冒出火焰和烟雾。
2019-04-15 19:07,一名路透社记者从远处看到巴黎圣母院的烟雾和火焰。
2019-04-15 19:49,火势蔓延到巴黎圣母院大教堂的尖顶上。法国总统马克龙因此推迟了原定当天晚上8点发表的关于“大辩论”的总结讲话。
2019-04-15 19:53,巴黎圣母院中部的尖塔坍塌。
2019-04-15 19:59,法国总统办公室称马克龙正赶往现场。
2019-04-15 20:07,路透社现场记者报道称,巴黎圣母院的整个屋顶倒塌了。
2019-04-15 20:25,巴黎圣母院附近区域被警方疏散。
2019-04-15 21:00,大火仍然没有被扑灭,夜幕下的巴黎圣母院主体建筑不断冒出白色烟雾,空气中弥漫着刺鼻的气味。
2019-04-15 22:20,法国内政部的一名官员表示,有400名消防员已在火灾现场,但他们可能无法拯救巴黎圣母院。
2019-04-15 22:30,巴黎民众及游客等聚集在巴黎圣母院附近,为圣母院祈祷。
2019-04-15 22:50,巴黎市长表示,为了防止火势蔓延,居住在巴黎圣母院附近的人们已经被疏散。
2019-04-15 23:05:一名法国消防官员表示,巴黎圣母院的标志性长方形塔楼已从火灾的风险中被拯救出来。
2019-04-15 23:15,巴黎检方称,目前调查人员正在对巴黎圣母院着火区域进行灭火。
2019-04-15 23:35,法国总统马克龙表示正在寻求国际帮助,以恢复重建巴黎圣母院。
2019-04-15 23:35,大火仍在继续燃烧。
2019-04-16 03:30, 公布了巴黎圣母院大火救援的最新进展,称火情已“全部得到有效控制,并已部分扑灭”。
2019-04-16 10:00,巴黎圣母院大火被全部扑灭。屋顶和塔尖被烧毁,但主体建筑得以保存,圣母院中的主要文物“耶稣荆棘冠”和“圣路易祭服”等也没有受损。火灾目前进入调查和损失评估阶段。

0x02 造成损失

根据法国消防队员称,巴黎圣母院主体结构被“拯救”,主结构整体保存完整。
巴黎副市长称,巴黎圣母院有着852年历史的中轴塔在火中坍塌。
据报道,巴黎圣母院馆藏珍宝在此次火灾中大致幸免,主结构尚存,但屋顶烧毁,一座尖塔倒塌,可能要数年时间修复。
重要文物“荆棘皇冠”和路易九世的一件长袍已被成功救出。

0x03 事故伤亡

没有人员死亡,有两名警察和一名消防员受到轻伤。

0x04 事故原因

        火灾发生后,巴黎市检察机关在第一时间宣布启动调查,调查方向初步定为“过失引发火灾导致损毁”,目前检方已经排除了纵火的可能性,也不认为此事和恐怖主义有关。
        法国媒体援引巴黎消防队的说法称,火灾与耗资600万欧元的翻新工程有“潜在联系”。据悉,翻新工程的对象是大教堂被烧毁的尖顶和建筑的250吨铅材料。上周,尖塔上的雕像才被起重机吊起

自己执生

时光匆匆,去年一年都没写过一篇博客。都忙碌于三点一线,上班、吃饭、睡觉。回想其实去年,仿佛白纸一般,没想可想。

常常在抱怨的时候会飙粤语,这些年总是自己执生。仿佛在迷宫中,两条路可选,选对即可乘风破浪;选错自己收拾残局。并没有人指点你的江湖路。

一切得靠自己执生。

oracle表空间满

最近一段时间发现程序在晚上同步数据时会假死,程序没有输出异常信息,但是用浏览器访问后页面空白,重启后后正常了,一开始以为是程序晚上同步数据时有2万多个空指针,导致内存溢出,然后卡死,把异常数据清理后发现问题依旧。在同步数据时卡死,那么数据库也嫌疑犯之一。首先查看表空间的使用情况:

 SELECT tbs 表空间名,
       sum(totalM) 总共大小M,
       sum(usedM) 已使用空间M,
       sum(remainedM) 剩余空间M,
       sum(usedM) / sum(totalM) * 100 已使用百分比,
       sum(remainedM) / sum(totalM) * 100 剩余百分比
  FROM (SELECT b.file_id ID,
               b.tablespace_name tbs,
               b.file_name name,
               b.bytes / 1024 / 1024 totalM,
               (b.bytes - sum(nvl(a.bytes, 0))) / 1024 / 1024 usedM,
               sum(nvl(a.bytes, 0) / 1024 / 1024) remainedM,
               sum(nvl(a.bytes, 0) / (b.bytes) * 100),
               (100 - (sum(nvl(a.bytes, 0)) / (b.bytes) * 100))
          FROM dba_free_space a, dba_data_files b
         WHERE a.file_id = b.file_id
         GROUP BY b.tablespace_name, b.file_name, b.file_id, b.bytes
         ORDER BY b.tablespace_name)
 GROUP BY tbs

发现表空间USERS的表空间的已使用百分比是99%.再获取用户的默认表空间:

select username, DEFAULT_TABLESPACE
from dba_users
where username = 'scott';

scott用户的默认表空间刚好是USERS,找到表空间的物理路径:

select * from dba_data_files where tablespace_name ='USERS';

那就把这个表空间进行扩展:

alter database datafile 'D:\ORACLE\PRODUCT\ORADATA\TEST\USERS01.DBF' resize 5120M;

修改USERS表空间时较慢,花了4分多钟.修改完成后再次查询表空间的使用情况,再次查询看否执行成功。