0%

由于磁盘阵列Unreadable Sectors错误,强制修复后导致cassandra的一个sstable损坏,cassandra启动时报错:

1
2
3
4
5
6
7
8
ERROR \[CompactionExecutor:2\] 2019-07-15 15:03:27,161 DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system exception on startup, disk failure policy "stop"
org.apache.cassandra.io.FSReadError: org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: /mnt/data/cassandra/reis/image-6a85c44086a711e5aef4b53617129a2a/lb-47344-big-Data.db
at org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:365) ~\[apache-cassandra-2.2.14.jar:2.2.14\]
at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:361) ~\[apache-cassandra-2.2.14.jar:2.2.14\]
at org.apache.cassandra.utils.ByteBufferUtil.readWithLength(ByteBufferUtil.java:324) ~\[apache-cassandra-2.2.14.jar:2.2.14\]
at org.apache.cassandra.db.ColumnSerializer.deserializeColumnBody(ColumnSerializer.java:132) ~\[apache-cassandra-2.2.14.jar:2.2.14\]
at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:92) ~\[apache-cassandra-2.2.14.jar:2.2.14\]
at org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:52) ~\[apache-cassandra-2.2.14.jar:2.2.14\]

lb-47344-big-Data.db这个sstable被破坏了。
因为节点已经无法启动了,所以下面的尝试无可避免的失败了

1
2
$ nodetool scrub
nodetool: Failed to connect to '127.0.0.1:7199' - ConnectException: 'Connection refused (Connection refused)'.

尝试离线修复,如果数据量很大,记得开启screen会话

1
$ sudo -u cassandra sstablescrub reis image

注意cassandra数据目录的权限,这里使用cassandra用户来执行scrub
执行结束后,删除掉已经损坏的sstable,scrub时cassandra会将损坏的sstable保持原样

1
$ sudo mv lb-47344* backups/

启动cassandra

1
$ sudo systemctl start cassandra

确认系统运行正常

1
$ nodetool status 

之后可以删除sstablescrub自动创建的快照,释放掉已经无用的sstables

1
2
$ nodetool clearsnapshot
Requested clearing snapshot(s) for \[all keyspaces\]

最后需要repair本节点,修复节点数据

1
$ nodetool repair -local -- reis image

References:
[1]sstablescrub
[2]Dealing with a corrupt SSTable in Cassandra
[3]So You Have A Broken Cassandra SSTable File?

一台IBM DS5020(1814-20 FAStT) RAID5存储阵列,OS报错误:

1
2
3
4
5
6
\[ 274.331664\] sd 4:0:0:0: \[sdc\] tag#5206 Add. Sense: Unrecovered read error
\[ 274.331673\] print_req_error: critical medium error, dev sdc, sector 177668608
\[ 274.331752\] print_req_error: critical medium error, dev dm-0, sector 177668608
\[ 274.371749\] sd 4:0:0:0: \[sdc\] tag#5206 Add. Sense: Unrecovered read error
\[ 274.371757\] print_req_error: critical medium error, dev sdc, sector 177668632
\[ 274.371848\] print_req_error: critical medium error, dev dm-0, sector 177668632

连上存储,有报警信息:

1
2
3
Failure Entry 1: USM_UNREADABLE_SECTORS_EXIST-Recovery Failure Type Code: 75
Storage array: Unnamed
Unreadable sectors detected: 2

有两个不可读取的扇区,可以进一步看到这两个扇区位于哪个磁盘驱动器,这种故障一般就是硬盘不稳定了,该换就换吧。

存储管理EMW(Enterprise Manage Window)窗口找到存储阵列,右击弹出context菜单中选择“Exectute script…”

脚本窗口中执行:

1
show storageArray unreadableSectors;

结果窗口输出:

1
2
3
4
5
6
Executing script...
Volume LUN Accessible By Date/Time Volume LBA Drive Location Drive LBA Failure Type
1 0 Host Group ibm 7/11/19 3:07:58 AM 0xa97021e Tray 85, Slot 2 0x12d391e Logical
1 0 Host Group ibm 7/11/19 3:07:58 AM 0xa97061e Tray 85, Slot 6 0x12d391e Physical

Script execution complete.

