crifan的折腾精神、学习能力和逻辑能力的体现

说明

crifan的折腾精神==解决复杂问题的能力

下面整理出crifan的折腾各种复杂问题的过程。

其中部分内容额外体现了需要一定的技术敏感度,才容易从发现问题细节,找到问题根源,最终解决问题。

CentOS7中安装Python的pycurl和PySpider的pipenv的pycurl

期间各种折腾,遇到各种问题

最后才发现,其实涉及到了多个环境:

最终解决问题的关键点之一是:

最后不仅解决了问题,还整理出心得了:

期间的过程详见:

PySpider中模拟访问小花生接口其他参数都正确但始终是500 Internal Server Error

详见:

小花生的app的破解

MongoDB无法连接

期间,要有足够的技术敏感度,才能及时想到可能的原因,然后才能证实和快速解决。

详见:

wordpress主页菜单加指示条

折腾期间,能想到利用:

网址是wordpress,然后再去搜wordpress中是否有和当前页面方面的标示,还真的巧了找到了current-menu-item

之后,才能通过css去控制current-menu-item,达到要显示的效果。

详见:

enfold-child子主题中手机端顶部菜单点击显示异常

开始时最直接的反应,以为是以为缺少什么css呢,所以就去对比css,一点点的找,到底是哪些css不同而导致的异常

后来对比调试+细心发现,加上了is-active后,菜单可正常显示,说明不是缺少css

(重点:如果不是细心发现其实只是加上is-active即可,不知道后续还要在错误道路上,继续调试css多久)

而最开始想要调试,也没法调试,是无意间搜到网上帖子,得知是Enfold的avia-merged-styles-f39bxxxx773.css这种是合并后的

所以想到了,是不是可以有合并的参数设置,后来果然找到了

然后取消合并后,得到分别的独立的css(以及js)

从而后续可以单独看到js源码调试了

(重点:如果不是找到取消合并,则后续无法准确调试js到底执行了什么)

后来以为avia.js中的burger_wrap.click的代码执行有误呢,然后经过添加log日志,最终确定代码没问题

期间看到了加上了is-active,但是后来又没了

以为是jquery的AddClass失效了呢

而期间调试了N多次,始终有问题。

后来是第二天无意间重启了Mac的web server即mamp后,本地代码好像正常工作了

(重点:如果不是重启mamp,还不知道要继续浪费多少时间)

才调试发现

burger.addClass(“is-active”);

是正常执行的,是的确添加了is-active的class

而执行了后面的:

htmlEL.addClass(“av-burger-overlay-active”);

却导致菜单不正常显示的

就以为是:html的class中加了av-burger-overlay-active导致其他什么css生效,导致不正常显示呢

后来发现这个是正常现象

后来继续对比调试。以为是:

burger_wrap.click的 e.preventDefault();

没有执行到,导致burger_wrap.click被执行了2次

后来发现不是,而是通过Chrome调试期间,细心的注意到了:

前后的两个avia.js是enfodl父主题和子主题enfold-child两个独立的文件的相同函数

(重点:如果不是注意到是两个不同文件的avis.js中的burger_wrap.click,则解决问题的方向就偏了,还不知道要继续花多少时间才能回到正确方向上)

不是同一个avia.js中的两次执行相同的函数

从而确定是由于先后两次加载了都带burger_wrap.click的avai.js,而导致burger_wrap.click被执行了2次

最终经过Beyond Compare对比发现,enfold-child本身配置是相同的,而新旧两个Enfold主题,是版本不同,所以问题还是出在enfold主题。

然后自己通过间接的注释掉enfold-child的avia.js,才规避问题。

具体过程详见:

Azure的token出错:Out of call volume quota

如果只是从问题的表面现象,很难想到根本原因。

幸好是从繁杂的信息中,找到了一个帖子,有个提示。

经过尝试最终发现是这个原因:

微软Azure,打着鼓励你用免费F0套餐,且免费的额度很多很多,但是实际上你使用了一点点后,就不给你继续使用,就告诉你超额了。然后你只能升级换成收费的套餐,才能正常继续使用。

详见:

小程序页面空白出错:SyntaxError Unexpected EOF

关键点:

即使知道原因是:MongoDB中某些text中有特殊字符,导致显示小程序json解析出错,导致页面无法显示的问题

但是如果不懂这个是不可见的控制字符,以及如何去除,以及应该去掉哪些,那也是没法彻底的(去写代码,批量)解决问题的。

详见:

Netgear R6220路由器 变砖尝试修复的过程

虽然最后没有把变砖的路由器救活,但是期间能够从网上繁杂的信息中,找到真正的串口的位置,以及最终买电烙铁和找到并买到合适的ttl的线,也算是不容易了。

