Day 5692 Windows 10 下找不到『Realtek高清晰音频管理器』的笔记

1、系统内置的 Microsoft Store 中直接搜索 Realtek Audio Control 找不到,直链在此,但安装后会出现『无法连接RPC服务』的提示(首先,你得能下得下来)。

2、原因是 Windows 10 下安装 Realtek 声卡驱动时需要使用 UAD(Universal Audio Driver)版本,才能在驱动安装完成后,使系统自动去 Microsoft Store 下载对应的控制面板项。猜测 Microsoft Store 没有显示该项目的原因是避免用户误操作。

3、所以正确的安装方法是:

(1)去自己设备或主板厂商网站下载驱动;

(2)下载 UAD 版本的驱动;

(3)实在不行也可以扒一个传统驱动里的 Rtkcpl64.exe 用。

Day 5537 UNIFOSA GU512303EP0202 GDDR-1333 2GB

该机器为宏碁(Acer)台式机上的定制内存,所谓的 GDDR 是误导写法。

该内存无法配合其它普通内存条使用,单插其它内存也是开机长鸣(找不到内存),在该帖子中有人提到:

I have the same memory installed on a Gateway with ACER MoBo….here’s what I know so far…that memory is FULLY BUFFERED and the MoBo probably won’t recognize unbuffered SDRAM. Mine is also labeled GDDR3-1333 and bears the part number GU512303EP0202. My conclusion after much surfing and reading is that the machine will run best with the buffered memory in it and I’m simply going to have to wait for 4GB buffered modules to become available. Buffered memory is a tad slower due to the buffer read, but is much less error-prone and thus the machine should be more stable. Servers, routers, and MACs all run buffered memory. As for the GDDR3 it should designate graphics memory which should not work as system memory unless some proprietary MoBo innovation has been created. I wonder if the memory was simply mis-labeled GDDR3?

然而普通台式机用 FBDIMM 内存的很少见,对应的内存条在淘宝上本地存档)也只有一条记录,实属怪哉。

做个笔记。

Day 5536 关于 Vitrite 不能用 Ctrl+Shift+0 切换回 100% 透明度的问题

因需要将部分窗口设置为半透明,找到了Vitrite 这款软件。其使用很简单,在其启动后:

1、按 Ctrl+Shift+主键盘区的0至9的任意数字,设置当前活动窗口的透明度为 100% 或 10%~90%;

2、按 Ctrl+Shift和主键盘的加号键(+/=)可以设置/取消设置当前活动窗口总在最前端。

但是,在系统的默认设置下,Ctrl+Shift+1至9都有效,唯独 Ctrl+Shift+0 无效。原因是该组合键被 Windows 默认指定为切换键盘布局的全局快捷键。

如需要,可按如下步骤取消系统对该组合键的占用(以下针对 Windows 7):

1、在语言栏上点击右键,选择『设置』,并切换到『高级键设置』标签;

2、选择『在输入语言之间』,点击『更改按键顺序』;

3、将右侧的『切换键盘布局』修改为『未指定』或除了『Ctrl+Shift』之外的其他选项;

4、一路确定。

Day 5518 关于 UFW 防火墙和 Bitwarden docker 容器在网络连接管理方面冲突的笔记

注:本文不是教程,只是为了在特定环境下实现特定需求的笔记,仅供参考。

最近被人推荐了 Bitwarden 的服务端开源实现 bitwarden-rs,于是在自己的服务器上做实验。

由于 Chrome 的限制,Web Crypto API 在非 HTTPS 连接上无法使用,所以根据官方建议及其它教程配置 HAProxy 以开启 https 服务,但配置好后,发现一个有点吓人的事情:在 ufw 防火墙没有允许访问 80 端口的情况下,容器的 80 端口仍能正常访问。

经过检索,发现是由于 docker 会直接修改 iptables 配置容器的网络连接,而这部分修改并不会体现在 ufw status 中。

修正笔记如下:

1、停止 docker 服务:systemctl stop docker.socket && systemctl stop docker

2、修改 bitwarden 容器的绑定配置:在 /var/lib/docker/containers/bitwarden容器对应的hash/hostconfig.json 中,找到 PortBindings 段,修改HostIp 为 127.0.0.1(以使服务不发布在本机之外)、HostPort 为 80 以外的其它值(不冲突的话,愿意留着80也可以),如8888。修改完成后保存。