可以看到这两个扇区的详细状况,然后继续执行命令清除这两个扇区

1
clear allVolumes unreadableSectors;

最后重新查看

1
2
3
4
show storageArray unreadableSectors;
Executing script...
There are currently no unreadable sectors on the storage array.
Script execution complete.

可以看到已经没有不可读取的扇区了,阵列的报警灯也恢复正常。
注意,那两个扇区的数据应该是丢失了,应用程序如果需要这些数据应该通过其他途径恢复数据。

wine是个伟大的工程。

wine有三个分支wine-stable,wine-devel和wine-staging,就好像debian的三个分支stable,testing和sid,devel分支其实很稳定的,也能支持更多的应用程序

但是debian buster上安装wine-devel出现依赖问题:

1
2
3
wine-devel : Depends: wine-devel-amd64 (= 4.12.1~buster) but it is not going to be installed
Depends: wine-devel-i386 (= 4.12.1~buster)
wine-devel-amd64 : Depends: libfaudio0 but it is not installable

从wine4.5开始,wine-devel依赖libfaudio0,但是debian官方源并没有提供这个包,因此可以从参考[2]给出的链接下载amd64和i386两个架构的安装包libfaudio0_19.07-0_buster_amd64.deb和libfaudio0_19.07-0_buster_i386.deb
并手工安装

1
2
$ sudo dpkg -i libfaudio0_19.07-0_buster_amd64.deb
$ sudo dpkg -i libfaudio0_19.07-0_buster_i386.deb

然后再安装wine-devel

1
$ sudo apt -y install wine-devel

注意wine-devel安装到/opt/wine-devel目录,因此要使用wine-devel需要在.bashrc中添加

1
export PATH=/opt/wine-devel/bin:$PATH

References:
[1]Installing WineHQ packages
[2]FAudio for Debian and Ubuntu

debian buster gnome桌面默认启用wayland,当前仍然可以切换回Xorg
wayland兼容性还是有一些小问题,wayland并不加载profile环境配置文件,
也不理会Xsession,导致.xinitrc,.Xresources等无法加载
系统及用户的Xresources是由/etc/X11/Xsession.d/30x11-common_xresources脚本加载的,在wayland面前失效了,直接后果就是每次重启机器xterm就会被打回原形,只能手工重新加载~/.Xresources
回到gnome on xorg则xterm恢复正常
发现一个跨平台GPU加速的terminale emulator alacritty看起来很不错,可以试用一番。

References:
[1]GNOME, Wayland, and environment variables

macosx上自带的很多命令行工具都是bsd版本的,包括sed

sed的参数-i与gnu版本稍有不同,其-i参数后面的备份文件扩展名不可省略,即使是空字符串,也就是不要备份,而gnu版本不要备份的话是可以忽略掉的。
bsd版本:

1
$ sed -i '' 's/123/456/' test

gnu版本:

1
$ sed -i 's/123/456/' test

如果/etc/mysql/my.cnf中打开了log-bin选项,即使没有做主从复制,数据目录下仍然会持续的生成大量的mysql-bin.0000*文件,这玩意儿就像归档日志吧。

如果你做了主从复制,下面就不要看了。
没做主从复制的话,可以先清除掉这些文件

1
mysql> reset master;

这样会删除掉所有的log-bin,重新生成一个mysql-bin.000001
然后修改/etc/mysql/my.cnf,注释掉下面的行

1
#log-bin=mysql-bin

重新启动mariadb服务,以后就不会再生成这些文件了。

scp是不支持断点续传的,传输大文件意外中断会很痛苦。
rsync支持断点续传,也支持使用ssh协议传输数据,所以可以这样

1
$ rsync -P --rsh=ssh nasmdoc.pdf linode:

这里linode是为一个ssh服务器配置的别名,而且支持tab补全,很好用。

可以在.bashrc中设置一个alias

1
alias scpr="rsync -P --rsh=ssh"

就可以这样用了

1
$ scpr nasmdoc.pdf linode:

注意,客户端和服务器都要安装rsync。

transfer.sh可以使用命令行快速的分享文件,最大可以上传10G,有效期最长14天,也可以设定下载次数和有效期。

上传文件

1
2
$ curl --upload-file ./go.sh https://transfer.sh/go.sh
https://transfer.sh/Pyg2a/go.sh #生成的下载链接

