扩展程序可以让我们不需要深入了解Chrome
的原生代码就可以扩展Chrome
浏览器的功能。 你可以用已经掌握的web
开发核心技术HTML
,CSS
,和JavaScript
来创建Chrome
扩展程序。 如果你以前开发过网页,你可以很快地上手开发扩展程序; 接下来我们就马上开始,一步步地开发一个简单的扩展程序,这个扩展程序的作用是找出当前页面中所使用的谷歌服务器图片。
ubuntu 16.04.3上apache 2.4.18通过HTTP_REFERER阻止图片盗链
最近偶尔碰到网站的流量被消耗尽的情况,已经影响到自己的使用了。怀疑网站图片,数据等被盗链,导致流量被消耗。
ubuntu 16.04.3
上apache 2.4.18
防止网站图片被盗链的方法如下:
首先是在根目录下创建一个.htaccess
,如果已经有了,直接把下面的代码添加到.htaccess
尾部即可。
#阻止盗链 <IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ [NC] RewriteCond %{HTTP_REFERER} !google.com [NC] RewriteCond %{HTTP_REFERER} !baidu.com [NC] # 微软必应 RewriteCond %{HTTP_REFERER} !bing.com [NC] # 谷歌翻译 RewriteCond %{HTTP_REFERER} !translate.googleusercontent.com [NC] RewriteCond %{HTTP_REFERER} !mobibrw.com [NC] RewriteCond %{HTTP_REFERER} !miniab.com [NC] # 跳转到服务器首页 RewriteRule .*.(gif|jpg|png|zip|gz|tar|pdf)$ mobibrw.com [R,NC,L] # 服务器返回403禁止访问 # RewriteRule .*.(gif|jpg|png|zip|gz|tar|pdf)$ - [F] </IfModule>
简单的解释下每条语句:
RewriteCond %{HTTP_REFERER} !^$ [NC]
允许空“HTTP_REFERER
”的访问,即允许用户在浏览器地址栏中直接输入图片地址时图片文件的显示。一般而言,这是可选的,不过,建议这么设置,如果强迫必须具有“HTTP_REFERER
”才能访问,可能会带来某些问题,比如说在用户通过代理服务器访问时。
RewriteCond %{HTTP_REFERER} !google.com [NC]
设置允许访问的HTTP
来源,包括我们的站点自身、Google
、Baidu
等。这个可以添加多条,目前我们配置只有自身还有谷歌百度等常用的搜索引擎的访问权限。
RewriteRule .*.(gif|jpg|png|zip|gz|tar|pdf)$ mobibrw.com[R,NC,L]
定义被盗链时替代的链接,可以是图片,也可以是404
错误页,目前我们定义的是首页,所以就是mobibrw.com
,如果是要定义在404
页面,可以把404
页面的路径加上。当然替换的页面文件体积越小越好。你也可以不设置替换图片,而是使用下面的语句即可(服务器返回403
禁止访问):
RewriteRule .*\.(gif|jpg|png|zip|gz|tar|pdf)$ – [F]
参考链接
ubuntu 16.04.3上apache2服务器报告错误“script not found or unable to stat: /usr/lib/cgi-bin/php*”
最近在查看服务器上的apache2
的错误日志的时候,发现如下错误信息:
[Sun Jan 28 19:06:13.794012 2018] [cgi:error] [pid 3382:tid 139940209870592] [client 149.56.130.214:39 474] AH02811: script not found or unable to stat: /usr/lib/cgi-bin/php [Sun Jan 28 19:06:14.238284 2018] [cgi:error] [pid 3382:tid 139940117550848] [client 149.56.130.214:39 474] AH02811: script not found or unable to stat: /usr/lib/cgi-bin/php5 [Sun Jan 28 19:06:15.550249 2018] [cgi:error] [pid 3382:tid 139940226656000] [client 149.56.130.214:39 474] AH02811: script not found or unable to stat: /usr/lib/cgi-bin/php-cgi [Sun Jan 28 19:06:15.983952 2018] [cgi:error] [pid 3382:tid 139940125943552] [client 149.56.130.214:39 474] AH02811: script not found or unable to stat: /usr/lib/cgi-bin/php.cgi [Sun Jan 28 19:06:16.422075 2018] [cgi:error] [pid 3382:tid 139940033623808] [client 149.56.130.214:39 474] AH02811: script not found or unable to stat: /usr/lib/cgi-bin/php4
刚刚开始感觉莫名其妙,因为PHP
的解析已经通过PHP-FPM
模式进行处理,服务器上的配置已经不需要cgi
进行处理了。
网上搜索了一下,发现这个是由于ubuntu
上apache2
的默认配置模版导致的,尤其是从ubuntu 12.04
一路升级上来的系统,在配置模版中有指出/usr/lib/cgi-bin/
这个路径,可是这个路径已经不再使用了。
修改方式如下:
$ sudo vim /etc/apache2/sites-enabled/000-default.conf
向下查找,会发现如下内容:
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin/"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory>
如果确实网站已经不再使用任何cgi
相关的东西了,可以直接注释掉这段代码。
另外如果开启了HTTPS
,同理需要修改HTTPS
对应的配置文件。
修改完成后,重启服务器:
$ sudo service apache2 restart
参考链接
script not found or unable to stat: /usr/lib/cgi-bin/php-cgi
用Python在地图上模拟疫情扩散
最近在研究热力图,发现了一篇可能有用的Python
模拟疫情扩散的文章,可以部分模拟热力图,整篇文章原文内容如下:
RTSP回放时如何通过RTP的timestamp计算NPT时间(Normal Play Time)
客户端通过RTSP
的PLAY
方法开始播放、定位播放、快速/慢速播放(Scale
)某非实时视频时,客户端会通过Range
头字段指定NPT
时间,即让服务器开始从NPT
指定时刻开始播放视频(NPT
(Normal Play Time---正常播放时间
)即播放位置离文件开始部分的相对时间)。
播放开始后,下一次发送PLAY
命令前,客户端需要根据服务器发来的RTP timestamp
计算当前收到的帧的NPT
时间。
客户端与服务器同步NPT
时间
客户端可以在每次收到PLAY
响应消息时与服务器同步NPT
时间,响应消息里可带RTP-Info:rtptime
和Range:npt
参数。
客户端发往服务器RTSP
消息例子:
PLAY rtsp://foo.com/test.wav RTSP/1.0 CSeq: 3 Session: 2034820394 Range: npt=30.6-3508 Scale: 2
服务器响应消息的例子:
RTSP/1.0 200 OK CSeq: 3 Session: 2034820394 Range: npt=30.6-3508 Scale: 2 RTP-Info: url=rtsp://foo.com/test.wav/streamid=0; seq=981888;rtptime=3781123
其中响应消息中Range:npt
的第一个参数表示客户端紧接着收到的timestamp
为RTP-Info:rtptime
指定的RTP
包时的NPT
时间。
当前NPT
时间计算公式
current_npt = begin_npt + ((timestamp_len * reset_counter + current_timestamp - start_timestamp) / clock_rate) * scale
其中各项含义:
begin_npt
:PLAY
返回消息里Range: npt=18.8-3600
中的开始时间(秒)timestamp_len
:RTP timestamp
的最大表示个数,4
个字节,所以是2^32
即0x100000000
reset_counter
:RTP timestamp
的归零次数current_timestamp
: 当前收到的RTP
的timestamp
值start_timestamp
:PLAY
返回消息里的RTP-Info
里的rtptime
(指明此后第一个收到的RTP
包的timestamp
值)clock_rate
: 时钟频率,即SDP a=rtpmap:96 H264/90000
里的90000
scale
:PLAY
里请求和返回中的Scale
值(以返回为准)
NPT
与RTP timestamp
的进一步讨论
RTP
的timestamp
里的wallclock
应该是表示RTP
会话开始到当前的绝对elapsed
时间,与NPT
不是对应的。(比如PAUSE
以后,重新PLAY
时NPT
是影片开始的相对时间,而RTP timestamp
是RTP
会话开始的相对时间)
加速播放时(RTSP scale=2
),在PLAY
返回让npt
与rtptime
映射后,npt
计算时要加倍计算,而rtptime
间隔保持不变。
另外,关于RTP timestamp
与帧率等关系可参考RTP timestamp与帧率及时钟频率的关系。
参考资料
[1] RFC2326 (Appendix B: Interaction with RTP):
For scaling (see Section 12.34), RTP timestamps should correspond to
the playback timing. For example, when playing video recorded at 30
frames/second at a scale of two and speed (Section 12.35) of one, the
server would drop every second frame to maintain and deliver video
packets with the normal timestamp spacing of 3,000 per frame, but NPT
would increase by 1/15 second for each video frame.The client can maintain a correct display of NPT by noting the RTP
timestamp value of the first packet arriving after repositioning. The
sequence parameter of the RTP-Info (Section 12.33) header provides
the first sequence number of the next segment.[2] 3GPP 26.234 (A.3.2.4 Timestamp handling after PAUSE/PLAY requests):
The description below intends to clarify how RTP timestamps are specified within the 3GPP PSS when a client sends a PLAY request following a PAUSE request. The RTP timestamp space must be continuous along time during a session and then reflect the actual time elapsed since the beginning of the session. A server must reflect the actual time interval elapsed between the last RTP packets sent before the reception of the PAUSE request and the first RTP packets sent after the reception of the PLAY request in the RTP timestamp. A client will need to compute the mapping between NPT time and RTP timestamp each time it receives a PLAY response for on-demand content. This means that a client must be able to cope with any gap in RTP timestamps after a PLAY request.
The PLAY request can include a Range header if the client wants to seek backward or forward in the media, or without a Range header if the client only wants to resume the paused session.
Example:
In this example Client C plays a media file from Server S. RTP timestamp rate in this example is 1000Hz for clarity.
C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0
CSeq: 2
Session: 123456
Range: npt=1.125-
S -> C: RTSP/1.0 200 OK
CSeq: 2
Session: 123456
Range: npt=1.120-
RTP-Info: url=rtsp://example.com/mediastream;seq=1000;rtptime=5000
S -> C: RTP packet - seq = 1000 - rtptime = 5000 - corresponding media time (NPT time) = 1120ms
S -> C: RTP packet - seq = 1001 - rtptime = 5040 - corresponding media time (NPT time) = 1160ms
S -> C: RTP packet - seq = 1002 - rtptime = 5080 - corresponding media time (NPT time) = 1200ms
S -> C: RTP packet - seq = 1003 - rtptime = 5120 - corresponding media time (NPT time) = 1240ms
C -> S: PAUSE rtsp://example.com/mediastream RTSP/1.0
CSeq: 3
Session: 123456
S -> C: RTSP/1.0 200 OK
CSeq: 3
Session: 123456
[10 seconds elapsed]
C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0
CSeq: 4
Session: 123456
S -> C: RTSP/1.0 200 OK
CSeq: 4
Session: 123456
Range: npt=1.280-
RTP-Info: url=rtsp://example.com/mediastream;seq=1004;rtptime=15160
S -> C: RTP packet - seq = 1004 - rtptime = 15160 - corresponding media time (NPT time) = 1280ms
S -> C: RTP packet - seq = 1005 - rtptime = 15200 - corresponding media time (NPT time) = 1320ms
S -> C: RTP packet - seq = 1006 - rtptime = 15240 - corresponding media time (NPT time) = 1360ms
C -> S: PAUSE rtsp://example.com/mediastream RTSP/1.0
CSeq: 5
Session: 123456
S -> C: RTSP/1.0 200 OK
CSeq: 5
Session: 123456
C -> S: PLAY rtsp://example.com/mediastream RTSP/1.0
CSeq: 6
Session: 123456
Range: npt=0.5-
[55 milliseconds elapsed during request processing]
S -> C: RTSP/1.0 200 OK
CSeq: 6
Session: 123456
Range: npt=0.480-
RTP-Info: url=rtsp://example.com/mediastream;seq=1007;rtptime=15295
S -> C: RTP packet - seq = 1007 - rtptime = 15295 - corresponding media time (NPT time) = 480ms
S -> C: RTP packet - seq = 1008 - rtptime = 15335 - corresponding media time (NPT time) = 520ms
S -> C: RTP packet - seq = 1009 - rtptime = 15375 - corresponding media time (NPT time) = 560ms
参考链接
RTP时间映射及同步
RTP
包中的时间戳字段是说明数据包时间的同步信息,是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间。为了计算各个数据流的播放时间以及同步处理,仅有RTP
包中的时间戳信息是不够的。
在整个播放过程中,包括这样几种时间:
RTP
包中的rtptime
PLAY
请求的Response
中的rtp time
和npt
RTCP
的SR
(Sender Report
)中的rtp
和ntp
时间戳对
一、时间戳映射关系
首先介绍PLAY
请求的Response
里的两个域:
(1)npt
npt
顾名思义Normal PLay Time
,正常播放时间,指出了流相对与播放开始时的绝对位置。播放开始时的之间定义为0.0s
。这个特殊的常量now
被定义为现场事件的当前时刻。"now
"常数允许客户端请求接收实时反馈而不是存储或者延时的版本。因为对于这种情况而言,既没有绝对时间,也没有0
时间,所以需要该参数。
(2)rtptime
rtptime
是发送PLAY
请求后将收到的第一个RTP
包的时间戳值。
npt
和rtptime
的区别在于npt
是影片开始的相对时间,而rtptime
是会话开始的相对时间。因此在client
端,需要对这两者进行map
处理。
在client
端计算播放时间戳的公式如下:
nptUs = (current_rtpTime - start_rtptime) / scale + srart_npt
其中:
start_rtptime
与start_npt
分别是PLAY
请求的Response
中的rtptime
和npt
。
current_rtpTime
是当前收到的RTP
包头中的rtptime
。
scale
为PLAY
请求的Response
中的scale
值。在正常播放的情况下为1
,快速播放时大于1
,当处于反向扫描模式时小于-1
.
二、媒体间同步方法(不同设备的同步)
上面的处理仅仅实现了媒体内的同步,在实现媒体间同步时,还需要进行其他的处理工作。这就需要用到RTCP
的SR
(Sender Report
)。在SR
中包含一个<rtp
,ntp
>时间戳对,通过这个时间戳对可以将音频和视频准确的定位到一个绝对时间轴上。
<rtp
,ntp
>时间戳对的必要性在于不同流的RTP
时间戳有不同的随机偏移量,因此无法直接进行同步。
<rtp
,ntp
>中的ntp
是网络时间协议格式表示的绝对时间值。
<rtp
,ntp
>中的RTP
与数据包中的RTP
时间戳具有相同的单位和偏移量,但在大多数情况下此时间戳不等于任何临近的RTP
包中的时间戳。
根据不同stream
中的<rtp
,ntp
>时间戳对,可以将一个stream
中的时间戳值映射为另一个stream
的时间戳值,从而实现媒体间的同步。
参考链接
ubuntu 14.04.5桌面版与服务器版~/.bashrc,~/.bash_profile的差异
对于ubuntu 14.04.5
服务器版,当前用户目录下存在.bash_profile
的时候,会忽略.bashrc
文件。
对于ubuntu 14.04.5
桌面版,当前用户目录下的.bash_profile
会被忽略。
Ubuntu 17.10将于1月11日“重新”发布,修复“变砖”问题
Ubuntu 17.10
将于1
月11
日“重新”发布,表示不会再让本本变砖~
Canonical
上个月从Ubuntu
的官方网站临时关闭了Ubuntu 17.10
的下载通道,并留下通知:
由于在 某些笔记本电脑(主要为联想)上出现BIOS
固件问题,导致笔记本电脑无法启动,目前不推荐下载Ubuntu 17.10
。待问题解决后,再重新开放。
关闭Safari英文矫正功能
在macOS High Sierra
系统上使用Safari
进行搜索的时候,总是莫名其妙的被修改搜索词,导致搜索结果驴唇不对马嘴。搜索了一下,这个锅应该是输入法导致的,最可恶的是不能拒绝输入法的推荐词汇,可以使用如下方式关闭输入法的自动英文矫正功能。
Ubuntu 14.04.5安装开源跳板机 Jumpserver 开发版(2018.01.08)
参照ubuntu 14.04.5下安装多版本Python(2.7.6/3.4.3/3.6.4),安装配置最新版本的Python 3.6.4
。Jumpserver
需要Python 3.5
以上的版本才能正常运行。
目前我们安装的是2018.01.08
的开发版Jumpserver
,此时的版本信息如下:
commit dfaf029a68f3e3a327a0f22c470306e9bf64aedb Author: ibuler <ibuler@qq.com> Date: Mon Jan 8 15:51:08 2018 +0800 [Bugfix] 资产导入bugfix
安装流程:
$ sudo apt-get update $ sudo apt-get upgrade $ pip3 install --upgrade pip # c/_cffi_backend.c:15:17: fatal error: ffi.h: 没有那个文件或目录 $ sudo apt-get install libffi-dev # Modules/LDAPObject.c:17:18: fatal error: sasl.h: 没有那个文件或目录 $ sudo apt-get install libsasl2-dev $ sudo apt-get install slapd ldap-utils # 需要的数据库 $ sudo apt-get install redis-server $ cd ~ $ git clone https://github.com/jumpserver/jumpserver.git $ cd ~/jumpserver $ git checkout dev # 取消可能影响到我们安装路径的环境变量 $ unset PYTHONPATH $ cd requirements && sudo apt-get install -y $(cat deb_requirements.txt) && pip3 install -r requirements.txt $ cd ~/jumpserver $ cp config_example.py config.py $ cd apps && python3 manage.py makemigrations && python3 manage.py migrate $ cd ~/jumpserver # 安装配置coco,coco被配置用来支持远程登陆 $ git clone https://github.com/jumpserver/coco.git $ cd coco $ cd requirements $ pip3 install -r requirements.txt $ cd ~/jumpserver/coco $ cp conf_example.py conf.py $ cd ~/jumpserver $ python3 run_server.py all & #如果提示 “[service ERROR] Access key is not valid”,则需要执行如下操作 #$ rm -rf coco/keys/.access_key $ python3 coco/run_server.py
如果代码下载失败,可以从本站下载一份代码拷贝。点击这里下载jumpserver,点击这里下载coco
浏览器通过http://127.0.0.1:8080进行访问,默认的用户名密码都是admin
。
上面都启动成功之后,通过如下命令访问jumpserver
#$jumpserver_ip为跳板机的访问IP ,$login_user 为跳板机上为登陆用户分配的用户名 $ ssh $jumpserver_ip -p2222 -l $login_user