github monitor项目 邮件发送调试问题处理笔记

Django项目中,import project_name失败,造成 project apps目录下的 tt.py processors.py 无法单独执行

解决方案:
注意到 Dockerfile 里通过执行如下shell来启动django服务:
/home/chen/code/Github-Monitor/docker/run.sh

查看该 run.sh

发现里面有一句:
export PYTHONPATH=/home/docker/Github-Monitor/server/

刚好配合 processors.py 开头中注释说的:
# 调试时去掉下面的注释、命令行执行 PYTHONPATH=. venv/bin/python github_monitor/apps/monitor/processors.py
# import django, os
# os.environ.setdefault(“DJANGO_SETTINGS_MODULE”, “github_monitor.settings”)
# django.setup()

对比目录结构:
/home/chen/code/Github-Monitor/server/github_monitor/apps/monitor

判断要在docker exec -it container_id /bin/bash中的如下目录:
/home/docker/Github-Monitor/server
执行: PYTHONPATH=. python3 github_monitor/apps/monitor/processors.py
只有这样才能成功单独运行单个文件

对应宿主机的目录为: /home/chen/code/Github-Monitor/server/

====================================================
下面的这个配置值经过测试可以正常触发扫描任务的邮件提醒
# Email Settings for 163
# If you do not fill it in, it is None/False
EMAIL_HOST=”smtp.163.com” # smtp host
EMAIL_PORT=”25″ # smtp port
FROM_EMAIL=”xxx@163.com” # 发件人
EMAIL_HOST_USER=”xxx@163.com” # email user, 如为匿名发送,将值设为空字符即可
EMAIL_HOST_PASSWORD=”xxxxxxxx” # email password, 使用授权码,避免暴露邮箱登陆密码
EMAIL_USE_TLS=”True” # 与SMTP服务器通信时是否使用TLS(安全)连接, 可选True/False
EMAIL_USE_SSL=”False” # 与SMTP服务器通信时是否使用SSL(安全)连接, 可选True/False

# Email Settings for QQ
# If you do not fill it in, it is None/False
EMAIL_HOST=”smtp.qq.com” # smtp host
EMAIL_PORT=”465″ # smtp port
FROM_EMAIL=”xxx@qq.com” # 发件人
EMAIL_HOST_USER=”xxx@qq.com” # email user, 如为匿名发送,将值设为空字符即可
EMAIL_HOST_PASSWORD=”xxxxxxxx” # email password, 使用授权码,避免暴露邮箱登陆密码
EMAIL_USE_TLS=”False” # 与SMTP服务器通信时是否使用TLS(安全)连接, 可选True/False
EMAIL_USE_SSL=”True” # 与SMTP服务器通信时是否使用SSL(安全)连接, 可选True/False

wordpress 服务重启 网页打开次数较多后 报内存不足

实际解决方案:

先找到占用内存严重的进程:
打印占用内存前10的进程:
ps aux | sort -k4,4nr | head -n 10

明确了是/usr/sbin/httpd -k start 这些进程在不断消耗内存,
与之前一直在查的PHP不是一回事,根本不是php在消耗内存。
而是httpd进程把内存消耗光了,造成php请求内存失败

httpd -V 看编译情况及加载的配置文件

修改了:
sudo vi httpd.conf , 把:#Include conf/extra/httpd-mpm.conf 前的”#”去掉了
/etc/httpd/extra/httpd-mpm.conf event里的参数,都改小了

这样修改httpd-mpm.conf就生效了。

 

 

下面这段是之前写的,文章刚要发布就因为内存不足而卡死:

背景: 升级apache到2.4, php重装后,访问wordpress网站经常会出现:Fatal error: Out of memory, 看后台error_log:  mmap() failed

尝试过多种方法都没有效果。

访问插件:http://www.xxxxxx.com/wp-admin/admin.php?page=aiowpsec&tab=tab2

在wordpress控制台内,看到PHP的内存是256M,但在服务器的配置文件中,看到的都是128M。说明配置哪里没有统一。因不知道那个256M的值是从哪里读取的,先把已知配置文件中,128M修改成256M:

vi ./wp-includes/default-constants.php,
发现这个文件里有两个变量限制内存大小 :WP_MEMORY_LIMIT WP_MAX_MEMORY_LIMIT

修改:wp-config.php,定义这2个变量的值如下:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);

修改之后,重启httpd服务,没有再发生内存不足的问题。

 

LAMP升级apache2.2 到 apache2.4踩过的坑

背景:要在apache中添加部署Django项目,要安装mod_wsgi这个模块,结果因为apache的apxs的版本有冲突无法安装。眼看自己的apache版本还是2.2,于是寻思着对Apache进行升级,于是踩坑之旅就此开始,熬过了2个凌晨2点钟。

Apache升级:原来考虑的最简单的思路莫过于直接yum update apache,结果有冲突,无法卸载也无法升级。最后直接下载了源码编译安装。

Apache安装完之后,原来Wordpress博客的网页无法正常加载,访问博客网址,刚开始是一访问就会直接触发一个下载动作。后面调试后,变成直接会把html文件夹根目录下的index.php文件的内容打印出来。试过执行了info.php,结果也是直接在网页上直接返回这个文件的内容。

看到测试的info.php都不能正常执行,猜测试是PHP有问题,网上一查,说是apache没有加载PHP模块导致。之前我的PHP版本刚升级过,是使用YUM操作的,服务器里没有编译生成过libphp7.so。各种尝试无果之后,果断决定升级PHP。

也是先考虑用yum update php来操作,结果也是各种冲突,升级也不行,卸载也不行。于是决定下载PHP源码自己编译安装。刚开始执行源码 ./configure的时候,参数使用官网默认提供的,装完之后,才想到没把mysql统计进php,于是又网上查找LAMP搭建时,PHP源码编译的参数,安装过程中各种包找不到,./configure失败重新补充安装缺少的组件。

PHP安装完之后,把:libphp7.so加载到apache的模块中。发现访问博客网站还是出现 Index of 的页面,直接把html根目录的文件全部暴露。这个时候,查找apache logs下的error_log,发现提示.htaccess的问题,再网上搜索,说的是apache2.4 跟apache2.2 的httpd.conf有些配置语法是不一样的。连猜带蒙改了httpd.conf, .htaccess。改完之后,error_log里这个报错是没有了,但是博客还是返回Index of,但这时info.php已经能正常返回了,说明我的PHP已经能正常工作。这中间穿插了:”AddType application/x-httpd-php” 的配置问题,没有这一句,apache无法正常处理php后缀的网页文件。

现在基本可以排除PHP的问题。

接下来继续上网查,发现会返回“Index of”是因为apache找不到网站访问初始打开的页面,默认是index.html,于是默认就会把html根目录下的文件列表返回至网页上。

需要修改httpd.conf:

把这一句:“Options Indexes FollowSymLinks”改成“Options FollowSymLinks”

这样就不会返回文件名列表,而是会直接提示 Forbidden。
再把“DirectoryIndex index.html”改成“DirectoryIndex index.html index.php”就可以让apache自动搜索index.php来加载网站了。

现已能正常打开博客网站。

但是,这个时候又发现了新的问题,网站只是主页能打开,博客文章目录里的链接点开会报链接不存在。好在这个问题以前就处理过,并且有写文章记录下解决方案,找到旧的博文,发现是mod_rewrite.so没有加载导致。编辑下httpd.conf,把mod_rewrite前的注释去掉就行了。

至此,整个博客网站的访问就全恢复正常了。

这下,原来要部署的Django网站的活可以重新排上日程了。。。

这篇博文刚写完要保存,发现还有问题,后台报:mmap() failed: [12] Cannot allocate memory, 先重启httpd服务修复。

使用Pyecharts画柱状图 折线图

官网:http://pyecharts.org/#/

这个工具是国人自己开发的,中文文档非常详尽易懂,使用方法可直接参考官网。

这里主要说下安装踩过的坑。

网上都说安装是: pip install pyecharts

我昨晚确实是这么安装成功,并且可以正常使用。但今天晚上再开机使用时就报错说找不到这个模块:pyecharts-snapshot,各种pip uninstall卸载重试,切换到admin账号卸载重装,全都不行。