设定下载次数和最大天数

1
2
$ curl -H "Max-Downloads: 1" -H "Max-Days: 5" --upload-file ./hello.txt https://transfer.sh/hello.txt 
https://transfer.sh/66nb8/hello.txt

添加.bashrc命令行别名

1
2
3
4
5
6
transfer() {
curl --progress-bar --upload-file "$1" https://transfer.sh/$(basename "$1") tee /dev/null;
echo
}

alias transfer=transfer

然后可以这样

1
$ transfer hello.txt

是不是很简单,很好用,但是,不要用来传输敏感文件,传输敏感文件请使用onionshare或加密后再传输。
还有一点儿要注意,github上的tansfer.sh项目与http://transfer.sh网站并无关系。

References:
[1]Easy and fast file sharing from the command-line

OnionShare是一个安全匿名的开源文件分享工具,可以使用它在本地机器通过tor网络发布共享服务,生成一个不可猜测的onion地址,通过这个地址其他人可以使用tor browser来获取分享的文件。只要生成的onion地址没有泄露,文件就是安全的。文件传输的过程不会被任何第三方窃取。

安装

1
$ sudo apt install onionshare

分享文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ onionshare go.sh 
Onionshare 1.3.2 https://onionshare.org/
Connecting to the Tor network: 100% - Done
Configuring onion service on port 17620.
Starting ephemeral Tor onion service and awaiting publication
Settings saved to /home/xxx/.config/onionshare/onionshare.json
Preparing files to share.
* Serving Flask app "onionshare.web" (lazy loading)
* Environment: production
WARNING: Do not use the development server in a production environment.
Use a production WSGI server instead.
* Debug mode: off
* Running on http://127.0.0.1:17620/ (Press CTRL+C to quit)
Give this address to the person you're sending the file to:
http://huq64ocyu666ecom.onion/negligee-easing

Press Ctrl-C to stop server

获取文件

将生成的连接通过安全路径发送,然后在tor browser中打开连接即可,简单可靠又安全,美中不足,速度慢慢慢。

TLS-SNI-01已经deprecated,但certbot尚不支持tls-alpn-01验证方法,因此可以使用dehydrated或者acme.sh通过https来获取Let’s Encrypt证书。

使用TLS_ALPN获取证书,需要使用443端口进行验证,借助nginx的ngx_stream_ssl_preread_module模块,可以路由来自443的请求到不同的处理后端。

确保nginx支持ssl_preread特性

1
2
$ nginx -V 2>&1 grep -o ssl_preread
ssl_preread

配置nginx
/etc/nginx/nginx.conf文件最后添加

1
2
3
4
5
6
7
8
9
10
11
12
stream {
map $ssl_preread_alpn_protocols $tls_port {
~\\bacme-tls/1\\b 10443;
default 8443;
}
server {
listen 443;
listen \[::\]:443;
proxy_pass 127.0.0.1:$tls_port;
ssl_preread on;
}
}

这样来自签发证书时的验证请求会被路由到10443端口,而其他对443端口的访问会被路由到8443端口,所以虚拟主机应该在8443端口上监听ssl连接。

reload nginx使新配置生效

1
$ sudo systemctl reload nginx

申请证书

1
2
3
4
5
6
7
8
9
# acme.sh --issue --alpn --tlsport 10443 -d openwares.net
```

**安装证书**
```js
# acme.sh --installcert -d openwares.net \\
--key-file /etc/nginx/ssl/openwares.net.key \\
--fullchain-file /etc/nginx/ssl/fullchain.cer \\
--reloadcmd "systemctl force-reload nginx"

更新证书

1
# acme.sh --renew -d openwares.net --force

注意(updated 02/29/2020):
如果启用了proxy_protocol以获取客户端的真实地址,申请或者更新证书时会出现错误:

1
Verify error:Error getting validation data

因此申请或更新证书时需要临时禁止proxy_protocol协议。

References:
[1]Deploying Let’s Encrypt certificates using tls-alpn-01 (https)
[2]使用TLS-ALPN-01验证签发证书
[3]TLS ALPN without downtime
[4]ssl_preread_protocol, multiplex HTTPS and SSH on the same port