详见:

nginx的https的ssl证书无效,https域名的网页地址打不开

nginx中配置了https的ssl证书,结果始终不起效果,打开https的地址 https://www.naturling.com/ 始终出现:

无法访问此网站,拒绝了我们的请求。
请尝试以下办法:
检查网络连接
检查代理服务器和防火墙

之类的错误

-》经过一点点问题的排除,包括但不限于:

cert和key的文件访问权限:从root改为nginx的www用户和组

ssl的各种参数配置,包括listen 80和listen,server_name,ssl_ciphers等等等等

-》最终发现:

nginx在listen 443同时如果加入了80,则http页面是可以打开的,有access的log的

-》但是https的访问,始终没有log

-》好像是https的请求,根本都没进入nginx

-》所以才怀疑是不是端口问题

-》但是阿里云的ECS的安全组中,已确保了添加了443端口了

(本身新建ECS时勾选了默认系统建了安全组就包括优先级110的443,担心有影响,又自己新建一个更高的优先级1的443的规则,且删除了系统的443规则)

但是还是不行。

-》最终是:(去CentOS中用firewalld去)添加防火墙规则,允许https的443端口入方向被访问
才使得https地址 https://www.naturling.com/ 能正常打开。

详见:

相关:

Charles抓包https的过程

其中包括:

网上更多的人说安卓手机中安装Charles证书时,类型选择WLAN,结果被坑了,最后是换成少数人提到但是自己没试过的:VPN和应用,最后才正常安装证书,但是还不是安装到受信任凭据的系统中,而是用户中,以为没用,但是后来发现是有用的

-》规避了必须要root安卓手机的问题

-》也可以实现普通的https抓包解密未明文的效果了

最后把完整的操作步骤和中间遇到的大大小小的坑,都详细记录并整理到帖子里了,详见:

并且,后续又遇到:

部分https能抓包,但是其他特殊https无法抓包

期间也试了试其他路:找改安卓app的旧版本,希望万幸可以没有https的ssl pinning,最后失败

从:

Charles proxy fails on SSL Connect Method – Stack Overflow

以及其他一些帖子,基本上确定了此处无法破解的https是ssl pinning

而关于ssl pinning的办法,网上很多帖子,各种说法都很复杂,包括从apk逆向工程得到代码,再改动代码去破解的,所以放弃这些复杂的办法。

Android Security: SSL Pinning – Matthew Dolan – Medium

提到了之前Charles调试期间看到的,那个特殊的https是OkHttp,也知道旧版本貌似有bug

但是此处是最新的okhttp/3.10.0,没bug,所以也无法破解,也找不到其他相关的的办法。

后来终于找到一个相对解释的比较全的帖子,其中介绍了破解的办法:

Four Ways to Bypass Android SSL Verification and Certificate Pinning

但是却也没有给出有效且方便的办法。

而方便的办法,则是之前很多帖子中,断断续续提及的,包括这里也提到了:

如何对使用了ssl pinning的APP(如知乎)进行抓包? – 知乎

以及Android Security: SSL Pinning – Matthew Dolan – Medium 然后才知道,对于破解ssl pinning的办法:

通过

知道的:

但是需要去root手机才行

然后对于手上的手机想办法去root:

那么实在不行,考虑去购买个,便宜点的,比如1000以内中低端手机,应该都可以root的

然后就去研究便宜的可以root的安卓手机

结果发现,通过网上很多个root工具的支持机型,再去找手机,都找不到,因为都是旧型号手机,现在京东和天猫等都买不到了

再去单独从京东或天猫中找最新出的,1000以内的手机,再去找每个手机是否方便root,结果却又发现原本以为的常见的品牌,包括小胡,华为,中兴,Oppo,Vivo等等手机,却要么是之前可以root,但是最新都不支持了,比如华为的,之前可以申请解锁现在不支持了,要么是太贵了,总之现在都不论便宜和贵的,都很难买到一个手机,确保能顺利root的。

所以放弃。

后来的后来,突然想起来:去淘宝买个二手的手机吧,结果无意间发现,有人卖这种二手老手机且帮忙弄好root的手机,所以就去买二手的小米4,卖家帮忙先root好(其实自己也可以用工具去root,因为都是老的安卓系统,很多现有root工具都支持root的)

不过后来,突然想到:

貌似听某些人说,Charles的代理,也可以用安卓模拟器的

以及如何对使用了ssl pinning的APP(如知乎)进行抓包? – 知乎又提到了安卓模拟器,所以才想到另外这条路:

找个安卓模拟器,这样应该就容易解决root的问题了

最后经过尝试,在Mac中好用的,支持Wifi网络设置Charles的代理的,支持root权限的安卓模拟器是夜神安卓模拟器,