3、重启 docker 服务:systemctl start docker.socket && systemctl start docker

4、修改 HAProxy 中对应的转发端口。

5、修改 ufw 配置,使 HAProxy 的对外端口能被外网访问。

参考资料:

1、https://askubuntu.com/questions/652556/uncomplicated-firewall-ufw-is-not-blocking-anything-when-using-docker

2、https://stackoverflow.com/questions/19335444/how-do-i-assign-a-port-mapping-to-an-existing-docker-container

Day 5517 Aria2 将 RPC 服务绑定到其它网卡的折衷方法笔记

注:本文不是教程,只是为了在特定环境下实现特定需求的笔记,如有更好的方法,欢迎提出。

服务器上运行 Debian 10,有两块网卡,姑且称作 eth0 和 eth1,其中 eth0 是外网连接,通过 DHCP 自动获取 IP 地址,可以访问互联网;eth1 是内网连接,为静态 IP 地址,无法访问互联网。

现想达到如下目的:

1、让下载流量自动走 eth0。

2、使 RPC 服务可以通过 eth1 访问。

Aria2 有一配置选项 interface 可以将整个服务绑定在个网络连接(某块网卡或某个IP)上,但并不支持将下载流量和 RPC 服务分别绑定在不同的网络连接上(按:本文撰写时 Aria2 版本为 1.35),按上述环境,如果将 Aria2 服务绑定在 eth0,则 RPC 服务不可访问;如果绑定在 eth1,则无法下载。此外,Aria2 的 rpc-listen-all 参数受 interface 参数的影响,当 interface 绑定为特定网络连接时,rpc-listen-all 会随之绑定在对应网络连接上,而不是所有的网络连接。

由于我不会写 C,无法对 Aria2 本身的代码做出修改,最终在此处找到一个折衷的解决方案(按:本文撰写时该 issue 已提出6年,官方仍未实现,估计是需求太少),配置成功,操作步骤如下:

1、安装 HAProxy(Debian 下为 apt-get install haproxy,其它系统请自行尝试)

2、修改 HAProxy 配置文件,在末尾增加如下内容(默认位置为 /etc/haproxy/haproxy.cfg):

listen web_port

bind 10.0.0.1:6801 #此处地址为 eth1 上的内网地址,6801 为要开放的端口,依据实际情况自行修改

mode http

log global

server aria2 127.0.0.1:6800 check inter 3000 fall 2 rise 5 #此处6800为 Aria2 的 RPC 端口,依据实际情况自行修改

3、重启 HAProxy 服务:systemctl restart haproxy

4、修改 aria2 配置文件,包含如下两处修改:

(1)删除 rpc-listen-all 行(此时 RPC 服务会被绑定到本地回环设备 lo 上)

(2)修改 interface 行为下载流量要绑定的设备或 IP,如:interface=eth0(注意:Windows 下必须使用 IP 地址或主机名

5、重启 Aria2服务:systemctl restart aria2

此时使用 Aria2 的 UI 服务(如 AriaNg 等)去连接内网地址上的 HAProxy 转发端口,即可连上 RPC 服务,同时下载将通过外网连接进行。

Day 5515 修复在 VMWare ESXi 中误将主机阵列卡设置为直通设备后,ESXi 存储变为 NaN,且无法取消阵列卡直通的问题

手里有一台二手的戴尔 R420 服务器,在上面安装了 VMWare ESXi 6.5 作为虚拟化平台。有一次出于好奇,将主机的 PERC 阵列卡设置为了直通设备,结果重启主机之后发现两个问题:

1、ESXi Web 控制台报告存储空间为 NaN,且数据存储列表为空、存储设备中的本地硬盘消失。

2、所有虚拟机变为无效状态。

VMWare 官方给出的方案是在 VMKernel 控制台修改 /etc/vmware/esx.conf,将其中的 passthru 设备修改为 vmkernel,但对于该情况而言,修改保存后重启,阵列卡仍然会报告为直通启用,且再次查看修改后的文件时,会发现刚刚修改的内容又变回原样。

惊恐之下到处搜索,终于找到如下可用的方案,并成功修复问题。

以下内容来自 https://blog.51cto.com/fengwan/2497520,其原文来自 https://communities.vmware.com/t5/ESXi-Discussions/How-to-disable-ESXi-Passthrough-my-findings/m-p/2732447#2592922

1、使用 Ubuntu Desktop Live CD 引导系统(不要用服务器版),并在安装界面选择 Try Ubuntu(试用 Ubuntu)

2、打开终端,输入以下指令切换到 root 账户:sudo su –

3、执行如下指令查看当前硬盘分区:parted -l

4、挂载 VMKernel 所在分区,原文直接提到为编号 5 的分区,我的情况也一样,但中文版教程提到他的分区是编号 6,请按自身情况选择(能找到接下来的文件就算正确):mount /dev/sda5 /mnt

5、依次执行如下指令解压缩打包的配置文件:

tar xvf state.tgz (此时本目录(~)下会解压出一个 local.tgz来)

tar xvf local.tgz(此时本目录下会解压出一个 etc 目录来)

6、使用 vi 或 nano 修改 etc/vmware/esx.conf,将其中对应阵列卡的 device 行有 passthru 字样之处修改为 vmkernel(也可以将所有 passthru 都修改为 vmkernel,缺点是如果有其他直通设备,需要重启后重新配置),保存退出。

7、此时应仍在 ~ 目录下,依次执行如下指令重新打包配置文件:

tar czf local.tgz etc/ (此时会将 etc 目录打包为 local.tgz)

tar cvf state.tgz local.tgz(此时会将 local.tgz 打包为 state.tgz)

8、执行如下指令替换 VMKernel 分区下的文件:cp -rf state.tgz /mnt/

9、重启主机即可。

TONT 31753 为什么有两份『记事本』的程序文件?

原文链接:https://devblogs.microsoft.com/oldnewthing/20060328-17/?p=31753

You may have noticed that there’s a copy of Notepad in %windir%\notepad.exe and another in %windir%\system32\notepad.exe.Why two?

可能你会注意到在 %windir%\notepad.exe 和 %windir%\system32\notepad.exe 分别各有一份记事本的程序文件,为什么会这样呢?

Compatibility, of course.

当然是为了兼容性了。

Windows 3.0 put Notepad in the Windows directory. Windows NT put it in the System32 directory. Notepad is perhaps the most commonly hardcoded program in Windows. many Setup programs use it to view the Readme file, and you can use your imagination to come up with other places where a program or batch file or printed instructions will hard-code the path to Notepad. In order to be compatible with programs designed for Windows 95, there needs to be a copy of Notepad in the Windows directory. And in order to be compatible with programs designed for Windows NT, there also needs to be a copy in the System32 directory.

Windows 3.0 在 Windows 目录下放置记事本,Windows NT 则放在 System32 目录下面。记事本大概是被硬编码到程序里最多的 Windows 组件之一了,很多安装程序都调用它来展示 Readme 文件,可想而知还有多少程序、批处理文件或印刷出来的操作说明里有硬编码的记事本的路径。为了保持与为 Windows 95 设计的应用程序的兼容性,在 Windows 目录下需要有一份记事本程序的副本,同样,为了保持与为 Windows NT 设计的程序的兼容性,System32 目录下也有一份。

And now that Notepad exists in both places, new programs have a choice of Notepads, and since there is no clear winner, half of them will choose the one in the Windows directory and half will choose the one in the System32 directory, thereby ensuring the continued existence of two copies of Notepad for years to come.

如今记事本在两个位置都有一席之地,新编写的程序就可以自由选择了。鉴于没有哪一份是明显的赢家,选择 Windows 目录下那份和选择 System32 目录下的那份的程序大概是一半一半的几率,由此保持两份副本共存的做法还要一直持续下去。

TONT 32453 为什么在NTFS分区和FAT分区上,回收站文件夹的名字不一样?

原文链接:https://devblogs.microsoft.com/oldnewthing/20060131-00/?p=32453

译注:原文第一段比较长,为方便阅读,进行了手工拆分,今后再有的类似情况将不再另作备注。

On FAT drives, the directory that stores files in the Recycle Bin is called C:\RECYCLED, but on NTFS drives, its name is C:\RECYCLER. Why the name change?

在 FAT 格式的分区上,存储回收站文件的目录叫做 C:\RECYCLED,但在 NTFS 格式的分区上则叫 C:\RECYCLER。为什么会有这种变化呢?

The FAT and NTFS Recycle Bins have different internal structure because NTFS has this thing called “security” and FAT doesn’t. All recycled files on FAT drives are dumped into a single C:\RECYCLED directory, whereas recycled files on NTFS drives are separated based on the user’s SID into directories named C:\RECYCLER\S-…. (It has nothing to do with whether you are running English or Swedish Windows.)

FAT 分区和 NTFS 分区上的回收站的内部结构有所不同,因为 NTFS 文件系统有一种 FAT 文件系统所没有的功能,叫做『安全属性』。在 FAT 格式的分区上,所有删除的文件都被直接丢进了 C:\RECYCLED 目录里,而在 NTFS 分区上,回收站则按照用户的 SID 将删除的文件以 C:\RECYCLER\S-…. 的形式区别开来(这与你用的是英文版还是瑞典语版的 Windows 没有关系)。

Suppose the same directory name were used for both file systems, say, C:\RECYCLED. Since it is possible to upgrade a FAT drive to an NTFS drive with the CONVERT utility, this means that a FAT drive converted to NTFS would have a FAT-style Recycle Bin after the conversion. But since the names are the same, the Recycle Bin says, “Hey, look, here’s a C:\RECYCLED directory. That must be my NTFS Recycle Bin!” except that it isn’t. It’s a FAT Recycle Bin left over from the conversion. Giving the NTFS Recycle Bin a different name means that the Recycle Bin shell folder won’t get confused by the “wrong” type of recycle bin directory structure on an NTFS volume.

假设在两种格式的磁盘上,回收站文件夹的名字是相同的,都是 C:\RECYCLED。鉴于系统允许使用 CONVERT 工具将 FAT 格式的分区升级成为 NTFS 分区,这就意味着从 FAT 格式转换为 NTFS 格式的分区,在转换完成后就会有一个 FAT 格式的回收站(译注:上文所说的直接将文件丢进去,不按 SID 区隔的那种)。但由于(回收站的)名字是相同的,那么回收站功能便会认为,『嘿,看,这儿有个 C:\RECYCLED 目录,这肯定是我们 NTFS 格式的回收站没错!』,而事实上并非如此,它只是一个转换后遗留下来的 FAT 格式回收站而已。给 NTFS 格式回收站(目录)一个不同的名字,有助于令回收站功能不会在 NTFS 格式的卷上对『错误的』回收站目录结构产生疑惑。

Yes, the problem could have been solved some other way. For example, there could have been code to inspect the Recycle Bin directory to determine what format it is and ignore it if it didn’t match the actual file system. (Or, if you’re feeling really ambitious, somehow convert from one format to the other.) But that would be over-engineering. You have to write and test the detection (and possibly conversion) code, there’s the risk of a false-positive, the code runs at every boot, and it needs to be maintained whenever either the FAT or NTFS recycle bin format changes. All for a scenario that happens at most once per drive.

的确,这个问题也能通过其他方式解决。例如,回收站功能可以新增一段代码,来判断目录内的格式,并忽略与当前文件系统不相符的情况。(又或者真的很有雄心壮志的话,把不相符的格式转换为相符的也可以。)但是那样就成了过度开发的案例了。你得撰写相关的代码,对检测功能进行测试(可能还包括转换格式的功能),这其中存在判断错误的可能,这段代码会在每次系统启动时运行,并且每次 FAT 或 NTFS 文件系统的回收站格式发生变化时都要维护,而以上所有的麻烦,都只为了一个在每个磁盘上最多只会发生一次的事情。

Or you could change one text string and be done with it. (I could make some really awful “Gordian knot”/”string” remark here but will refrain.)

也可以选择就修改一个字符串(译注:RECYCLER 和 RECYELED 的区别)就搞定了。

TONT 32483 为什么有时损坏的二进制文件会令系统提示『程序太大,不能装入内存』?

原文链接:https://devblogs.microsoft.com/oldnewthing/20060130-00/?p=32483

译注:原文第一段比较长,为方便阅读,进行了手工拆分。

If you take a program and corrupt the header, or just take a large-ish file that isn’t a program at all and give it a “.exe” extension, then try to run it (Warning: Save your work first!), you will typically get the error “Program too big to fit in memory”. Why such a confusing error message? Why doesn’t it say “Corrupted program”?

随便找一个程序来,然后把它的文件头搞乱,或者干脆随便拿一个挺大的、不是应用程序的文件,并给它一个.exe的扩展名,然后尝试运行之(警告:先保存好你正在进行的工作!),通常你会得到一条错误信息:『程序太大,不能装入内存』。为什么是这么令人费解的一条错误信息呢?为什么不说是『程序已损坏』呢?

Because the program isn’t actually corrupted. Sort of.

因为从某种意义上讲,这个程序实际上并没有损坏。

A Win32 executable file begins with a so-called “MZ” header, followed by a so-called “PE” header. If the “PE” header cannot be found, then the loader attempts to load the program as a Win16 executable file, which consists of an “MZ” header followed by an “NE” header. If neither a “PE” nor an “NE” header can be found after the “MZ” header, then the loader attempts to load the program as an MS-DOS relocatable executable. If not even an “MZ” header can be found, then the loader attempt to load the program as an MS-DOS non-relocatable executable (aka “COM format” since this is the format of CP/M .COM files). In pictures:

一个 Win32 可执行文件的开头包含所谓的『MZ』文件头,紧跟着是所谓的『PE』头。如果找不到PE头,那么加载器就会尝试将程序按照 Win16 可执行文件进行读取,而 Win16 的文件头便是MZ后面跟一个NE。如果在MZ头之后既没有找到PE头,也没有找到NE头,那么加载器会尝试将程序按照MS-DOS可重定位可执行文件进行加载。如果连MZ头都没找到,那么加载器就会将其按照MS-DOS不可重定位可执行文件(也叫做COM格式,因为这是CP/M的.COM文件的格式)进行加载。总的来说就是:

MZ PE Win32
NE Win16
其它情况 MS-DOS 可重定位可执行文件
其它情况 MS-DOS 不可重定位可执行文件

Observe that no matter what path you take through the chart, you will always end up at something. There is no exit path that says “Corrupted program”. But where does “Program too big to fit in memory” come from?

很明显,根据上面表格中列出的情况,不管走哪条路最后都会到达某个终点,并且并没有哪个终点是显示『程序已损坏』这条消息的选项。话说回来,『程序太大,无法载入内存』又是怎么回事呢?

If the program header is corrupted, then various fields in the header such as those which specify the amount of memory required by the program will typically be nonsensical values. The loader sees an MS-DOS relocatable program that requires 800KB of conventional memory, and that’s where “Out of memory” comes from. An MS-DOS non-relocatable program contains no such information about memory requirements. The rule for loading non-relocatable programs is simply to load the program into a single 64KB chunk of memory and set it on its way. Therefore, a program with no “MZ” header but which is larger than 64KB in size won’t fit in the single 64KB chunk and consequently results in an “Out of memory” error.

如果某个程序的文件头损坏了,那么在文件头中的一些字段——例如指定程序所需内存数量的值通常会是一些毫无意义的数值。加载器会将其视为一个请求800KB常规内存的 MS-DOS 可重定位应用程序(译注:常规内存上限为640KB),而这就是『内存不足』消息的来源。MS-DOS 不可重定位应用程序是不包含类似所需内存数量之类的信息的,加载这类程序的路子,就是将其装入单独一段64KB内存并运行它。因此,一个没有MZ头、但是尺寸又比64KB大的程序自然无法装入64KB的内存段,由此引发了『内存不足』的错误。

And since people are certain to ask:

顺便一提吧,反正肯定会有人问:

“MZ” = the legendary Mark Zbikowski.

MZ:传奇人物 Mark Zbikowski 的缩写(译注:微软公司的元老级开发者)

“NE” = “New Executable”, back when Windows was “new”.

NE:新式可执行程序(New Executable)的缩写,那时候 Windows 还蛮『新』的。

“PE” = “Portable Executable”, because one of Windows NT’s claims to fame was its portability to architectures other than the x86.

PE:便携式可执行程序(Portable Executable)的缩写,因为 Windows NT 出名的原因之一就是其可以在 x86 平台之外的可移植性。

“LE” = “Linear Executable”, used by OS/2 and by Windows 95 device drivers.

LE:线性可执行程序(Linear Executable),由 OS/2 和 Windows 95 的驱动程序所使用。