Apache 重定向(301)到新域名

目录 原创

Apache下301重定向代码(因为我使用的是LINUX + APACHE 所以本文仅限APACHE服务器使用。)

一、新建.htaccess文件,输入下列内容(需要开启mod_rewrite):

· 启用mod_rewrite模块
在conf目录的httpd.conf文件中找到
LoadModule rewrite_module modules/mod_rewrite.so
将这一行前面的#去掉。
· 在要支持url rewirte的目录启用
Options FollowSymLinks和AllowOverride All

1)将不带WWW的域名转向到带WWW的域名下

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^001.com [NC]
RewriteRule ^(.*)$ http://www.001.com/$1 [L,R=301]

2)重定向到新域名

Options +FollowSymLinks
RewriteEngine on
RewriteRule ^(.*)$ http://www.001.com/$1 [L,R=301]

3)使用正则进行301重定向,实现伪静态

Options +FollowSymLinks
RewriteEngine on
RewriteRule ^news-(.+)\.html$ news.php?id=$1

将news.php?id=123这样的地址转向到news-123.html

二、Apache下vhosts.conf中配置301重定向

为实现URL规范化,SEO通常将不带WWW的域名转向到带WWW域名,vhosts.conf中配置为:

<VirtualHost *:80>
    ServerName www.001.com
    DocumentRoot /home/fari001Com
</VirtualHost>

<VirtualHost *:80>
    ServerName fari001.com
    RedirectMatch permanent ^/(.*) http://www.001.com/$1
</VirtualHost>

其中开启HTTPS后,不带WWW域名转向WWW域名配置为:

<VirtualHost *:443>
    ServerName fari001.com
    RedirectMatch permanent ^/(.*) https://www.001.com/$1
</VirtualHost>

HTTP跳转HTTPS配置为:

<VirtualHost *:80>
    ServerName fari001.com
    RedirectMatch permanent ^/(.*) https://www.001.com/$1
</VirtualHost>

*群晖存储空间损毁/Btrfs文件系统损坏数据恢复教程

目录 原创

· 感谢 https://roov.org/2017/11/btrfs-repair/ 的教程提供指导,本文在原教程出现报错的地方进行了修改和完善,部分图片因恢复数据时未截图转载自原教程。已成功恢复5.4T的数据。

· 恢复数据操作系统 Ubuntu 16.04 LTS ( 系统镜像下载地址: http://download.orcy.net:8027/Ubuntu/16.04/

使用的黑群晖系统,在偶尔一次断电重启后,有一个4x2T硬盘的存储空间出现了“已损毁”状态,而网络上搜索到的教程和案例都是使用 Ext4 作为文件系统,那么只需要用 UFS explorer 来修复就好了。偏偏群晖推荐用的是 Btrfs 文件系统,当前状态系统中无法读取文件,但 RAID 并没有异常,无需进行 RAID 清理。通过查看 S.M.A.R.T 状态,发现所有硬盘均处于健康状态,于是跳过这一步。接下来我们需要引导到 Ubuntu 系统并尝试挂载 RAID。

进入Ubuntu系统后第一件事是安装必要的工具包以及挂载 RAID,打开终端并以 root 身份(sudo -i)执行以下操作:


apt-get update
apt-get install mdadm lvm2 btrfs-prog
mdadm -Asf && vgchange -ay

正常完成后可以在磁盘管理中看到 RAID 阵列,但是由于文件系统损坏,此时是无法挂载的。

切换回终端,运行以下命令:

btrfs-find-root /dev/vg1/volume-1 &> /home/3.txt

注意:/dev/vg1/volume-1 此位置为系统内的位置,系统不同可能默认路径不一致,以你自己的位置为准,如果使用挂载位置可能会出现报错无法扫描。

运行过程可能需要10-30分钟,期间是没有任何回显的。等待运行完成后终端会返回命令提示符,这时我们打开 /home/3.txt 文件,可以看到如下内容:

我们需要用到的数据是 Well block 后面的这一串数字,其后的 gen 数字越高,恢复的可能性越大。下一步使用找到的 tree root 来模拟修复,到目前为止的所有操作都不会对硬盘进行写入和修改,也不会破坏任何数据。

btrfs check --tree-root <block> --super <sup> /dev/vg1/volume1
#<block>为上一步中的数值,按 gen 数字从高到低依次尝试使用
#<sup> 可以尝试0,1或2。

如果 block 有效,运行结果末尾应当类似于以下图示:

如果最后回显不是以上格式,表明这一条 无效,需要继续尝试下一条。在确认看到以上提示后,我们尝试将数据导出。

btrfs restore /dev/vg1/colume1 /data5 -D -v -F -i -t <block>

此时仍然使用上一步中的 block 值,将 /data5 改为导出目录,需要确保留有足够空间存储文件。如果文件名包含特殊符号可能导致导出中断,将目标分区格式化为 Ext3/4 即可。

如果导出正常进行,会看到类似上图的提示,此处没有进度提示,可以自行前往导出目录查看。如果导出失败会给出其他提示,在确认导出分区是 Ext3/4 的情况下,则只能退回上一步尝试其他 block 值。

如下图,成功恢复5.4T左右的数据到/data5目录下:

到目前为止我们并没有对数据盘进行任何写入和修改操作,如果因为种种原因无法导出,或是导出过程异常中断,仍然可以通过修复原盘的方式来挽回数据。不过请注意,此步骤有可能会损坏数据,如果你不能接受任何风险,请停止执行并联系专业机构。

以下修复步骤博主未亲自测试,请谨慎操作!

btrfs check --repair --tree-root <block> --super <sup>
#使用之前步骤中正常回显的 <block> 及 <sup> 值进行正式修复,确认操作完成后执行:
btrfs rescue super-recover /dev/vg1/volume-1

提示确认目标分区是 Btrfs 文件系统,否则会损坏数据,输入 y 确认操作。等待数秒后再次回到提示符,如果一切顺利,此时已经可以通过磁盘管理工具挂载 Btrfs 分区了。不过群晖很大几率不会识别修复后的文件系统,还是建议将数据导出后再将硬盘还原。

docker自动启动容器策略

目录 原创

Docker提供了重新启动策略 来控制容器在退出时或Docker重新启动时是否自动启动。重新启动策略可确保以正确的顺序启动链接的容器。

1.使用重启策略

要为容器配置重新启动策略,请–restart在使用该docker run命令时使用该标志。–restart标志的值可以是以下任何一种:

标志描述
no不要自动重启容器。(默认)
on-failure如果容器由于错误而退出,则重新启动容器,该错误表现为非零退出代码。
always如果容器停止,请务必重启容器。如果手动停止,则仅在Docker守护程序重新启动或手动重新启动容器本身时才重新启动。
unless-stopped在容器退出时总是重启容器,但是不考虑在Docker守护进程启动时就已经停止了的容器

以下示例启动Redis容器并将其配置为始终重新启动,除非明确停止或重新启动Docker。

docker run -dit --restart unless-stopped redis

2.重启策略详情

使用重启策略时请记住以下几点:

重启策略仅在容器成功启动后生效。在这种情况下,成功启动意味着容器启动至少10秒并且Docker已开始监视它。这可以防止根本不启动的容器进入重启循环。

如果手动停止容器,则会忽略其重新启动策略,直到Docker守护程序重新启动或手动重新启动容器。这是防止重启循环的另一种尝试。

重新启动策略仅适用于容器。群组服务的重新启动策略配置不同。请参阅与服务重新启动相关的标志。

3.如果run时没有添加restart 可以通过update命令追加

以下示例为Redis容器追加重启策略

docker update --restart=always redis