最后是在翻看官网(http://pyecharts.org/#/zh-cn/team, new address: http://pyecharts.org/)右上角主菜单“生态系统”时,看到一个菜单项叫:pyecharts-snapshot,点击开来是一个github项目,往下翻这个github项目,发现有这么一条语句介绍安装方法:

 pip install pyecharts-snapshot

于是尝试了下在本地电脑上单独安装这个模块,装完后再 from pyecharts import Bar就正常通过了。原来的代码也能正常执行。


2019-05-15更新:
今天重新安装发现 pyecharts 代码升级后,要安装的东西不一样了,一些包的使用方式也有了变化。
要新安装的包:
pip install selenium
pip install snapshot_selenium

柱状图导入包的语句要用这一句:
from pyecharts.charts import Bar, Line

第二部分:

默认是将图表生成为html文件,下面要研究如果生成图片格式

http://pyecharts.org/#/zh-cn/prepare 有介绍

使用 pyecharts-snapshot 插件:
http://pyecharts.org/#/zh-cn/prepare?id=使用 pyecharts-snapshot 插件
如果想直接将图片保存为 png, pdf, gif 格式的文件,可以使用 pyecharts-snapshot。使用该插件请确保你的系统上已经安装了 Nodejs 环境。

  1. 安装 phantomjs $ npm install -g phantomjs-prebuilt
  2. 安装 pyecharts-snapshot $ pip install pyecharts-snapshot
  3. 调用 render 方法 bar.render(path='snapshot.png') 文件结尾可以为 svg/jpeg/png/pdf/gif。请注意,svg 文件需要你在初始化 bar 的时候设置 renderer=’svg’。

PhantomJS 是只有后端的浏览器,可在爬虫时完美模拟前端页面,对应简介可参考:https://yq.aliyun.com/articles/53969

更多内容请移步至 pyecharts-snapshot

phantomjs: http://phantomjs.org/download.html

直接用示例代码会报错:
env.render_chart_to_file(bar, path=‘bar.html’)

报错信息:
File "\ProgramData\Anaconda3\envs\python36\lib\site-packages\pyecharts_snapshot\main.py", line 119, in make_a_snapshot
raise OSError(content_array)
OSError: ["ReferenceError: Can’t find variable: echarts\n\n undefined:1\nnull\n"]

可以先用这种方式把html文件转换成图片文件:

from pyecharts_snapshot.main import make_a_snapshot
make_a_snapshot('render.html', 'clother.gif')

在Centos上执行: npm install -g phantomjs-prebuilt 会报错,
报错信息:

Phantom installation failed { [Error: EACCES: permission denied, link '/tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1545013537793/phantomjs-2.1.1-linux-x86_64' -> '/usr/local/node-v10.14.2-linux-x64/lib/node_modules/phantomjs-prebuilt/lib/phantom']
  errno: -13,
  code: 'EACCES',
  syscall: 'link',
  path:
   '/tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1545013537793/phantomjs-2.1.1-linux-x86_64',
  dest:
   '/usr/local/node-v10.14.2-linux-x64/lib/node_modules/phantomjs-prebuilt/lib/phantom' } Error: EACCES: permission denied, link '/tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1545013537793/phantomjs-2.1.1-linux-x86_64' -> '/usr/local/node-v10.14.2-linux-x64/lib/node_modules/phantomjs-prebuilt/lib/phantom'
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! phantomjs-prebuilt@2.1.16 install: `node install.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the phantomjs-prebuilt@2.1.16 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-12-17T02_25_43_064Z-debug.log

解决方案:

sudo npm install -g phantomjs-prebuilt --unsafe-perm

python36 Django项目部署到uWSGI + Nginx 环境的笔记

1. 架构关系:

Nginx和uWSGI都是Web服务器,Nginx负责静态内容,uWSGI负责Python这样的动态内容,二者配合共同提供Web服务以实现提高效率和负载均衡等目的。

uWSGI实现了多个协议,如WSGI,HTTP协议,还有它自己的uwsgi协议,想了解更多关于uWSGI和uwsgi协议内容可以查阅这里。请求和响应的流程如下:

Request > Nginx > uWSGI > Django > uWSGI > Nginx > Response

2. 安装uWSGI:

pip3 install uwsgi

测试uwsgi是否可正常运行:

先定义一个test.py,内容如下:

def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    #return ["Hello World"] # python2
    return [b"Hello World"] # python3

再执行:uwsgi –http 127.0.0.1:9000 –wsgi-file test.py

如果浏览器访问: http://127.0.0.1:9000 能成功返回”Hello, Horkd”则表示uwsgi正常工作。否则还要再排查下安装过程。

网上很多文章在测试时写的return “Hello World”是错误的,在python3的环境下,用这条语句是不会把”Hello Horld”返回给前端页面的。

3.创建一个Django测试项目,名为pro:

cd /var/www/nginx-html/test/pro/

$django-admin startproject pro

cd /var/www/nginx-html/test/pro/pro

验证这个pro是否可以正常运行:

python manage.py runserver 0.0.0.0:8000

浏览器访问:   127.0.0.1:8000, 此时应能正常返回django欢迎页面。

4.用uwsgi加载django项目:

cd /var/www/nginx-html/test/pro

新建一个配置文件: uwsgi.ini, 内容为:

[uwsgi]
http=127.0.0.1:8000
#socket=/home/www/work/project/pro/nginx_uwsgi.socket
chdir=/var/www/nginx-html/test/pro
#chmod-socket=664
master=true
processes=4
threads=2
module=pro.wsgi
#wsgi-file=uwsgi_test.py
#stats=127.0.0.1:9000

执行命令加载django项目:
uwsgi –ini uwsgi.ini

另外一种运行方式:
# 进入这个django项目的根目录
cd /var/www/nginx-html/test/pro
# 使用--module参数
uwsgi --http :8000 --module pro.wsgi

浏览器访问:http://127.0.0.1:8000/

正常情况下应返回django的欢迎页面

(正式使用uwsgi时,可设置uwsgi为自启动)

5.部署nginx服务:

sudo yum install nginx

在启动nginx的时候经历了selinux限制导致无法正常启动的小插曲:

$ sudo service nginx start
Redirecting to /bin/systemctl start  nginx.service
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
$ systemctl status nginx.service
● nginx.service - nginx - high performance web server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2018-09-09 23:15:30 CST; 9s ago
     Docs: http://nginx.org/en/docs/
  Process: 5410 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)

 SELinux is preventing /usr/sbin/nginx from name_bind access on the tcp_socket port 8081. For complete SELinux messages. run sealert -l 04b2ed94-23ec-4ed8-a29c
Sep 09 23:15:32 lanbaby.yichen python[5414]: SELinux is preventing /usr/sbin/nginx from name_bind access on the tcp_socket port 8081.
                                             
                                             *****  Plugin catchall (100. confidence) suggests   **************************
                                             
                                             If you believe that nginx should be allowed name_bind access on the port 8081 tcp_socket by default.
                                             Then you should report this as a bug.
                                             You can generate a local policy module to allow this access.
                                             Do
                                             allow this access for now by executing:
                                             # ausearch -c 'nginx' --raw | audit2allow -M my-nginx
                                             # semodule -i my-nginx.pp
                                             


#yum install policycoreutils-python
cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M my-nginx
semodule -i my-nginx.pp

$ sudo service nginx start
Redirecting to /bin/systemctl start  nginx.service
$ ps -ef |grep nginx
root      6709     1  0 23:44 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx     6710  6709  0 23:44 ?        00:00:00 nginx: worker process
lanbaby   6720  4605  0 23:44 pts/1    00:00:00 grep --color=auto nginx

cp /etc/nginx/uwsgi_params  /var/www/nginx-html/test/pro(备用)

cd /etc/nginx/conf.d (文件夹里的可以针对不同站点进行配置)

cp default.conf test-pro.conf (生成一个专门针对 test-pro 这个django项目的配置文件)

#nginx-pro
 
upstream django{
        server unix:///var/www/nginx-html/test/pro/nginx_uwsgi.sock; # file socket
        #server 127.0.0.1:7070; # TCP socket
}


server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name 127.0.0.1; # IP or FQDN

        location /static {
                alias /var/www/nginx-html/test/pro/static;
        }

        location / {
                uwsgi_pass django;
                include /var/www/nginx-html/test/pro/uwsgi_params;
                #try_files $uri $uri/ =404;
        }
}

这时配置都已完成,执行如下命令:

$uwsgi –ini uwsgi.ini
$sudo service nginx restart
这时会遇到下面报错:
SELinux is preventing /usr/sbin/nginx from read access on the file uwsgi_params.
SELinux is preventing /usr/sbin/nginx from open access on the file /var/www/nginx-html/test/prouwsgi_params.

$sudo cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M my-nginx
$sudo semodule -i my-nginx.pp
这时可以成功执行:
$sudo service nginx restart

这时访问 127.0.0.1:80,报错: 502 Bad Gateway

查看nginx错误日志,发现原因是没有权限访问文件:/var/www/nginx-html/test/pronginx_uwsgi.sock

$ sudo tail -f /var/log/nginx/error.log
[sudo] password for xxx: 
2018/09/09 23:14:21 [emerg] 5349#5349: bind() to 0.0.0.0:8081 failed (13: Permission denied)
2018/09/09 23:15:30 [emerg] 5410#5410: bind() to 0.0.0.0:8081 failed (13: Permission denied)
2018/09/09 23:49:26 [error] 6710#6710: *1 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "127.0.0.1", referrer: "http://127.0.0.1/"
2018/09/10 00:25:28 [emerg] 8604#8604: open() "/var/www/nginx-html/test/prouwsgi_params" failed (13: Permission denied) in /etc/nginx/conf.d/test-pro.conf:22
2018/09/10 00:27:13 [emerg] 8679#8679: open() "/var/www/nginx-html/test/prouwsgi_params" failed (13: Permission denied) in /etc/nginx/conf.d/test-pro.conf:22
2018/09/10 00:29:21 [emerg] 8852#8852: open() "/var/www/nginx-html/test/prouwsgi_params" failed (13: Permission denied) in /etc/nginx/conf.d/test-pro.conf:22
2018/09/10 00:36:28 [crit] 8949#8949: *1 connect() to unix:///var/www/nginx-html/test/pronginx_uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///var/www/nginx-html/test/pronginx_uwsgi.sock:", host: "127.0.0.1"
2018/09/10 00:36:36 [crit] 8949#8949: *1 connect() to unix:///var/www/nginx-html/test/pronginx_uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///var/www/nginx-html/test/pronginx_uwsgi.sock:", host: "127.0.0.1"

 

 

 

 

 

参考资料:跨过Nginx上基于uWSGI部署Django项目的坑

使用nginx + uwsgi socket的方式来部署Django项目