其中还有个细节:夜神模拟器的Wifi直接点击也无法设置代理,无意间(也包括之前自己用过Android,巧了有过类似精力)长按Wifi,才找到Wifi代理设置的

之后的路,就相对不那么难了,但是还有点小小曲折:

正常去夜神模拟器中安卓Charles的证书,

正常去模拟器中通过apk安装安卓的app

模拟器中安装xposed框架,结果最开始安装的夜神应用中心(按理说,系统自带的应用市场,肯定是最匹配,且效果最好的),安装的是5.1.1版本,结果后来证明是不兼容,不支持此夜神模拟器的

后来的后来,即使从官网或别处下载到正确的4.4的版本,去安装,也还是有问题

最后是自己意识到,可能需要先卸载已有的版本再安装才可以?

试了下先卸载5.1.1.的Xposed,再安装支持4.4的Xposed,终于可以正常安装了。

最后的最后,终于可以绕开ssl pinning,实现特殊的https也可以抓包解密看到明文了。

详见:

注:后来又去整理出独立的教程了:

找出supervisor+gunicorn的gevent单worker的Flask的app中额外的2个进程是从哪里来的

虽然用gunicorn的gevent解决了Flask的app的单例问题,但是却发现另外还有2个线程,导致单例失效

而对于为何有这两个线程,其实开始是一点头绪是没有的。

而足够多的折腾精神和敏锐,让我找到了个思路:

可以从另外2个线程的log信息中,找到所对应的文件

这样就可以找到最开始打印log的文件

对于找到最终的线程的来源,应该会有帮助。

然后就找到了都是:

common/FlaskLogSingleton.py

log.info("LoggerSingleton inited, logSingleton=%s", logSingleton)

所打印出来的log:

[2018-08-30 13:28:35,272 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>

然后根据自己之前的代码,反推出,应该是别的模块中,调用了:

from common.FlaskLogSingleton import log

而触发上述的log的。

但是import log的地方也很多,并不容易找到是哪里的最开始引入的,以及也不容易因此就发现线程是如何创建的。

只是经验加上直觉,觉得最大的嫌疑是:

和Flask的app,感觉逻辑上属于并列的关系的celer

-》因为:

supervisor去管理和部署Flask的APP之外,还管理了celery:

[program:robotDemo_CeleryWorker]
command=/root/.local/share/virtualenvs/robotDemo-dwdcgdaG/bin/celery worker -A resources.tasks.celery

[program:robotDemo_CeleryBeat]
command=/root/.local/share/virtualenvs/robotDemo-dwdcgdaG/bin/celery beat -A resources.tasks.celery --pidfile /var/run/celerybeat.pid -s /xxx/robotDemo/runtime/celerybeat-schedule

猜测其中的:

celery worker -A resources.tasks.celery

celery beat -A resources.tasks.celery

导致了另外两个的process的产生

接着后来再去找更多的日志信息,最后发现:

/celery-beat-robotDemo_CeleryBeat-stderr.log

[20180830 01:28:35 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>

和:

celery-worker-robotDemo_CeleryWorker-stderr.log

[20180830 01:28:35 INFO 26052 MainProcess 140308360062784 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f9c08e71048>

验证了之前的推测:

因为对应的log的第一条,就是我们之前找到的import log而输出了logSingleton的日志信息:

celery-beat-robotDemo_CeleryBeat-stderr.log

[20180830 01:28:35 INFO 26049 MainProcess 139969090553664 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f4d0add4080>

celery-worker-robotDemo_CeleryWorker-stderr.log

[20180830 01:28:35 INFO 26052 MainProcess 140308360062784 MainThread FlaskLogSingleton.py:54 <module>] LoggerSingleton inited, logSingleton=<common.FlaskLogSingleton.LoggerSingleton object at 0x7f9c08e71048>

而其中:

就是最早发现的3个进程中的其中2个Process的ID的值:

[2018-08-30 13:28:37,129 INFO 26049 MainProcess 139969090553664 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f4d0b32e128>

[2018-08-30 13:28:38,078 INFO 26063 MainProcess 140140210039848 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f74ea6d9710>

[2018-08-30 13:28:39,545 INFO 26052 MainProcess 140308360062784 MainThread tasks.py:118 <module>] inited gMsTtsTokenSingleton=<resources.tasks.MsTtsTokenSingleton object at 0x7f9c09443908>

最终,而找到了:

除了supervisor+gunicorn去启动了Flask的app是单个Process之外:

supervisor还启动了Celery的worker和beat,这2个额外的Process

共3个线程,从而导致,虽然Flask的app中是单个Process,单例正常工作,

但是加上额外2个Process,导致单例失效:每个Process中初始化的实例都不同,无法保证单例的效果了。

总结:

此处之所以能够从大量的log日志中,最终分析找到产品额外2个进程的原因,主要是靠:

先是要了解自己写的代码的逻辑关系:此处涉及到近10个文件,以及好几个配置文件

其次要足够仔细和认真:要能否思路活跃,看到相关的日志信息后,能够实现基本的逻辑推理

一定的敏感度:能否在推理的基础上,思维活跃,偶尔联想到,猜到,可能和其他哪些模块有关系

最终通过 熟悉代码+足够认真+思维敏感 而找到问题原因并解决。

详见:

对于cygwin下编译buildroot时libtool的配置期间出错的折腾

先后尝试了可算达到上百个点了。

相比而言,之前的折腾时遇到比较多的,也就三五十个尝试的点,也就把问题搞定了。

期间有几次都打算放弃了,但是后来还是坚持继续找问题原因,最终功夫不负有心人,终于搞定了:

详见:

对于cygwin下编译docbook的webhelp用到makefile调用java编译webhelp结果出错

期间,也基本是,都差不多放弃了

因为实在找不到是什么原因

而且网上也没有类似的参考资料

其他找到的资料,也没太大参考价值

最后,还是自己巧了,试了试java的classpath改为分好分隔后,虽然不行,但是想到了加上引号试试,结果才搞定的。

然后再回头找原因,才找到了该问题的根据原因并解决的。

详见:

ReactNative iOS给导航栏添加图标

详见:

折腾Flask-RQ2 + Redis

在折腾:

期间,就在迷茫的时候 能想到去试试

rq worker

最终明白flask-rq2是需要rq worker的后台服务才能工作的

Antd Pro中前端列表页面loading加载很慢

antd pro中,前端页面中列表的loading很慢:

开始就知道后端Django有一次性返回所有页面的数据,而不是当前页面数据的问题

但是发现好像是antd pro的loading的绑定有问题,后来发现不是

又以为和antd pro的yield 或call有问题,发现也不是

又以为是js的fetch有问题,发现早就返回response了

又以为是fetch后的response去json()数据量大时,很耗时

结果去花精力解决了后端Django只返回当前页数据后,依旧很慢,发现不是json()慢

再后来是,antd pro的reactjs前端的js的console的log 和 Django的后端的api请求 联合对此,最终发现:

Django后端的代码耗时太长,很多的mysql的查询和其他操作,导致很慢

具体点就是:

所以加起来要8,9秒。

所以需要去优化原有的处理逻辑:

详见:

之前类似错误,简单的就已通过:

【已解决】pyspider运行出错:ImportError pycurl libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (none/other) – 在路上

就解决了。

而此处的问题,是同事另外一台Mac。

折腾和尝试了各种思路和方向,都没有结果,详见:

【已解决】Mac中pipenv中运行PySpider出错:ImportError pycurl libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (none/other)

而此处真正对解决问题的有帮助的点是:

除了之前已有的类似的经历,还要加上:

之前经历过2种类似和相关问题:

【已解决】pyspider运行出错:ImportError pycurl libcurl link-time ssl backend (openssl) is different from compile-time ssl backend (none/other) – 在路上

【已解决】Mac中编译安装pycurl失败:error: command ‘gcc’ failed with exit status 1

还要加上足够细心和敏感才能注意到:

【已解决】Mac中编译安装pycurl失败:error: command ‘gcc’ failed with exit status 1

中是用的LibreSSL

以及也注意到了旧Mac中用的是OpenSSL

由此才能想到可能是openssl内部调用的库,不同:

以及又(有想要去了解新技术的动力,所以才)去找了相关的解释:

tls – What are the main advantages of using LibreSSL in favor of OpenSSL – Information Security Stack Exchange

然后看到提到了是10.11的OS X之后也换用了LibreSSL

所以才想到这个点,可能是解决问题的方向

->最终经过升级Mac系统到最新版本Mojave而真正解决问题。

总结起来就是说:

能解决此问题有很多必要因素:

crfian的学习能力

折腾IP代理池的过程

第一次折腾IP代理池时,对于各种相关概念不了解,连想要选购合适产品都不容易。

但是通过一些IP代理池服务商的网站产品的简单介绍:

自己悟出和理解出相关含义和区别,并整理出来了:

然后就可以购买和使用合适自己需求的代理了:

crifan的逻辑能力

汽车销售领域内客户和线索逻辑的再优化

比如在 汽车销售领域内整理客户和线索的逻辑和流程时把已有的:

潜客和线索的关系和操作逻辑:

稍加整理,变为逻辑更加清楚的: