Gitea

一直觉得gitblit界面比较low,而且缺少基本的issue这样的功能,所以打算升级一下,有几个可能的选择:

gitlab gogs gitea

gitlab功能最强大,但是也安装复杂,最重要的是对系统的要求比较高不适合于小团队的;

gogs是gitea的爹,安装试用了一下,权限控制的功能实在是太差了。给用户加入一个organiaztion,然后呢,它就可以查看这个org下所有的repo,这也太夸张了吧?原因据说是gogs因为只有一个维护者,比较固执。

gitea是在gogs的基本上扩展的,权限上的功能有所改进,基本满足需求。

安装过程,非常简单:

  1. 在Linux上合建git用户,创建/home/git目录,并切换到此目录,同时切换到这个git用户最为合适;
  2. 下载gitea二进制文件只有一个文件gitea;[参考] 下载最新的版本就是;
  3. 执行gitea web,启动成功了!
  4. 访问http://youhost:3000/点login进入install界面;注意之前就建议过切换到git用户,否则有一些参数需要修;
  5. 切换到root用户,自行创建gitea.serivce并存放到/etc/systemd/system [参考]
  6. 执行systemctl enable gitea,启用gitea服务(自动运行)。[参考]
  7. 通过systemctl start gitea,然后通过3000端口可以访问表示服务加载正常了。

几个技巧注意一下:

  1. 资料说可以在custom/templates/中添加自定义模板从而修改界面,我测试发现有问题,后经检查发现一定要在gitea.service中设置正确的gitea home(按照我上面的描述应该是指向/home/git这个目录),相应的custom,data,gitea-repositories,log目录等均创建于此目录下,如果在gitea.service中设置的home目录不正确,则会在错误的目录下搜索tempaltes目录导致不能生效;
  2. 不要让用户加入任何组织,而是在组织内创建team,让用户加入team,这样用户可以查看:自己加入的,所属team加入的任意repo,并且可以查看team归属组织的基本信息,但不能查看(列出)其它未授权的repo;如果不让用户加入某个组织的team,则用户只能查看其加入的repo,即使这个repo属于某个组织,查看组织基本信息时也会显示404。
  3. 没找到gitea dump命令指定输出目录的参数,指定临时文件无效,最终文件仍然生成在“当前目录”,注意不是gitea所在目录。
  4. 放一个我自己用的定时任务脚本:备份整个gitea数据,保留5个备份,通过rclone同步到网盘;
  5. 直接下载的giteaweb是一个带版本号的文件,可以通过ln -s创建一个名gitea链接,这样以后升级时只要下载一个新版本并重新设置链接即可;

!/bin/bash
echo ‘do backup now’
cd /home/git/backup/
sudo -u git /home/git/gitea dump
echo ‘remove expired backups’
ls -1tr | head -n -5 | xargs -d ‘\n’ rm -f —
echo ‘sync with OneDrive’
rclone sync /home/git/backup OneDrive:/backup/gitea/

Continue Reading

ESXi单个主机定时开关机的设置

居然有人留言了,我把几个我觉得可能比较重点的地方重新标一下:)

自己在家里折腾单个ESXi主机,为了节能计划在晚上自动关机。折腾了一阵,基本搞定了。
ESXi的版本是6.7:)如果版本差异太大可能不适用。
1. 首先是如何定时关机的问题

首先是关机的问题服务器系统不存在计划性关机的功能,只能通过脚本实现。
在esxi中不支持cron命令,只能直接编辑cron文件,文件文件的路径是:
/var/spool/crontab/root
真接修改这个root文件意义并不大,因为一旦ESXi重启,这个文件会被重置。此时需要修改/etc/rc.local.d./local.sh,在exit 0这一行之前添加如下的脚本:

##以#开头的是注释行,可不添加
#get the cron service pid and kill it.
#杀掉已经存在的cron进程
/bin/kill $(cat /var/run/crond.pid)

#add shutdown script to crontab(root)
#修改/var/spool/crontab/root文件,增加相应的执行配置
#待修改的内容包括:
# 45 17 * * * 执行的时间,与cron相同,注意是UTC时间需换算
#/vmfs/volumnes/datastore1/autoshutdown.sh执行脚本路径
#注意一定要保存到datastore1这样的重启不会丢失的位置
#/var/spool/cron/crontabs/root是root用户cron配置文件位置,一般不用修改
/bin/echo ’45 17 * * * /vmfs/volumes/datastore1/autoshutdown.sh’ >> /var/spool/cron/crontabs/root

#restart cron service
#重启cron进程(将加载修改后的root文件)
/usr/lib/vmware/busybox/bin/busybox crond

  • 注意注意注意
    修改完/etc/rc.local.d./local.sh文件后,工作没有结束,需要执行一次/sbin/auto-backup.sh,将修改后的local.sh文件保存,否则结果将和之前的root文件一样,重启后丢失。
  • 上面操作的实质是在ESXi重新启动时,生成(修改)/var/spool/crontab/root文件,添加自动关机的执行脚本,因此必须重启一次机器才能生效(或者手工执行一次这个脚本)
  • 一定要保存在存放虚拟机的存储空间中,这样可确保脚本不会因为重启而丢失。

2. 接下来是关机脚本的内容

#!/bin/sh

#shutdown all VMs(2,3,9 is VMID,add your VMIDs here)
vim-cmd vmsvc/power.off 2
vim-cmd vmsvc/power.off 3
vim-cmd vmsvc/power.off 9

#Poweroff Host
/sbin/poweroff

脚本中的vim-cmd vmsvc/power.off 2是关机命令,将对指定的虚拟机(VMID)发送关机命令,在宿主机关机前关闭所有虚拟机,这一操作是否有必要我不确定。我的ESXi上运行了NAS,为保护数据加这一段。
最后是关机命令。

后面查了一下,其实是有点画蛇添足了,因为poweroff就相当于直接拔插头……应该用power.shutdown,但是这个命令是异步的,后面直接跟/sbin/poweroff的话,效果未知:)

后面干脆改了,因为只有NAS是一直开机,其它虚拟机可能是不开机的,所以在NAS中自己定义的了一个计划性关机,这一部分相当于无效,可以只保留/sbin/poweroff。

附几个相关命令:
vim-cmd vmsvc/getallvms 查询所有已配置的虚拟机,可获得VMID
vim-cmd vmsvc/power.getstate VMID 通过VMID查询相应的虚拟机的当前状态(开关机)
vim-cmd vmsvc/power.shutdown VMID发送关机信号(命令),但操作系统未必会真正关机。
vim-cmd vmsvc/power.off VMID 直接关机(相当于关电源)

3. 开机:)
通过ESXi是不能实现开机,可以借助如下方案:
BIOS如果支持定时开机,可以使用,就是需要修改配置时很麻烦。
BIOS中可设置断电后再恢复时自动开机,配合智能插座的定时通断电功能,实现定时开机。
注意:这个功能可能对某些主板是无效的!我目前使用的这个主板的设置就是:只有当意外断电(非正常关机)后断电再通电时自动启动,如果是正常关机后哪怕再断电通电也不会开机。
BIOS中可设置WOL唤醒,通过路由器等执行WOL唤醒脚本:)

Continue Reading

Rime输入法配置心得

Rime相当好,在各个平台(win,osx,ios,android)我都用上了。

目前来说,在win/osx/ios上使用起来都非常顺手,而android略感诡异(键盘布局),用得上,以后再折腾。
其中win/osx相对来说配置基本上是一致的,后面的说明也基本上是以PC(win/osx)为主,而ios平台的则完全是因为它本身的配置就非常实用了,唯一需要做的就是导入合适的码表和熟悉的wubi86配置。
以pc平台的配置来说几个关键的地方:

1. 输入法的自定义扩展配置文件名
比如:default.yaml对应的扩展配置文件名是default.custom.yaml
而相应的输入法,比如wubi86.schema.yaml对应的配置文件不是wubi86.schema.custom.yaml,而是wubi86.custom.yaml

这一点让我折腾了很久,不知为什么配置就是不生效。2. 自定义配置文件配置项的写法
假设原有配置文件(x.yaml),内容大体如此:

x:
a: 1
b: 2
y:
p: 3
q: 4
z: 5
M:
j: 5

自定义配置文件中有两种指定方式指定配置项,例如:

patch:

x:
y:
z: true

即采用与原配置文件相同的缩进的方式配置自定义的配置项,这种方法一般情况下是错误的!
因为这种情况下不只是最末端的节点被替换了,是整个顶端起被替换了。
比如,前面这种情况,合并后的配置文件中,x中的a,b项,y中的p,q项都没有了,最终生成的配置文件是:

x:
y:
z: true
M:
j: 5

另一种方法是使用/来分割不同级别的配置项名,这是一般情况下的正确用法。
如:

patch:
x/y/z: true

当这个文件和原文件合并后,生成的最终配置文件是:

x:
a: 1
b: 2
y:
p: 3
q: 4
z: true
M:
j: 5

3. 反查无效
网上下载的wubi86的配置文件中可指定相应的pinyin_simp输入法为相应的反查输入法,但是反查无效。
此时需要检查几项:

  • 对应的输入法名称是否正确(pinyin_simp就是正确的输入方案名称,且这个输入方案并不需要在default.yaml中指定<即这个输入法可以作为纯粹的反查输入法,在输入法列表中是不可见的>)
  • 对应的输入法是否有码表文件(pinyin.dict.yaml是相应输入方案的码表,已经编译的码表<table.bin>文件是不能实现反查的,大部分情况下是这个原因)

4. 中英文输入状态与中英文标点状态
先明确一点:

  • 英文输入状态下,只能输入英文标点,只有中文输入状态下才有中英文标点之分。

另明确以下操作习惯:

  • 切换到输入法时多半是要输入中文
  • 切换到中文时多半是要输入中文标点
  • 一般情况下不会操作切换半角/全角
  • 一般情况下不会操作切换标准字符集(GB)与扩展字符集(GBK)

因此,配置的内容如下:

  • ascii_mode/reset=0,表示任何情况下从其它输入法切回rime时重置(reset)为中文;
  • ascii_punct/reset=0,表示任何情况下从其它输入法切回rime时重置(reset)为中文标点,原因是:默认为中文自然是中文标点;
  • full_shape不做reset设置,表示不会重置full_shape设置,即沿用上一输入法的全角半角状态。
  • extend_charset不做reset设置,表示不会重置字符集的设置。

 

 

 

 

 

 

 

Continue Reading

测试千兆内网速度

家里折腾完了墙布之后,想把之前用接线子连接的网线改成模块对接方式,更好看点(其实隐藏在开关面板盒子里根本看不见!),就买了几个模块然后接上:)结果千兆变百兆了。

手上没有测线仪,不知道哪里有问题,线头又比较短了,不敢随便减了再接,所以又折腾了一个测线仪,#4线(蓝)没接紧!

再测试NAS复制文件,最大还是11M,这就奇怪了!再测一次模块 到路由器,1000M正确的。突然想起,更换过一根NAS的线(成品线),我想当然的认为是5E以上的,一看5……换掉,速度立刻到了50M+

因为复制文件还受硬盘速度隐藏,为了确认一下网速,又下了个iperf测试一下网速:

服务端”

iperf3 -s

只要一个-s参数就行,有些文章写了需要 -s -u 命令(udp模式),可能是老版本的,新版本应该是不需要再区分了。

客户端:

iperf3 -c -u -b 1000M -t 60 -i 5

-c客户端模式
-uUDP模式
-b测试目标带宽:这个不是测试的传输文件大小,如果指定的是100M哪怕实际带宽有1G,也只能测出100M
-t测试传输时长(秒)
-i每次传输间隔时长(秒)

实际测试带宽 890Mbits左右,通信路径是:虚拟服务器-》物理服务器-》路由器-》模块转接1-》路由器2-》模块转接2-》客户端,中间经过了3跳,还有各种影响,这个带宽还是让人满意的。

Continue Reading

记录一下我的云端备份脚本

rem set ENV
path %PATH%;c:\progra~1\winrar\
path %PATH%;c:\windows\system32
path %PATH%;C:\green\rclone\
rem BACKUP NOW
set backupSource=c:\gitresp\
set backupPath=C:\OneDri~1.abc\vps.qc\git\
set fileName=gitbak_%date:~0,4%%date:~5,2%%date:~8,2%
set fullFileName=%backupPath%%fileName%.rar
echo %fullFileName%
rar a %fullFileName% %backupSource% -r
echo %fullFileName%
rem REMOVE OLD ARCHIVE
cd %backupPath%
forfiles /D -7 /c "cmd /c del /Q @file"
rem SYNC
rclone sync %backupPath% onedrive:backup\git\

计划任务,定期执行,将指定的目录(backupSource)通过rar(需要先安装winrar或其它命令行)压缩为gitbak_年份日期.rar的名称,并放到backupPath目录下。

执行forfiles删除7天外的文件。

执行rclone(需要事先下载rclone并配置相应的OneDrive的登录信息),将相应的备份目录,同步到云端的指定目录(backup\git)。

先通过Path命令添加winrar,rclone等执行文件目录。

Continue Reading

纯文本方式粘贴Everywhere:)

今天搞定一个挺有用的快捷键:经常需要复制文本以plain text方式粘贴,但在OSX下挺不方便的。网上的教程大部分是说option+command+v可以有match formatting的方式粘贴,实际上这个快捷键基本上无效而且即使粘贴了也没完全达到paste as unformatted的效果。

解决方案分两步:
1. 先写一段脚本,内容相当简单,就一行,这个脚本的功效是:把当前剪贴板的内容转换成无格式的文本。

set the clipboard to string of (the clipboard as record)

补充:第2天来发现这段代码又不能工作了,原因不明,换了一段代码又可以了,用的时候自己试吧

set the clipboard to «class ktxt» of ((the clipboard as text) as record)

 

2. 用BTT(BetterTouchTools)创建快捷键,比如:ctrl+option+command+v
这个快捷键得有二个Action,第一个Action是执行上面的脚本,转换剪贴板的文本,注意一定要选择blocking方式执行。

注意在打开的脚本编辑(选择)窗口中一定不能勾选下面这个勾(Run in background),否则即使你前面选择的是blocking也会自动改成async(异步)执行。

第二步其实很简单,就是触发一个粘贴的快捷键Command+V把剪贴板的内容粘贴出来。
如果第一步是用异步的方式执行的,则第2步与第1步会同时执行,此时可能尚未完成文本内容的转换,粘贴的结果是未知的,因此一定要同步(blocking)执行。

也许使用Automator+Script也能达到同样的效果,不过我正好有BTT就省事了。

Continue Reading

全面转移到vim(MacVim)

之前一直用Sublime,原因无它:启动快!当你想打开一个文本文件,可能是个配置文件,也可能是个普通文本文件,又或者一段代码,甚至是一个10M的TXT电子书,最想要的是在2秒内打开它!Sublime完全可以满足这一点:)

几个我算是用过一段时间的文本编辑器器的几个关键我我大致比较了一下:
冷启动速度(启动进程,不打开任何文件)

vim<sublime<vscode<atom
vim最快但sublime也不相上下,大概都是在1.5~2.5秒内,相比之下VSCode就延时比较明显了至少需要3秒,ATOM就不提了,哈哈。

已启动的情况下打开大文件
三者没有特别明显的时间差别,但仍然能感觉到vim最快,奇怪的是感觉vsc的加载速度甚至比sublime还要快。

我的主要用途是:
1. 编辑一般文本文件,但不会做开发、调试之类(习惯IDE工具)
2. 处理TXT小说……哈哈
结合这两个用途而言,其实Sublime完全满足我的需要,但它需要破解又想试试更专业的工具,尝试了一翻之后,真心觉得好用。

有几个重要的经验(针对我的需求,特殊需求的人员就自己去折腾了),反正都是配置~/.vimrc,具体方法不说了,无非就是~/.vimrc(文件)和~/.vim目录(里面含有Color/Plugin等子目录)

对中文和OSX系统来说重要的两个配置

“支持的换行模式
set ffs=unix,dos,mac
“支持的编码格式
set fileencodings=utf-8,ucs-bom,gb18030,gbk,gb2312,cp936

配置了这个之后打开上述编码(换行)格式的文件就能自动处理,不会有乱码之类的问题。在OSX下默认UTF8,在Sublime中需要安装一个插件来转换编码这个就不需要折腾了。

影响整体效果的配置一,状态栏,一般文本编辑工具都有状态栏显示:)

 

显示文件路径,类型,编码格式,换行格式,文件类型,行,列,当前位置:)够用了。还有些插件可以支持git之类的,我感觉意义不大。代码如下:

“这行很重要,木有这行下面怎么配置都不会显示出来的
set laststatus=2
“正面是状态栏格式代码
set statusline=
set statusline+=%7*\[%n] “buffernr
set statusline+=%1*\ %<%F\ “File+path
set statusline+=%2*\ %y\ “FileType
set statusline+=%3*\ %{”.(&fenc!=”?&fenc:&enc).”} “Encoding
set statusline+=%3*\ %{(&bomb?\”,BOM\”:\”\”)}\ “Encoding2
set statusline+=%4*\ %{&ff}\ “FileFormat (dos/unix..)
set statusline+=%5*\ %{&spelllang}\%{HighlightSearch()}\ “Spellanguage & Highlight on?
set statusline+=%8*\ %=\ row:%l/%L\ (%03p%%)\ “Rownumber/total (%)
set statusline+=%9*\ col:%03c\ “Colnr
set statusline+=%0*\ \ %m%r%w\ %P\ \ “Modified? Readonly? Top/bot.
“前面格式代码中用到的FileFormat函数定义

function! HighlightSearch()
if &hls
return ‘H’
else
return ”
endif
endfunction
“颜色定义

hi User1 guifg=#ffdad8 guibg=#880c0e
hi User2 guifg=#000000 guibg=#F4905C
hi User3 guifg=#292b00 guibg=#f4f597
hi User4 guifg=#112605 guibg=#aefe7B
hi User5 guifg=#051d00 guibg=#7dcc7d
hi User7 guifg=#ffffff guibg=#880c0e gui=bold
hi User8 guifg=#ffffff guibg=#5b7fbb
hi User9 guifg=#ffffff guibg=#810085
hi User0 guifg=#ffffff guibg=#094afe

影响整体效果的配置二就是配色了,随便上Github弄一个放到~/.vim/Color目录下,然后在.vimrc文件中启用这个就行了,我用的是这个(GH上搜索vim color theme 星星最多的):https://github.com/altercation/solarized

 

 

Continue Reading

K3C官改固件WOL on WAN折腾记录

为了整黑裙实现WOL on WAN,过年花了好些时间再外加平时研究折腾终于搞定了。

要想WOW先要实现WOL(Wake on LAN),如果局域网测试通不过,就不要做WOL的任何测试了。
WOL的基本要求:
1. 硬件支持,网卡、电源。有说法说DC电源不支持WOL启动,至少我试过一个DC电源+ITX-M65-N55的主板是支持的;
2. 软件配置好,两部分:BIOS/操作系统,各主板及OS不同各不相同,具体只能去上网查,凭经验了。

先说针对WakeOnWAN的关键配置:

步骤一:端口转发
因为目标是唤醒群晖,所以它本身也需要转发5000/5001/6690这些端口。对于WOW而言,端口转发是必须的,也就是说至少要能转发一个端口,但是除非网络有特定的限制,否则其实并不存在所谓的WOL端口,也就是说WOL是与端口无关的,只要路由器可以转发数据包,理论上哪个端口都可以唤醒。比如:群晖就直接用5000端口是可以唤醒的(其它端口测试也是可以唤醒的)。
端口转发另一个注意事项就是:WOL是UDP数据包,所以必须配置UDP或ALL协议的转发。

在端口转发的处理过程中发现了一个我个人感觉很坑爹的问题:DMZ设置。为了下载时方便暴露端口,我将常用的笔记本设置了静态IP+DMZ主机(不是群晖主机),而群晖只是设置了端口转发(理论上也应该如此更安全)。
因为WOW一直不成功,所以就尝试在路由器上用tcpdump抓包,结果发现:K3C持续向某些主机发送IGMP包(ping)(感觉是在判断主机的在线状态,本质就是ARP表中的NUD状态),在配置了端口转发(比如转向192.168.1.9),但目标主机又不在线时,K3C就将这个数据包直接转发到了DMZ主机(没有测试DMZ关闭的情形,也不确定路由器会主动向哪些服务器发起IGMP包)使得WOW失效。
没去细想这一设计是否合理,但这一结果就是:如果不做静态MAC绑定,待唤醒主机是关机状态,端口转发规则其实是无效的。

步骤二:IP/MAC绑定
这一步是关键。因为如果没有IP/MAC的绑定记录,则路由器在收到转发向内网主机(比如我的群晖内网地址是:192.168.1.9)的时候,因为它已经下线在ARP缓存里没有MAC地址,所以路由器也不知道将数据包发往何方。
局域网在任何情况下都可以唤醒的原因是:发送数据包是广播地址,同一LAN内的所有主机都收到了WOL唤醒包,所以不需要特别的绑定。WOW则不同,路由器在收到来自公网的数据包后,不可能将其“广播”到内网上。事实上,操作WOL时如果不选择IP广播(发往192.168.1.255)而是单播只发往待唤醒主机(192.168.1.9),并且发送WOL唤醒包的本地的ARP记录中又不存在192.168.1.9的记录时,结果尚不知道。

这两个配置如果实现,其实就完全可以WOW方式唤醒主机,但是这个K3C却让我折腾了很久。原因是它没有提供方便的IP/MAC绑定功能。

最开始我不是在K3C下试用的,而是在一个水星路由器下(100以内那种最入门款路由器),在路由器上做端口转发+静态MAC绑定,即可。

但是K3C,没有一个“静态MAC绑定”的功能,只有一个DHCP的MAC地址绑定,我以为是一回事,其实完全不是。在走了很多冤枉路,知道这两者的对系统而言并不相同后,尝试执行绑定:

首先的尝试是执行

arp -s 192.168.1.9 mac:add:ress

这一命令没有任何效果,arp命令在k3c上只是纯粹的show arp list,绑定之类的操作好像没有效果。
但我不能排除在别的架构的路由器(固件)上可能是有用的,所以遇到问题还是可以尝试一下。
后面尝试的是IP命令

ip neigh change 192.168.1.9 lladdr mac:add:ress nud permanent dev br-lan
ip neigh add 192.168.1.9 lladdr mac:add:ress nud permanent dev br-lan

命令中的192.168.1.9是待唤醒主机,mac:add:ress是主机的MAc地址,NUD permanent表示将这条ARP记录的NUD状态设置为永久,dev br-lan表示在哪个网络接口(interface)上执行这个操作。
这两个命令执行后,可以通过ip neigh(此命令显示ip/mac缓存列表)中看到相应的IP的ARP记录显示为permanent(永久)生效。

执行两条命令的原因是:如果192.168.1.9(待唤醒主机)实际在开机状态,那么在ARP缓存记录中会有相应的记录,只是其NUD状态不为permanent,所以先执行ip neigh change操作尝试将状态修改为永久,再尝试添加新的ARP记录,两个命令有一个执行成功即可。
执行完上述命令后,测试WOW成功。

第三个步骤严格来说其实就和WOW无关了:这个命令在重启路由器后就失效了。
首先是尝试在路由器的高级功能的启动脚本(rc.local)中写入如下的命令:

ip neigh change 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan
ip neigh add 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan
exit 0

重启路由器,没任何效果,加上日志,跟踪了执行过程:

echo “START BIND” >> /var/log/ipbind
echo “DO CHANGE” >> /var/log/ipbind
ip neigh change 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan >> /var/log/ipbind >> /var/log/ipbind 2>1&
echo “DO ADD” >> /var/log/ipbind
ip neigh add 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan >> /var/log/ipbind /var/log/ipbind
echo “END BIND” >> /var/log/ipbind
exit 0

上述命令中的应该只有一个地方比较难理解就是末尾的”2>1&”,作用是同时将标准输出(stdout)和标准错误输出(stderr)重定向。直接使用>>只是重定向了stdout,错误信息在日志里就看不到了!
通过日志发现错误提示:device br-lan不存在。但是在路由器已经启动完成的情况下通过ifconfig命令是可以看到br-lan接口的,找了半天,用了另外一方法:
将绑定命令写成脚本,保存在/etc目录下(也可以是其它目录,推荐),比如: /etc/bind_ip.sh。注意要通过chmod a+rx bind_ip.sh来授权执行。
上述命令的脚本要稍做修改如下:

#!/bin/sh
echo “SLEEP”
sleep 60
echo “START BIND”
echo “DO CHANGE”
ip neigh change 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan 2>1&
echo “DO ADD”
ip neigh add 192.168.1.9 lladdr 00:ff:ff:ff:8b:31 nud permanent dev br-lan 2>1&
echo “END BIND”
exit 0

脚本主要修改是:
#!/bin/sh,虽然是注释但有用,这样确保执行脚本时在bash环境中,否则会提示can’t find applet(不能执行第一个sleep命令)。
sleep 60,休眠60眠,脚本的关键修改就是这个延时操作了。
删除了所有的>> /var/log/ipbind,原来这个功能是将脚本执行的输出写入日志的,但因为之后我们要用nohup命令来后台执行程序,nohup这个应用会再次重定向,所以这里就不用写了(如果写了的话在nohup.out中看不到执行日志和错误输出)。但是要注意保留 2>1&,错误输出挺重要的。

然后在rc.local中添加如下命令(强烈建议使用路由器的Web界面添加,不要用vi,试过一次丢失了rc.local文件):

nohup /etc/bind_ip.sh &
exit 0

这里有两个linux常用的命令或语法nohup和&,执行指定的程序,即使你已经注销。其实在这个脚本中可以不使用这个命令前缀,因为是路由器开机过程应该没有不会有注销信号,不过为了保险加上这个命令。
命令末尾的&表示在后台执行这个程序(前台可以继续执行其它命令或脚本),相当于多线程。这个&才是关键,这意味着系统在接下来的时间里仍按原配置加载系统配置(目的就果发创建接口设备br-lan),在这个过程中bind_ip.sh同步执行的是sleep 60命令,只要路由器在60秒内加载完br-lan设备,再执行后面的绑定就成功了。

 

 

 

 

 

 

 

 

 

Continue Reading

强迫症的数据安全

先考虑一下我的数据的性质以及同步频率、数据可靠性的要求。

  1. 一类资料:文档类不可再生数据:如Office文件、工程文档、扫描文件、源代码等;文件数量较少(打包后),总体积较少(总数量<50G),应保持实时更新(在线<30分钟)。
  2. 二类资料:媒体类不可再生数据:如照片、视频、录音等,占用空间大,文件数量多(>100G且持续增长),在3~7内甚至更长时间更新均可。二类资料中有一种特殊的文件(夹)就是备份虚拟机,必须一个文件不少且保证文件正确性,但虚拟机体积大不适合打包,是个问题。
  3. 三类资料:媒体类可再生数据:如高清电影、iTunes音乐数据等(此类文件无需冗余),占用空间大,但单个文件体积大,数量相对较少,无需同步手工下载。

备份方案:

  1. 一类资料:本地PC ,NAS 同步,本地PC直接与Dropbox同步,定期移动硬盘离线同步,3份实时同步,1份离线同步;
  2. 二类资料:本地PC,NAS同步,通过NAS间接同步到百度云,定期移动硬盘离线同步,3分实时同步,1份离线同步;
  3. 三类资料:仅存在于NAS,部分存在于本地PC 或百度云但处于未管理的状态。

本地PC,日常使用,难免有丢失、机器损坏的风险,因此是不太可靠的备份介质,主要用于日常数据使用。
Dropbox数据可靠性相对有保障,但因容量和速度问题只能保障一类资料。也因为如此,一类资料是能够有效保障的。
Baidu云的数据可靠性其实也是有保障的,但基于对国内企业的信任(数据可能不会丢,但随时可能关停服务或要求付费),所以这一备份只能是做个额外保障。
所有数据在关键就在这个NAS上了……

