今天给大家打来一篇关于sql数据库安全设置 操作步骤： 1、删除危险存储过程 打开企业管理器-工具-SQL 查询分析器，输入下面代码 use master exec sp_dropextendedproc ‘xp_cmdshell’ exec sp_dropextendedproc ‘xp_dirtree’ exec sp_dropextendedproc ‘xp_enumgroups’ exec sp_dropextendedproc ‘xp_fixeddrives’ exec sp_dropextendedproc ‘xp_loginconfig’ exec sp_dropextendedproc ‘xp_enumerrorlogs’ exec sp_dropextendedproc ‘xp_getfiledetails’ exec sp_dropextendedproc ‘Sp_OACreate’ exec sp_dropextendedproc ‘Sp_OADestroy’ exec sp_dropextendedproc ‘Sp_OAGetErrorInfo’ exec sp_dropextendedproc ‘Sp_OAGetProperty’ exec sp_dropextendedproc ‘Sp_OAMethod’ exec sp_dropextendedproc ‘Sp_OASetProperty’ exec sp_dropextendedproc ‘Sp_OAStop’ exec sp_dropextendedproc ‘Xp_regaddmultistring’ exec sp_dropextendedproc ‘Xp_regdeletekey’ exec sp_dropextendedproc ‘Xp_regdeletevalue’ exec sp_dropextendedproc ‘Xp_regenumvalues’ exec sp_dropextendedproc ‘Xp_regread’ exec sp_dropextendedproc ‘Xp_regremovemultistring’ exec sp_dropextendedproc ‘Xp_regwrite’ drop procedure sp_makewebtask go 2、恢复代码 use master exec sp_addextendedproc xp_cmdshell,’xp_cmdshell.dll’ exec sp_addextendedproc xp_dirtree,’xpstar.dll’ exec sp_addextendedproc xp_enumgroups,’xplog70.dll’ exec sp_addextendedproc xp_fixeddrives,’xpstar.dll’ exec sp_addextendedproc xp_loginconfig,’xplog70.dll’ exec sp_addextendedproc xp_enumerrorlogs,’xpstar.dll’ exec sp_addextendedproc xp_getfiledetails,’xpstar.dll’ exec sp_addextendedproc sp_OACreate,’odsole70.dll’ exec sp_addextendedproc sp_OADestroy,’odsole70.dll’ exec sp_addextendedproc sp_OAGetErrorInfo,’odsole70.dll’ exec sp_addextendedproc sp_OAGetProperty,’odsole70.dll’ exec sp_addextendedproc sp_OAMethod,’odsole70.dll’ exec sp_addextendedproc sp_OASetProperty,’odsole70.dll’ exec sp_addextendedproc sp_OAStop,’odsole70.dll’ exec...
教程目的： 使用Linux系统自带的命令logrotate对Nginx日志进行切割。 Nginx安装目录：/usr/local/nginx/ Nginx日志目录：/usr/local/nginx/logs/、/usr/local/nginx/logs/nginx_logs/ 1、添加nginx日志切割脚本 cd /etc/logrotate.d #进入目录 vi /etc/logrotate.d/nginx #编辑脚本 /usr/local/nginx/logs/*.log /usr/local/nginx/logs/nginx_logs/*.log{ missingok dateext notifempty daily rotate 7 sharedscripts postrotate if [ -f /usr/local/nginx/logs/nginx.pid ]; then kill -USR1 `cat /usr/local/nginx/logs/nginx.pid` fi endscript } :wq! #保存退出 chmod +x /etc/logrotate.d/nginx ＃添加执行权限 2、执行脚本 /usr/sbin/logrotate -vf /etc/logrotate.d/nginx 3、添加定时任务 crontab -e #添加以下代码 0 0 * * * /usr/sbin/logrotate -vf /etc/logrotate.d/nginx #每天凌晨定时执行脚本 至此，Linux下nginx日志每天定时切割教程完成。 备注：logrotate相关参数说明 missingok：忽略错误，如“日志文件无法找到”的错误提示。 dateext：切换后的日志文件会附加上一个短横线和YYYYMMDD格式的日期，没有这个配置项会附加一个小数点加一个数字序号 notifempty：如果日志文件为空，不执行切割。 daily:按天切割日志。可用值月：monthly 周：weekly 年：yearly rotate 7：保留最近7天的日志记录 sharedscripts：只为整个日志组运行一次的脚本 postrotate和endscript：里面指定的命令将被执行。 compress:：在轮循任务完成后，已轮循的归档将使用gzip进行压缩。 delaycompress:：总是与compress选项一起用，delaycompress选项指示logrotate不要将最近的归档压缩，压缩将在下一次轮循周期进行。这在你或任何软件仍然需要读取最新归档时很有用。 create 644 root root: 以指定的权限创建全新的日志文件，同时logrotate也会重命名原始日志文件。
【腾讯云】2核2G云服务器新老同享 99元/年，续费同价，云服务器3年机/5年机限时抢购，低至 2.5折
引言：大家在管理Windows Server 2003 服务器的时候，进行远程桌面连接，当输入完账号密码，点确定之后弹出一个提示框“终端服务器超出了最大允许连接数”，如下图所示： 原因：服务器默认情况下，最多只能登录2个链接会话，而且登录远程桌面之后如果没有采用注销的方式退出而是直接关闭远程桌面窗口，实际上远程会话没有释放，继续占用总连接数，当链接数超过最大允许值时就会出现上面提示。 系统运维 www.osyunwei.com 温馨提醒：qihang01原创内容©版权所有,转载请注明出处及原文链接 解决方法： 1、如果是用Windows Xp、Windows Xp SP1、Windows Xp SP2、Windows Server 2003系统进行远程桌面连接，请看下面操作： 开始-运行，然后输入 mstsc /console /v:192.168.1.1:3389 2、如果是用Windows Xp SP3（SP3也是在开始-运行）、Windows Vista、Windows 7、Windows Server 2008系统进行远程桌面连接，请看下面操作： 开始-程序-附件-运行，然后输入 mstsc /admin /v:192.168.1.1:3389 远程连接登录之后，打开任务管理器，切换到用户选项，把之前断开的用户会话全部注销掉，下次记得维护好之后用注销的方式退出，切忌不要直接关闭远程桌面窗口。 系统运维 www.osyunwei.com 温馨提醒：qihang01原创内容©版权所有,转载请注明出处及原文链接 备注：其中192.168.1.1:3389代表远程服务器的IP和端口，改为你自己的即可。
9 月 4 日，微软在美国中南部地区的圣安东尼奥数据中心由于雷电天气影响导致电压激增，数据中心的冷却系统发生故障。为保证数据和硬件完整性，数据中心的自动化措施强制关闭了系统电源以防止机器因过热造成损坏。这一事故引发了 Azure 中断，Office 365 以及 Azure Active Directory 服务都受到影响，并且恢复相关存储服务经历了很长时间。 故障从 9 月 4 日上午 9 点（北京时间 9 月 4 日 17:00）左右开始出现问题，到 9 月 5 日 13 点左右（北京时间 9 月 5 日 21:00 左右），微软大多数受影响服务的存储可用性已经恢复，整个故障中断时间超过 24 小时。 跟踪服务中断的 DownDetector.com 网站显示 Azure 服务中断主要位于德克萨斯州： Azure 官方推特 Azure Support 让用户查看 Azure 状态页面，但是 Azure 服务中断甚至影响到该页面也一度无法访问。Azure Support 将事故称为“网络问题”，并表示中断只会影响美国中南部的客户，但是很多用户表示中断已经影响了包括西欧、亚洲在内的其他地区。 Azure Support 在对用户的回复中澄清了为什么其他地区会受到影响：“在某种程度上，我们所有的数据中心都是相互联系的。因此，如果一个数据中心出现故障，它将转移到其他数据中心。此外，在欧洲的客户可能会在受影响的数据中心托管一些资源。“ 包括 Office 365 和 VSTS （Visual Studio Team Services）在内的近 40 个 Azure 服务受到影响。根据 Office 365 的公告，Office 365 用户遇到的问题类型如下： Exchange – 某些用户可能无法访问网页上的 Outlook。 通过其他协议进行的电子邮件访问则有可能不受影响。 Power BI – 用户可能收到“服务器不可用”错误或可能无法登录。 SharePoint – 大多数影响已得到缓解，但一部分用户可能无法进行更改或更改无法保存。 Microsoft Teams – 用户可能无法访问 Teams 的 Office 文档。 Intune – 受影响的用户可能无法访问 Intune 门户或其他功能。 根据 VSTS 的公告，这次中断影响了使用微软 Visual Studio Team Services 的开发人员，导致他们无法访问帐户，报告仪表板也无法加载。 根据 Microsoft Dynamics 公告，这次中断还影响了 Azure Active Directory，Microsoft Dynamics Finance 以及 Operations 和...
前言 一、什么是配置虚拟主机 二、通过端口区分虚拟主机 三、通过域名区分虚拟主机 阅读本文需要安装Nginx：https://www.cnblogs.com/huangyi-427/p/9229645.html 一、什么是配置虚拟主机 就是在一台服务器启动多个网站 二、通过端口区分虚拟主机 复制一份静态页面 cd /usr/local/nginx cp -r html html81 修改部分内容以示区分 vim /usr/local/nginx/html81/index.html 查看配置文件 more /usr/local/nginx/conf/nginx.conf #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root...
前言 Nginx是一款免费的开源，高性能，可靠，可扩展且可完全扩展的Web服务器，负载均衡器和反向代理软件。 它有一个简单和易于理解的配置语言。 它还支持多种静态模块（自第一个版本开始就存在于Nginx中）和动态模块 （在1.9.11版本中引入 ）。 Nginx中的一个重要模块是ngx_http_stub_status_module模块，它通过“ 状态页面 ”提供对基本Nginx状态信息的访问。 它显示活动客户端连接总数，接受和处理的总数，请求总数以及读取，写入和等待连接数等信息。 在大多数Linux发行版上， Nginx版本随ngx_http_stub_status_module启用。 您可以使用以下命令检查模块是否已启用。 # nginx -V 2>&1 | grep -o with-http_stub_status_module 检查Nginx状态模块 如果在终端中看到–with-http_stub_status_module作为输出，则表示状态模块已启用。 如果上述命令没有返回任何输出，则需要使用-with-http_stub_status_module作为配置参数从源代码编译NGINX ，如图所示。 # wget http://nginx.org/download/nginx-1.13.12.tar.gz # tar xfz nginx-1.13.12.tar.gz # cd nginx-1.13.12/ # ./configure --with-http_stub_status_module # make # make install 在验证模块之后，您还需要在NGINX配置文件/etc/nginx/nginx.conf中启用stub_status模块，以便为该模块设置一个本地可访问的URL（例如http://www.example.com/nginx_status ）状态页面。 location /nginx_status { stub_status; allow 127.0.0.1; #only allow requests from localhost deny all; #deny all other hosts } 启用Nginx状态页面 确保将127.0.0.1替换为服务器的IP地址，并确保只有您可访问此页面。 更改配置后，请确保检查nginx配置是否有任何错误，并使用以下命令重新启动nginx服务以实现最近的更改。 # nginx -t # nginx -s reload 检查Nginx配置 重新加载nginx服务器后，现在您可以使用curl程序访问下面的URL中的Nginx状态页面来查看您的指标。 # curl http://127.0.0.1/nginx_status OR # curl http://www.example.com/nginx_status 检查Nginx状态页面 重要说明 ： ngx_http_stub_status_module模块已被Nginx 1.13.0版本中的ngx_http_api_module模块取代。
今天学派吧-给大家带来一篇nginx配置location总结及rewrite规则写法教程 1. location正则写法 2. Rewrite规则 2.1 flag标志位 2.2 if指令与全局变量 2.3 常用正则 2.4 rewrite实例 1. location正则写法 一个示例： location = / { # 精确匹配 / ，主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。 [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { # 匹配所有以 gif,jpg或jpeg 结尾的请求 # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则 [ configuration E ] } location /images/ { # 字符匹配到 /images/，继续往下，会发现 ^~ 存在 [ configuration F ] }...
为什么用 Nginx? 第一种方案: 使用 Docker 文档中的方法 使用另一个 Docker 镜像，差点成功 最终解决方案 在使用 Docker 容器来开发 PHP 微服务套件的过程中，作者遇到了容器数量过多的问题。 最近，我一直在使用 Docker 容器来开发 PHP 微服务套件。一个问题是 PHP 应用已经搭建，可以与 PHP-FPM 还有 Nginx（取代了简单的 Apche/PHP 环境）一起工作，因此每个 PHP 微服务需要两个容器（以及两个 Docker 镜像）：一个 PHP-FPM 容器和一个 Nginx 容器。 这个应用运行了 6 个以上的服务，做个乘法就知道，在开发和生产之间会有约 30 个容器。于是我决定构建一个单独的 Nginx Docker 镜像，它可以使用 PHP-FPM 的主机名作为环境变量并运行单独的配置文件，而不用为每个容器构建单独的 Nginx 镜像。 在本文中，我介绍了自己从上图中的方法 1 到方法 2 的转换，最后采用的方案中采用了一种新的定制 Docker 镜像。该镜像的代码是开源的，如果读者碰到类似问题，可以提供给大家参考。 为什么用 Nginx? Nginx 和 PHP-FPM 配合使用能使 PHP 应用的性能更好，但不好的地方在于，和 PHP Apache 镜像不同，PHP-FPM Docker 镜像默认不是和和 Nginx 绑定在一起的。如果需要通过 Nginx 容器和 PHP-FPM 连接，需要在 Nginx 配置里为该后端增加 DNS 记录。比如，如果名为 php-fpm-api 的 PHP-FPM 容器正在运行，Nginx 配置文件应该包含下面部分： location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; # This line passes requests through to the PHP-FPM container fastcgi_pass php-fpm-api:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; } 如果只服务于单独的 Nginx 容器，Nginx 配置中容器名字写死还可以接受，但如上所述，需要允许多个 Nginx 容器，每个对应于一个 PHP 服务。创建一个新的 Nginx...
之前用frp做内网穿透，把内网的服务器开放到外网。 如果是http服务的话，80端口的做法是使用二级域名xxx做个A记录指一台没有nginx 之类的服务器IP，然后用浏览器打开xxx.example.com就打开了。其他端口是在frpc.ini里指定的，就加个端口号如xxx.example.com:1234就打开了，这种情况用于外网服务器已经有nginx在运行占用了80端口， 这时如果不想用端口号来打开，就要做三级域名解析，同时nginx做反向代理，把这个1234端口代理到80. 其实只要给 nginx 增加一个简单的配置，就可以将某个域名的流量转发给 frp 了，还可以通过泛解析来映射不同的网站。 配置 nginx： server { listen 80; server_name *.frp.example.com; location / { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host:80; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_hide_header X-Powered-By; } } 上面这段写入/etc/nginx/sites-avaliable/default的最后面，监听*.frp.example.com, 并转发给127.0.0.8081, 接下来只要将frp默认监听 80 端口改成 8081 端口就好了. 配置 frp 服务端： [common] bind_port = 8787 vhost_http_port = 8081 token = passwd max_pool_count = 100 subdomain_host = frp.example.com [xxx] type = http subdomain = xxx 重点在于将 vhost_http_port 设为 8081, 还可以在common下加上dashboard相关的端口，用户，密码等信息。 配置 frp 客户端： [common] server_addr = exampel.com server_port = 8787 token = passwd login_fail_exit = false [xxx] type = http local_port = 80 subdomain = xxx 域名设置： 1, 增加二级域名frp的A解析，到外网服务器IP. 增加三级域名泛解析*.frp的CNAME解析，到frp.example.com. 这时要做完这2个域名解析就可以用xxx.frp.example.com访问了。 参考：http://www.miss.cat/frp-use-80-port-with-nginx/ https://blog.csdn.net/qq_36560161/article/details/79646523 如果是ssh,frpc如下面配置的话，还是一样的，跟http上面讲的东西没有关系： [common] server_addr = example.com server_port = 8787 token = passwd login_fail_exit = false...
选择代理 克服反对意见 服务提供方的好处 可扩展性 服务使用方的好处 更丰富的群集模型 多协议支持 动态服务发现 网络策略 监测 如何更快迁移 导读：随着Service Mesh在最近一年进入人们的视野，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。本文作者所在公司已经从 nginx 迁移到 Envoy。 随着我们下一代产品发布，我们将代理软件从 nginx 切换到 Envoy 。 我们很早就开始关注 Envoy。 公司的一些人之前在 Twitter 工作，其中一些人和 Matt Klein 一起组建了 Twitter 的边缘代理 TFE。 我们知道 Lyft 正在计划建立一个基于 TFE 的开源代理模型，我们对此很感兴趣。 不幸的是，我们刚开始做自己产品的时候它还没有准备好，所以起初我们还是使用 nginx。 我们很高兴看到 Envoy 的最初功能集合中包含了大量灵活运用微服务的想法。 我们更加兴奋地看到它的社区已经成型并且技术已经成熟。 现在 Envoy 提供的功能(相比于 nginx)可以使我们能够更快地为客户提供新功能。当然，Envoy 的功能路线图也非常令人兴奋。 选择代理 在启动Turbine Labs时，我们就知道负载均衡将成为我们基础架构的关键组成部分。 在2015年秋季的时候，代理软件并不是我们今天看到的样子。 我们选择 nginx 是因为它轻巧，经过大量生产环境测试，开源，相对来说易于扩展，并且拥有蓬勃发展的用户群体。然而我们必须做很多额外的工作才能在 nginx 之上构建一个全功能的流量管理解决方案。 服务发现，统计管理和更细粒度的负载均衡是现代基础架构的关键特性。 我们在 nginx 之上来实现这些功能，虽然已经花了很长时间，但仍有很多工作要做。 相比之下，Envoy 有很多非常有用功能（如 gRPC，tracing 等等），同时提供类似（或更好）的性能，稳定性和社区。 克服反对意见 采用任何新技术都需要考虑相反的意见。 由于我们已经部署了代理服务，不仅需要考虑到自己的问题，还需要考虑到客户提出的问题。 对于开源项目，这些问题通常分为以下几类： 我们一直密切关注 Envoy 的开发进展，并对它的成熟速度感到惊讶。已经有不少公司在生产环境使用 Envoy。Envoy 现在是一个 CNCF 项目，这意味着社区是透明和开放的。 代码贡献者来自很多公司，我们也在其中。 成本也是需要考虑的因素。随着 sidecars 成为更普遍的部署方式，代理会得到更广泛的应用。 虽然许多客户将继续集中式运行负载均衡，但我们希望代理软件可以优雅地支持边车部署模型。 Envoy 采用 C++ 11 编写，运行时占用的内存很少，与依赖较重运行时的代理相比，显着减少了 sidecars 部署的负担。 服务提供方的好处 应始终谨慎对待技术堆栈的大型更改。我们没有轻易转向 Envoy，但我们获得的好处以及我们可以传递给我们客户的好处非常显著。 可管理性 从一开始，Envoy 就被设计为可以大规模管理。 我们已经做了很多工作来使我们的基于 nginx 的代理可管理，但是这个配置接口不太容易地暴露给其他工具。 Envoy 数据平面 API 为其集中管理提供了一个开放标准。 我们可以提供一个集中的，开放的控制点，而不是复制配置文件。 可扩展性 nginx 是一个非常成功，稳定的开源项目。 其配置文件和模块生态系统具有较大的外围应用，并有大量现有用户支持。 给 nginx 贡献核心代码是非常有挑战性的，这导致在许多情况下需要编写自定义模块或 Lua 脚本以扩展其功能。 Envoy 更为聚焦，使用更为现代的语言支持改变代理行为。过去几个月中，我们向 Envoy 提交了超过 30 个功能，其中包括 OSX 构建...
前言 配置 1. 在nginx的主配置文件 2. 站点配置 3.验证 4. 遇到问题 前言 fastcgi_cache是一个nginx的插件，用于缓存fastcgi接口的执行结果，例如缓存php的执行结果。特别是php网站的首页与一些非交互页面，利用fastcgi_cache可以大幅度提升访问速度，并且降低php的执行压力。 配置 1. 在nginx的主配置文件 在主配置文件(nginx.conf)中添加缓存域 fastcgi_cache_path /dev/shm/nginx-cache levels=1:2 keys_zone=cgi_wpcache:200m inactive=1d; fastcgi_cache_path:缓存文件的路径，/dev/shm/为tmfs缓存文件系统， 实际储存在内存中，所以读写IO性能更高。 levels:缓存目录的结构层次，例如1:2，缓存文件会就生成在指定目录的再下两层目录中。 keys_zone:缓存域名称，在vhost内进行缓存时需要调用。 inactive:缓存不活动时间，若缓存内容在指定时间内未被访问将会被清理出缓存域。 2. 站点配置 location /archives/ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME /data/webroot/$fastcgi_script_name; include fastcgi_params; fastcgi_cache cgi_wpcache; fastcgi_cache_methods GET HEAD; fastcgi_cache_key $request_method$host$request_uri; fastcgi_cache_valid 200 2d; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; add_header X-Cache “$upstream_cache_status”; } fastcgi_cache:指定缓存域 fastcgi_cache_methods：指定缓存的请求方式 fastcgi_cache_key：指定缓存文件的标识，这个标识会MD5转码存储在缓存域的目录下 fastcgi_cache_valid：指定缓存状态，例如上文中只缓存响应状态码为200的请求所产生的返回页面两天 fastcgi_ignore_headers：默认情况下fastcgi_cache会忽略有特殊header的请求，并不进行缓存，官网说明。但当我们添加这个参数后，这些限制将不在存在。 add_header 将会在返回请求的response的header中添加一个X-Cache字段表示是否进行了缓存。如果需要也可以在nginx日志中通过log_format添加$upstream_cache_status字段 ·MISS 未命中，请求被传送到后端 ·HIT 缓存命中 ·EXPIRED 缓存已经过期请求被传送到后端 ·UPDATING 正在更新缓存，将使用旧的应答 ·STALE 后端将得到过期的应答 3.验证 配置完成后重新加载nginx后通过curl -I 访问如下： [root@localhost local]# curl -I localhost/archives/1.php HTTP/1.1 200 OK Server: nginx/1.14.0 Date: Mon, 25 Jun 2018 06:48:05 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding X-Powered-By: PHP/7.0.30 Expires: Tue, 26 Jun 2018 06:48:05 GMT Cache-Control: max-age=86400 X-Cache: MISS 第一次访问 X-Cache: MISS 说明还未进行缓存。 [root@localhost local]# curl...
今天进腾讯云的控制台 偶然发现腾讯云一直给我提示的漏洞 其中有一个挺为严重的 汗.png 我的网站配置下并没有屏蔽隐藏文件夹例如.git等文件夹的访问 甚至可以直接下载隐藏文件夹的内容 确实是我没有想到的 如果你也有这种情况 就需要进行配置服务器来禁止敏感文件的访问了 否则就直接暴露在大庭广众之下了… nginx的配置很简单 在server{}段内增加 代码如下: location ~ /\. { deny all; } 这样就把所有的隐藏文件夹给屏蔽访问了 如果想单独屏蔽某一隐藏文件夹的访问只需要 location ^~ /.git { return 444; }
今天给大家带来一篇ubuntu安装java8和7的教程。 前言 安装 jdk 切换 jdk 版本 前言 本机装的是 jdk7 ,无奈最近看的源码不少都已经拥抱 jdk8 了。便于调试，安装了新的 java 版本。 安装 jdk 这里简单说明下 Ubuntu 下 jdk8 的安装过程，jdk7 的类似，不再赘述。 下载安装包: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html ，选择 jdk-8u162-linux-x64.tar.gz。 新建目录并解压到该目录 sudo mkdir /usr/lib/java sudo tar zxvf ./jdk-8u162-linux-x64.tar.gz -C /usr/lib/java sudo mv /usr/lib/java/jdk1.8.0_162/ /usr/lib/java/jdk8 打开配置文件, sudo gedit /etc/profile, 在文件中加入以下内容 export JAVA_HOME=/usr/lib/java/jdk8 export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH 将新安装的 jdk 加入到选项里 sudo update-alternatives --install /usr/bin/java java /usr/lib/java/jdk8/bin/java 300 sudo update-alternatives --install /usr/bin/javac javac /usr/lib/java/jdk8/bin/javac 300 通过 sudo update-alternatives –config java 指令，选择相应的jdk即可！ $ sudo update-alternatives --config java There are 3 choices for the alternative java (providing /usr/bin/java). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 1071 auto mode * 1 /usr/lib/java/jdk7/bin/java 300 manual mode 2 /usr/lib/java/jdk8/bin/java 300 manual mode 3 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 1071 manual mode Press enter...
阿里云午夜在官网、微博发布了故障公告： 6月27日下午，我们在运维上的一个操作失误，导致一些客户访问阿里云官网控制台和使用部分产品功能出现问题，引发了大量吐槽。故障于北京时间2018年6月27日16:21左右开始，16:50分开始陆续恢复。 经过紧急技术复盘，故障原因如下： 当天下午，工程师团队在上线一个自动化运维新功能中，执行了一项变更验证操作。这一功能在测试环境验证中并未发生问题，上线到自动化运维系统后，触发了一个未知代码bug。错误代码禁用了部分内部IP，导致部分产品访问链路不通。 后续人工介入后，工程师团队快速定位问题进行了恢复。 受影响范围包括阿里云官网控制台，以及MQ、NAS、OSS等产品功能。 对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。 下午 16:30 左右，微信朋友圈、微信群、微博出现阿里云故障消息，故障原因主要体现在阿里云官网、控制台无法访问，尝试登陆阿里云官网，显示如下： 官网有时候可以访问，有时候显示502错误的网关，即使官网可以访时，点击登陆，页面只会刷新，登陆不了。 一位行业从业者发推称：阿里云的函数计算挂了，导致线上故障。打算马上降级到本地计算，结果阿里云的 Kubernetes 也挂了。想着挨个机器手工改一下，发现 OSS 也挂了…整个过程没有报警，因为 SLS 也挂了…（备注：未得到阿里云官方确认） 官网公告称16:21左右开始，阿里云官网的部分管控功能，及MQ、NAS、OSS等产品的部分功能出现故障，以下为全文： 阿里云官网通告：6月27日阿里云部分产品及账号登录访问异常通告 【阿里云】【网络】【异常通告】 异常时间：北京时间2018年6月27日16:21左右。 异常概述：于北京时间2018年6月27日16:21左右开始，阿里云官网的部分管控功能，及MQ、NAS、OSS等产品的部分功能出现访问异常，阿里云工程师正在紧急处理中，请您稍后重试。 【异常更新】 北京时间2018年6月27日 16:50 目前受影响的业务正在逐步恢复中，若遇到异常，请您稍等后重试。 【异常更新】 北京时间2018年6月27日 17:30 目前受影响的业务大部分已经恢复正常，请您确认。若还有异常，请您跟我们反馈，谢谢。 故障时间 50 分钟左右，故障原因，阿里云尚未披露。
lamp架构wordpress和discuzx教程 背景 虚拟主机 fastcgi 部署流程 部署架构 环境 架构图 编译软件 安装开发环境和必要的包 编译httpd 编译php 安装mariadb 配置文件修改 修改httpd主机 修改fast-cgi主机 配置mysql 宿主机的hosts文件修改 安装wordpress和Discuzx 背景 虚拟主机 如今服务器的配置提升明显，单一主机上部署单一网站会对主机造成大量的性能损失，因此web服务虚拟主机的技术应运而生。所谓虚拟主机指的是在一台机器上运行多个网站（如company1.example.com和company2.example.com）的做法 。虚拟主机可以是“ 基于IP的 ”，这意味着每个网站都有不同的IP地址，或者“ 基于名称 ”，这意味着每个IP地址上都有多个名称，或者“基于端口”，这意味着在同一ip的不同端口上提供不同的网站，通过这些方法使得他们在同一台物理服务器上运行的事实对最终用户来说并不明显。 Apache是第一批支持基于IP的虚拟主机的服务器之一。Apache的版本1.1及更高版本支持基于IP和基于名称的虚拟主机（虚拟主机）。虚拟主机的后一种变型有时也被称为基于主机的或非IP虚拟主机。 fastcgi FastCGI像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。它还支持分布式的运算, 即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。 FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail- Over特性等等。 部署流程 部署架构 环境 3台主机用于分别部署httpd，php和mysql，实现分离 软件版本 架构图 编译软件 这里我们需要编译的软件为httpd和php，mysql可以考虑使用二进制包或者直接官方yum安装 安装开发环境和必要的包 1.安装centos开发工具包 yum groupinstall "development tools" -y 2.安装编译httpd和php需要的包 #部分包需要epel源 #yum install epel-release -y yum install pcre-devel openssl-devel expat-devel libxml2-devel bzip2-devel libmcrypt-devel -y 编译httpd 这里在192.168.99.130机器上编译httpd2.4 1.创建apache用户 useradd -r apache -s /sbin/nologin 2.解压httpd，apr，apr-util源码包，这里需要的包均可在httpd官网下到 tar xvf httpd-2.4.33.tar.bz2 tar xvf apr-1.6.2.tar.gz tar xvf apr-util-1.6.1.tar.gz 3.编译httpd #移动解压的apr和apr-util到指定的httpd源码目录可以省去分别编译3个程序 mv apr-1.6.2 httpd-2.4.33/srclib/apr mv apr-util-1.6.1 httpd-2.4.33/srclib/apr-util #编译参数，具体含义可以参考./configure的帮助文档或者官方文档 ./configure \ --prefix=/app/httpd24 \ --enable-so \ --enable-ssl \ --enable-cgi \ --enable-rewrite \ --with-zlib \ --with-pcre \ --with-included-apr \...
前言 现在NGINX越来越普及了、通过很多面板都可以简单搭建、小白都可以操作、但是出了问题、不知道如何下手、今天我们总结下教程 学派吧-小编初到一家公司做运维的工作，刚来的第一天就开始部署LNMP(Linux+Nginx+MySQL+PHP)环境，结果出现了问题。 他来向我请教，具体问题现象、原因和解决思路如下: 问题一 nginx进程CPU和内存不均衡，某个进程占用资源特别高，如何解决？ 回答：我让学派吧-小编绑定下CPU的亲缘性(设置nginx配置worker_cpu_affinity项为auto，auto这个特殊值(1.9.10版本)允许自动绑定工作进程到可用的CPU上。)，绑定后CPU和内存使用就均衡了。 问题二 学派吧-小编又问close系统调用消耗很高怎么解决？ 回答：且听我娓娓道来，继续看下文。 strace−cpstrace−cp(pgrep -n nginx) $ top 系统32c的，top查看负载去到75.14， 查看过nginx和php-fpm的 错误日志也没有什么发现。 strace 跟踪close的系统调用， 都是以下的信息： strace−T−ttpstrace−T−ttp(pgrep -n nginx) 2&>1 |grep -B 10 close > ./close.log $ lsof | more 遂怀疑是连接创建关闭消耗了太多的资源，便让学派吧-小编加了台机器专门跑nginx， 前端挂了个nginx用长连接跟后端的nginx连接，接了个nginx之后负载果然就下来了。 前端未挂nginx压测ab压测结果: 前端挂了nginx压测ab压测结果: tps基本没变第一个Time per，requset快了87.52%。 接着继续排查tps上不去的原因，继续strace后端的nginx。 strace−cpstrace−cp(pgrep -n nginx) 发现现在是wrtiev占用高了，strace 跟踪close的系统调用， 发现很多以下的输出： connect(26, {sa_family=AF_INET, sin_port=htons(9000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) 问题应该不是在nginx上， 应该是在php-fpm上了。 继续 strace−cpstrace−cp(pgrep -n php-fpm) 显示下图所示： access cpu时间消耗最多那就先 排查access 系统调用： strace−T−ttpstrace−T−ttp(pgrep -n php-fpm) 2&>1 | grep -B 10 access > ./access.log php-fpm进程频繁的去读取文件，整个操 作下来花费4ms的时间。 然后排查recvfrom： strace−T−ttpstrace−T−ttp(pgrep -n php-fpm) 2&>1 | grep -B 10 recvfrom > ./recvfrom.log 频繁的去访问10.0.0.156的6379,端口，明显就是访问redis读取数据的过程， 整个过程花费12ms。 让学派吧-小编把上面两个strace信息发给开发，第一个得到回复是老版本的流程， 新版本改了，但还是有些判断没有处理。 第二个问题让开发使用redis连接池，无需频繁创建连接读取数据， 频繁创建连接开销很大的。 总 结 当遇上性能问题时，排查日志无法解决时，使用strace工具来查看一下系统调用，看时间到底消耗在哪里了，可以轻松的找到问题所在。欢迎关注我们学派吧
nginx配置location教程及rewrite规则教程 location正则写法 实际使用建议 Rewrite规则 flag标志位 if指令与全局变量 if判断指令 全局变量 常用正则 rewrite实例 location正则写法 一个示例： location = / { # 精确匹配 / ，主机名后面不能带任何字符串 [ configuration A ] } location / { # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求 # 但是正则和最长字符串会优先匹配 [ configuration B ] } location /documents/ { # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration C ] } location ~ /documents/Abc { # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索 # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条 [ configuration CC ] } location ^~ /images/ { # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。 [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { # 匹配所有以 gif,jpg或jpeg 结尾的请求 # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则 [ configuration E ] } location /images/ { # 字符匹配到 /images/，继续往下，会发现 ^~ 存在 [ configuration F ] } location /images/abc { #...
Nginx配置 main模块 events 模块 http模块 sendfile keepalive 超时 map proxy openfile client buffer Gzip fastcgi cache server模块 正则 Rewrite 文件缓存 FPM HTTPS upstream模块 默认轮询（加权） 最小连接数 IP Hash FPM配置 global全局配置 进程池配置 Nginx配置 nginx的配置主要分为6个区域，main（全局设置），events（工作模式），http（http服务），upstream（负载均衡），server（主机设置），location（url规则）。 main events { } http { upstream domain { } server { location { } } } main模块 user www www; worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; error_log /home/git/logs/error_log error; pid /usr/local/var/run/nginx/nginx.pid; worker_rlimit_nofile 65535; user 用来指定worker进程运行的用户及用户组 worker_processes 来指定开启的worker进程数，如果是多核CPU，建议指定和CPU的数量一样的进程数即可，这里的CPU数量指物理核数。 worker_cpu_affinity 将不同的woker进程绑定到不同的cpu，这里指绑定到CPU[0-3]，降低由于多CPU核切换造成的寄存器等现场重建带来的性能损耗。 error_log 用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少。 pid 指定master进程ID存储位置。 worker_rlimit_nofile 指定最多打开的文件描述符(fd)，查看用户级fd限制（ulimit -n），查看系统级fd限制（cat /proc/sys/fs/file-max），系统fd与系统内存有关。 events 模块 events用来指定nginx的事件模型及连接数上限。 events { use epoll; worker_connections 65535; multi_accept on; } use 用来指定具体的事件模型，包括select、poll、epoll、kqueue、/dev/poll、eventport、rtsig，其中select、poll是标准的事件模型，epoll（用于linux平台）和kqueue（用于BSD平台）是高效的事件模型。 worker_connections 定义每个nginx进程接收的最大连接数，最大客户端连接数Max_clients = worker_processes * worker_connections / 2，而作为反向代理时，Max_clients = worker_processes * worker_connections / 4。 multi_accept 让NGINX在接收到一个新连接通知后调用accept()来接受尽可能多的连接。 http模块 负责http服务器的设置，包括虚拟主机和反向代理。 http{ server_tokens off; include mime.types; default_type application/octet-stream;...