目前NAS是虚拟机+黑群晖的方案。

宿主机Windows 2008做软件RAID,运行VMWare Workstation跑黑群晖,这中间有虚拟机、宿主机、软件RAID等多种机制,不免让人担心数据安全。

一类数据有保障,不用担心;三类数据不担心丢失;关键是二类的,如果因为突发故障(掉电、死机等)而导致虚拟机文件损坏(vmx,vmdk)等不能正常加载,那样会让NAS 中的数据整体丢失,这个结果是不能接受的。

解决思路:

  1. 尝试了一下,将软件RAID的分区直接映射到虚拟机硬盘,但失败了,估计还是软件RAID不能这样用,得上硬件了,服务器是一台笔记本,放弃;
  2. 上白群晖硬件,其实这应该是最省事且靠谱的方案:贵且最近木有预算,就算有也是计划上HP Gen8;
  3. 虚拟机磁盘只做中介,在宿主机上利用磁盘或文件夹同步软件同步虚拟机磁盘与宿主机的RAID分区。这一方案也可以用于Gen8,并且可以规避掉黑群晖升级可能带来的数据丢失风险。

方案3的缺点是:

  1. 出于性能的考虑,文件夹同步最多一天执行1~2次(尚未找到实时监控同步的软件),但因为重点是保障二类数据,因此这类风险是完全可以接受的。
  2. 多占用空间。当然完全可以只针对一类和二类数据做同步,多占用的空间在200~300G左右,对NAS来说,可以忽略。这在某种程度上是另外一重Live备份,也不是坏处。

其实我想说的是,如果我不缺钱,就整一个HP Gen8+Synology DS416play,这样就省事多了。

虚拟机备份的问题需要再研究!

 

 

Continue Reading

黑群晖上线

一直想折腾一个群晖,因为Dropbox容量太小,百度太不靠谱!再次强烈批评百度。
前面折腾了一个win2008的小server放办公室,并做了数据盘的RAID1,借用VMWare Workstation创建黑群晖。前面下载了一套固件,但一直没有成功,今天搜索了另外一个论坛终于找到了解决方案。网上的其它方法说明的流程整体上木有问题,关键是这几个步骤:
1. 下载的引导文件是img格式的,即使提供了vmdk文件在Workstation中导入也不能成功,解决的方法相当简单,下载一个叫StarWindConverter的软件,下载地址是这个:
https://www.starwindsoftware.com/tmplink/starwindconverter.exe
上述下载地址不一定长期有效,可以去这个公司的网站注册,一定要用真实邮箱因为并不直接提供下载地址而是发送到邮箱的。软件不大,大约12M左右,安装好后运行,将img文件转换为相应的vmdk文件格式就行(默认的第一项VMWare growable image),类型我之前选择的是IDE,但因为VMWare创建默认虚拟机时用的是SCSI磁盘类型,推荐也用这个。假定生成的文件是boot.vmdk
2. 创建虚拟机,假定虚拟机名字是NAS,选择其它x64(版本选最新的吧,反正我是这样选的),创建一个虚拟机。
3. 找到这个虚拟机的目录,把默认生成的磁盘文件(正常情况下与虚拟机名称相同,如nas.vmdk),将之前转换的boot.vmdk复制到这里重命名并覆盖nas.vmdk
4. 打开虚拟机设置,添加数据磁盘,越大越好反正并不需要立刻创建;推荐选择分割为多个文件的方式,便于将来备份;一定要创建这个数据磁盘,否则将来安装系统时没有数据盘会失败(用Synology Assistant工具安装时提示网络错误:38,而通过网页安装时会提示没有数据盘);
5. 启动系统,注意启动时会有3个选项(或多个),一定要快速的切换到有VMWare之类的选项(最后一个)。看到:Booting the kernel,大概等1分钟,不会再有任何其它输出,接下来可以按网上的教程用pat文件安装了。

Continue Reading
1 2 3 8