使用源代码将 Glibc 升级到 2.6

简介

有些软件可能要求系统的 Glibc 高于某个版本才可以正常运行。如果您的 Glibc 低于要求的版本,为了运行这些软件,您就不得不升级您的 Glibc 了 。您可以寻找已经编译好的 rpm 包或者使用源代码的方式升级 Glibc。

使用源代码方式升级 Glibc 是需要小心考虑的事情,因为整个系统几乎所有应用程序都依赖于原有的动态库,升级的时候,执行"make install"命令会打断旧的动态库链接,改为指向新的库文件。在这个过程中,不同的链接指向新旧不同版本的库文件,很容易导致系统崩溃,崩溃后,一般是无法重新启动的。

笔者使用的Linux发行版本是Mandriva Linux release 2006.0,其Glibc版本是2.3.5,内核版本是2.6.12-12mdk。由于某些需要,笔者必须升级原来的Glibc到更高的版本。经过实 践,成功使用源代码的方式安全地把Glibc从2.3.5升级到2.6。使用相同的方法,也能成功升级到Glibc2.4或Glibc2.5。成功升级 后,还可以在新旧不同版本的Glibc之间自由切换。

如果您需要阅读有关升级Glibc的文档,可以阅读Glibc 2 HOWTO文档,该文论述了如何从libc5升级到libc6,但是现在的Linux发行版的Glibc都已经使用libc6,更多的需要是在libc6 的范围内,从低版本升级到更高的版本。另外您可以阅读Linux From Scratch项目有关如何安装Glibc的文档。笔者认为最有必要阅读的是Glibc源程序目录树下的INSTALL和FAQ文档,INSTALL详细 描述了有关各编译选项的具体作用,FAQ回答了很多具体的问题。

升级Glibc的流程

为了安全升级Glibc,在升级前必须做好详细的部署和备份,即使是升级失败,系统也要能够还原为原来的状态。升级Glibc失败后,一般是无法重新启动系统的,必须使用另外一个可以启动计算机的Linux系统启动,挂载升级失败的根文件系统,恢复系统的Glibc为原来的状态。因此,准备另外一个可以启动 的Linux系统,是必需的。

准备好另外一个可以启动的Linux系统后,接下来的工作是编译Glibc。编译前要执行"configure"命令,用户可以根据自己的需要,加入不同的编译选项,编译选项在INSTLL文件里有详细的说明。如果是升级当前的Glibc, 必须使用--prefix=/usr选项,该选项指定当前即将编译的Glibc作为系统的标准动态库,安装的时候,Glibc会修改/lib,/usr等 目录下的文件和链接。如果--prefix不是指向/usr,譬如--prefix=/glibc, 安装的时候,Glibc只会在/glibc目录下生成目录,文件以及链接,安装后的Glibc不会成为系统的标准动态库。如果不指定 --prefix,Glibc缺省认为--prefix=/usr/local,安装后的Glibc也不会成为系统的标准动态库。编译Glibc的时候需 要使用Linux内核的头文件,如果内核的头文件太旧,执行"make"的时候,可能会失败,这时可以在configure的时候,使用--with- headers选项指定新内核的头文件的所在目录。笔者的Mandriva Linux release 2006.0的内核头文件就不能令Glibc2.6成功编译,但是却能令Glibc2.4和Glibc2.5成功编译,使用--with-headers 指向新内核的头文件后,Glibc2.6也能成功编译,下文将会有详细叙述。

Glibc安装的时候,会直接修改/lib,/usr/lib等目录下的文件和链接,为了在升级失败的情况下能够恢复系统的Glibc为原来状态,在安装新版本的Glibc之前必须对一些重要目录进行备份,至于哪些目录需要做备份,下文将会有叙述。

备份好重要目录后就可以安装Glibc了,必须由root用户执行make install命令,不同的Linux发行版,可能会有不同的结果。笔者使用的Mandriva Linux release 2006.0在这个过程中会出现错误,并且输入任何命令都无效,重新启动也无法再次进入Linux系统。出现的这样的错误是由于Coreutils的命令 都是依赖于/usr/tls/目录下的链接文件,这些链接文件都指向原来的Glibc动态库文件,而/lib/ld-linux.so.2已经被改为指向 新版本的Glibc动态库文件了,这些重要链接分别指向新旧不同版本的库文件,导致了执行Coreutils的命令无效。这个时候,就要用另外一个 Linux系统启动,把/usr/tls/目录下的链接修改为指向新版本的Glibc的库文件。

经过上述修改,重新启动计算机,如果能重新 进入原Linux系统,表明到目前为止升级过程都是正确的。这个时候,要再执行一次"make install"重新安装Glibc,正常情况下,这次不会出现任何错误,安装结束的时候,Glibc会给出安装成功的消息。如果修改/lib/tls /下的链接后重新启动计算机仍然不能进入原Linux系统,表明这次升级失败,只能再次使用另外一个Linux系统启动,挂载升级失败的根文件系统,把先前备份好的重要目录恢复为原来的名字,经过这样的恢复,一般是可以重新启动升级失败的Linux系统的。

升级的最后一步是执行"make localedata/install-locales"命令安装时区和地区数据库。

图一:升级Glibc的流程图

image002

注意

本文介绍的方法在升级过程中会出现一次链接错误,系统无法输入命令,重新启动也无法进入Linux,必须使用另外一个Linux系统启动,并挂载原根文件系 统,修正在升级过程中产生的错误链接,然后才能继续升级。因此在升级之前,一定要先确保拥有另外一个可启动的Linux系统。此外,还要备份下文将会论述 的一些重要目录,如果最终升级失败,需要用另外一个Linux系统启动,恢复原Linux系统的Glibc为原来的版本。

建议在升级之前,详细阅读Glibc源代码包内的INSTALL和FAQ文件。

升级过程

本文假设进行编译的用户名字是xyz,用户目录是/home/xyz/,所有源代码都在/home/xyz/build/目录下编译。所有源代码压缩包都已 经拷贝到/home/xyz/build/目录下。升级Glibc的Linux系统的根文件系统使用hda5分区,其文件系统格式为xfs。

1 准备另外一个可启动的Linux系统

准备另外一个可启动的Linux系统的方法有很多,可以在硬盘上安装另外一个Linux发行版,可以在DOS环境下使用loadlin.exe启动一个 Linux系统,最简单的方式是使用Live CD,从光驱启动。无论使用什么形式,它都必须能挂载需要升级Glibc的根文件系统。

如果选择Live CD启动,Knoppix是一个很好的选择。您可以从Knoppix的网站下载iso文件,烧制成启动CD,也可以把Knoppix的系统文件拷贝到硬盘 上,在DOS环境下,执行loadlin.exe启动。笔者使用了Knoppix 5.0.1,制作成Live CD启动。参考资料有介绍如何使用 Knoppix 进行系统恢复。

2 编译

Glibc的编译安装与一般的软件很类似,都是要经过configure,make和make install三个阶段。Glibc不能在源代码目录下编译,必须在一个空目录下编译。

编译Glibc是需要内核头文件的,笔者的Mandriva Linux release 2006.0的内核版本是2.6.12-12mdk,可以直接使用该版本内核的头文件升级到Glibc2.4 和Glibc2.5。如果升级到Glibc2.6,在make过程中,会出现以下错误:

这是由于2.6.12-12mdk的内核头文件太旧,为了顺利编译Glibc2.6,必须使用新的内核头文件。

2.1 编译Glibc2.4或Glibc2.5

如果要升级Glibc到2.4或2.5,configure的时候只需要--prefix=/usr一个选项,意思是该Glibc将会作为系统的标准动态库。

以升级到Glibc2.5为例,执行以下命令进行编译:

glibc-2.5.tar.bz2是Glibc2.5的源代码压缩包,执行"tar xjf glibc-2.5.tar.bz2"命令后,在~/build/目录下产生了glibc-2.5目录树,Glibc2.5的源代码就在这个目录里面。 Glibc不能在源代码目录下编译,因此执行了"mkdir glibc-2.5-build"命令,生成glibc-2.5-build目录,编译Glibc2.5时产生的文件,保存在这个目录下。如果顺利,将会成功编译,不会出现错误信息。

2.2 编译Glibc2.6

如果您打算升级到 Glibc2.6,使用版本为2.6.12-12mdk的内核头文件是不能成功编译的,必须使用新的内核头文件。configure的时候使用 --with-headers选项指向新的内核头文件的目录。Glibc的FAQ文档明确指出最好使用最新版本的内核头文件,而且编译时需要的内核头文件 的版本不需要与当前正在运行的内核版本一致。笔者试验了版本为linux-2.6.20.7和linux-2.6.18两个版本的内核头文件,编译时系统 运行的内核版本是2.6.12-12mdk,都可以成功编译Glibc2.6。

为了使用新版本的内核头文件,解开新版本的内核压缩包后,在源代码目录下执行"make menuconfig",这将会进入内核的设置页面,不需要作任何处理,直接退出并保存。然后执行"make",不需要等待make完毕,一开始看到

就可以按下ctrl+c停止编译内核。执行"make"的目的是在内核源代码目录树内生成一些重要的文件和软链接,其中在include/目录下产生一个名为asm的软链接指向asm-i386目录,没有这个链接,Glibc2.6是无法编译的。

假设使用linux-2.6.20.7的内核头文件,执行以下命令:

linux-2.6.20.7.tar.bz2是2.6.20.7版本的Linux内核源代码压缩包,执 行"tar xjf linux-2.6.20.7.tar.bz2"命令后,将会产生linux-2.6.20.7目录,Linux内核的源代码都在这个目录下,其中内核头 文件在linux-2.6.20.7/include/下。确保linux-2.6.20.7/include/asm已经产生后,就可以停止内核的编 译,然后进行Glibc2.6的编译:

glibc-2.6.tar.bz2是Glibc2.6的源代码压缩包,执行"tar xjf glibc-2.6.tar.bz2"命令后,在~/build/目录下产生了glibc-2.6目录树。

如果您的系统当前运行的内核已经升级到比较新的版本,例如2.6.20.7,configure的时候,就不需要--with-headers选项了,与 Glibc2.4或Glibc2.5的configure命令一样,只需要--prefix=/usr选项就可以了,但是前提条件是/lib /modules/uname -r/source指向内核的源程序目录,您可以用以下命令查看它指向哪里:

3.make install前的准备工作

3.1 哪些目录需要备份?

安装Glibc前必须备份好原来的系统动态库,一旦安装失败,使用另外一个Linux系统启动,挂载升级失败的根文件系统,还原Glibc为原来的状态。可是哪些目录需要备份?Glibc在安装的时候,将会修改哪个目录下的文件?

Glibc 在安装时可以指定install_root选项,命令Glibc把该选项指向的目录作为根,文件都安装到这个目录下,通过观察Glibc在这个目录里生成了什么目录和文件,我们就可以知道Glibc在安装的时候到底会修改哪些目录了。假设安装到~/build/system_fake_root上:

安装后:

可以看出,Glibc的make install命令会修改/etc,/lib,/sbin和/usr目录下的文件。这里最重要的是/lib和/usr。一般来说/usr目录下有很多文件,占用硬盘空间很大,实际也不需要对整个/usr目录备份,使用以下命令查看Glibc会修改/usr/下的哪些目录:

经分析,笔者选择了备份/lib,/usr/lib,/usr/include,/usr/sbin和/usr/bin。您当然可以备份更多的目录,不过笔者发现备份上述5个目录已经可以恢复系统的Glibc为原来的版本了。

3.2 备份目录

使用su命令切换为root。执行:

经过以上步骤,就备份了以后还原用的目录。备份的目录名字使用原目录名后加上.2.3.5后缀,目的是区分不同的Glibc版本目录。

3.3 如何还原系统的Glibc

如果升级最终失败,导致系统无法启动,就必须使用另外一个Linux系统启动,还原上述备份的目录为原来的名字。以笔者的系统为例,升级失败的根文件系统使用hda5分区,其文件系统格式为xfs,将被挂载到/mnt/m1目录。使用Knoppix 5.0.1 Live CD启动后,打开一个控制台,执行"su"命令切换为root用户,执行以下命令

执行上述命令后,Glibc已经被恢复为原来的版本,系统应该可以正常启动。

3.4 如何知道当前的Glibc版本

Mandriva Linux release 2006.0的动态库是Glibc2.3.5。执行"/lib/libc.so.6"可以知道当前的Glibc是什么版本:

从以上输出可以看到,当前系统的Glibc版本是2.3.5,使用Gcc4.0.1编译,编译时运行的Linux内核版本是2.6.12。

Glibc的FAQ文档给出以下程序用于查看当前的Glibc的版本:

把上述程序写到chk_lib_v.c文件,执行以下命令编译:

执行chk_lib_v后有以下输出:

3.5 注意Coreutils依赖的动态库情况

Mandriva Linux release 2006.0系统的/lib/目录下有个tls目录。该目录下的文件是能否成功升级Glibc到2.6的关键。使用ldd命令查看Coreutils的应用程序依赖的动态库情况可以发现:

请注意上述的librt.so.1,libc.so.6和libpthread.so.0,它们都是位于/lib/tls/,而不是/lib/。换言之,ls的执行,依赖于/lib/tls目录下的某些动态链接库文件。tls是thread-local storage,当不同的线程使用同一个全局变量的时候,各线程将会在本地保留该变量的备份,查阅参考资料可以了解更多有关tls的信息。 Glibc2.4,Glibc2.5和Glibc2.6都支持tls。

/lib/tls/下有以下文件:

/lib/tls目录下的文件是一些很重要的动态库及软连接,其中包括libc.so.6,它们都是指向2.3.5版本的动态库文件。

4. 安装Glibc2.6

4.1 第一次make install

切换到root用户,执行make install就开始安装Glibc了:

在安装过程中,将会出现如下错误:

安装失败后,输入任何命令都是无效的,系统只会重 复"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息,重新启动计算机在启动中就会失败,根本无法进入原Linux系统。

出现这样的错误的原因是 Coreutils的应用程序都依赖于/lib/tls/下的动态库,在make install的时候,/lib/ld-linux.so.2从原来指向ld-2.3.5.so被改为指向ld-2.6.so,但这个时候/lib /tls/libc.so.6指向的仍然是/lib/tls/libc-2.3.5.so。/lib/ld-linux.so.2和/lib/tls /libc.so.6各自指向不同版本的库文件导致了Coreutils的命令执行失败,从而make install也失败。

这个时候, 就要用另外一个Linux系统启动,挂载升级失败的根文件系统,把原根文件系统的/lib/tls/下的链接全部改为指向2.6版本的库文件,具体就是 /lib/tls/libc.so.6,/lib/tls/libm.so.6, /lib/tls/libpthread.so.0和/lib/tls/librt.so.1这4个软链接分别指向libc-2.6.so, libm-2.6.so,libpthread-2.6.so和librt-2.6.so。libthread_db.so.1仍然是指向 libthread_db-1.0.so,但这个时候/lib/libthread_db-1.0.so已经是Glibc2.6版本的了,原/lib /tls/libthread_db-1.0.so必须被替换为Glibc2.6版本的libthread_db-1.0.so。

笔者使用Knoppix 5.0.1 Live CD启动计算机,启动后,打开一个控制台,执行"su"命令切换为root,执行以下命令:

上述命令就是把原根文件系统/lib/下的libc- 2.6.so, libm-2.6.so,libpthread-2.6.so和librt-2.6.so拷贝到/lib/tls/下,并把/lib/tls /libc.so.6,/lib/tls/libm.so.6,/lib/tls/libpthread.so.0和/lib/tls /librt.so.1这4个软链接从原来指向2.3.5版本的库文件改为指向最新的2.6版本的库文件。原/lib/tls /libthread_db-1.0.so下的文件被/lib/libthread_db-1.0.so替换。

4.2 第二次make install

修改了/lib/tls/下的链接和文件后,就可以重新启动计算机,进入原Linux系统,这次将会正常启动,登陆后,执行Coreutils的命令,例如 ls,已经不会出现"relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference"的错误信息。由于Glibc2.6没有彻底安装完毕,我们还要重新执行一次make install:

这次make install将不会出现错误,如果安装成功,到最后会有以下信息提示:

执行/lib/libc.so.6查看Glibc的版本:

这都表明当前系统的动态库已经使用了Glibc2.6。

如果把/lib/tls/下的链接改为指向2.6版本的库文件后,重新启动计算机仍然无法进入原Linux系统,就说明升级Glibc失败,只能再次使用另外一个Linux系统启动,恢复原系统的Glibc为原来的版本,请参考3.3节。

4.3 安装时区和地区数据库

虽然现在系统已经使用Glibc2.6,但是在X Window下,使用fcitx中文输入法的用户会发现按下ctrl+space不会弹出中文输入框。这是因为新的Glibc2.6还没安装时区和地区数据库。执行以下命令:

上述命令将会在/usr/lib/locale/下生成一个名为"locale-archive"的文件。重新启动X Window, 按下ctrl+space就可以调出中文输入框并输入中文了。

至此,升级Glibc完毕。笔者在升级到了Glibc2.6的Linux系统上使用了 VMware,Openoffice,Mplayer,Skype,Firefox,Thunderbird,Vim,Fcitx等一系列软件一段时间, 未发现由于升级了Glibc而导致的错误出现。

回到Glibc2.3.5 成功升级后,想在Glibc2.6和原来的Glibc2.3.5之间切换是很容易的。因为安装前对Glibc2.3.5的重要目录进行了备份,只需使用另 外一个Linux启动,挂载原Linux的根文件系统,把升级前备份好的/lib.2.3.5等目录的名字改为/lib等原来的名字即可。

使用Knoppix 5.0.1 Live CD启动,打开一个控制台,执行"su"命令切换为root,执行以下命令:

重新启动,系统将会使用原来的Glibc2.3.5,Glibc2.6的目录备份为原目录名后加.2.6后缀。

总结

使用源代码升级Glibc,做好升级前的准备是最重要的。首先要准备好另外一个可以启动的,能挂载原根文件系统的Linux系统。其次是对/lib, /usr/lib,/usr/include,/usr/sbin,/usr/bin等目录进行备份。成功升级后,可以在高低两个版本的Glibc之间自 由切换。

升级前只要做好上述两个准备,升级系统的Glibc是安全的。

由于不同的Linux发行版的系统环境不一样,因此使用源代码升级Glibc的过程可能会有差异,为了成功升级,读者必须在升级过程中根据自己的系统的实际情况作相应的调整。

链接地址

http://www.ibm.com/developerworks/cn/linux/l-cn-glibc-upd/

WD MyCloud 4.0 deb 安装源

请注意,以下的服务仅仅针对WDMyCloud Gen1,也就是比较早期的型号,最新的Gen2已经把系统从Debian Wheezy切换到了Busybox,因此下面的源已经不适用了。

WDMyCloud Gen1与WDMyCloud Gen2的区别如下:

Gen1: Mindspeed Comcerto C2000 (2 core, 650MHz) 256 MB Ram Debian wheezy
Gen2: Marvell armada 370 (2core, 800MHz) 512MB Ram Busybox


最近由于 WD MyCloud 的固件升级到4.0 之后,新的程序是以 64K 内存对齐的方式运作的,这就导致使用 apt-get 安装的所有安装包都是不能正常运行的,安装后,执行的时候会直接提示 “Killed”,因此需要全新编译代码才能成功安装。有动手能力的,可以参考 How to successfully build packages for WD My Cloud from source 来自己编译。不过非常的折腾。

今天刚刚更新了一下 WD MyCloud 的固件到V04.01.03-421版本,发现他的apt的源列表更新了一下,变成了如下

试了一下,竟然可以安装,并且部分软件运行正常,比如 VIM,Git-Core,Subversion.但是对于 aria2,expect 等软件,建议还是用我提供的源安装,原因在于有些软件需要升级libc6,stdlibc++6等这几个库,而这几个库如果更新,基本上,系统就启动不了了!

对于想省事的人来说,可以设置我的服务器为deb 的更新服务器,里面的是我编译好的版本。

最近调整了更新服务器地址,同时,又增加了Jseeie 版本的编译,这样的话,会有最新的版本的软件,但是,使用的时候要慎重,新版本软件可能没有经过长时间的严格测试,不排除有BUG的可能,如果下载的某些包有问题,麻烦尽快邮件反馈

安装新版本的话,需要手工卸载旧版本,apt-get remove 一下即可。

安装不上软件,提示缺少依赖的,暂时注释掉 jessie 部分的源,原因在于新版本正在编译中,耗时较长,只能是编译完成就上传导致了某些模块缺失。

如下操作即可。

1.打开 WD MyCloud 的SSH 登陆功能。

2.在SHELL 里面执行如下命令

修改里面的内容如下

目前这个安装源中支持的软件可以在下面的软件列表中找到 ,后续我会根据需要编译其他的软件,并且上传的。如果有什么软件是需要的,可以邮件联系我

注意:本源支持HTTPS方式访问,因此上面的配置也可以写成如下方式(目前貌似HTTP会有被劫持的倾向,建议使用HTTPS方式访问(切换到HTTPS之前需要先安装apt-transport-https),切换到HTTPS之后出现问题,可以参考
"method driver /usr/lib/apt/methods/https could not be found" update error来解决。):

3.执行更新

4.安装软件(以VIM 为例子)

5.目前已经编译完成的软件列表如下

wheezy

jessie

目前根据反馈,有人在使用本源的时候,存在如下的情况

base_download_att

也就是在安装任何应用的时候都提示:

这种情况发生的原因,目前初步定位为使用WDMyCloud自带的源执行过

不管成功失败,还是中途中断,可能会导致"/lib/arm-linux-gnueabihf"中的libc库被升级,从而出现下图所示的情况(左边是正常的WDMyCloud系统,右图是出现问题的WDMyCloud):

20160212140006

这个问题的目前有效的解决方法是,使用降级系统版本的方式重新刷机来还原系统:

downgrade_version

How to successfully build packages for WD My Cloud from source

The WD My Cloud comes with a Debian wheezy system on it. However WD customized that in a way that it is hardly possible (if not impossible at all) to install new packages using the standard "apt-get install <package name>" way, especially when you update the device firmware to version 4.x or later. The latest firmware, in fact, uses a modified Debian system with 64K sized memory pages: if you install a package using "apt-get install <package name>" from the standard repositories, almost certainly it won't run and produce just a laconic "Killed" output.
继续阅读How to successfully build packages for WD My Cloud from source

WD My Cloud OOM-Killer 杀死sshd服务导致无响应问题解决

WD My Cloud 的内存只有256M,在安装一系列应用之后,往往会导致内存不足,尤其是磁盘对拷的时候,很大的文件,往往会导致 Linux 内核的 OOM-Killer动作,导致 sshd ,Apache 等的服务被杀死,此时系统的指示灯是正常的,但是网络响应全无,只能强制断电。

先简单讲一下OOM-Killer的原理

OOM-killer:Out-of-Memory (OOM) Killer是一种保护机制,用于当内存严重不足时,为了系统的继续运转,内核迫不得已挑选一个进程,将其杀死,以释放内存,缓解内存不足的问题。
可以看出这种方式对进程的保护是有限的,不能完全的保护进程的运行。

OOM Killer的关闭与激活方式:

在实际运营场景中,我们经常出现ssh连接不上服务器,但ping却是通的情况,这个时候很有可能是内存不够linux启动了oom-killer,系统根据一定的分数和机制来决定
随机杀掉一些程序释放物理内存(特别是我们后台需要大量共享内存而且用了mlock的程序),而sshd进程很可能就是被选中杀掉的进程,因此导致通过ssh登录不上。
这个时候基本上swap也被耗尽, 所有能释放内存的机制内核都已经尝试了。

而ping能够通,主要是因为ping其实是内核协议栈就直接回包了,不会走到用户态,所以还能证明机器还是活着的。

对于每个进程都有一个oom_score的属性/proc/PID/oom_score
oom- killer 会杀死oom_score较大的进程,当oom_score为0时禁止内核杀死该进程。

还有一个/proc/PID/oom_score_adj
一般来说,oom_adj的值越大,该进程被系统选中终止的可能就越高,当oom_adj=-17时,oom_score将变为0。
(要对某个进程进行OOM保护的话就直接向“/proc/pid/oom_adj”中写入“-17”即可。)

所以可以通过命令

来防止重要的进程被oom_killer杀死。

例如可以把sshd进程的oom_adj改为0 ,包括自己连接上的那个终端进程,这样你还可以执行一些运维工作。

既然了解到这些,那么操作方式就很简单了。

为了防止SSHD被杀死,可以在命令行中执行如下命令

为保万无一失,利用Linux的计划任务cron来做一下定时检查。

里面内容如下

表示每10分钟执行一次进程存在检查。

WD MyCloud安装GIT建立GIT Server

WD MyCloud安装GIT的时候,总是提示依赖的OpenSSL Server版本号不匹配,尤其是升级到最新的修复了“Heartbleed” 的版本更是如此,不管如何操作,都是一样的,折腾了半天,结果把系统折腾挂掉了,网页进不去了,只能通过SSH界面重新还原系统,结果竟然可以安装成功了,看来,应该是前面安装openssh-server等的时候,导致的依赖问题,因此,如果出现问题,可以先全部还原系统,然后优先安装GIT 就能解决问题了。

  • 安装GIT(主要是gitgit-daemon)

 不要安装openssh-server,因此不要使用 “sudo apt-get install git-all” 来安装全部的功能 git-all包含了PHP等等的很多东西,更新的东西太多,他会导致版本依赖问题,主要是OpenSSL升级了,而依赖他的其他软件都还没有更新,而由于漏洞问题,系统又不允许早期版本安装。

  • 安装启动工具

用来在系统启动的时候启动Git 的服务器

  • 建立GIT服务器存储目录

1.首先查看分区信息

可以看到具体的分区,我们在 "/nfs/Public" 目录下面建立一个GIT的工作目录,具体根据自己需要来更改

  • 关闭git-daemon(否则可能下面的配置文件修改会被覆盖)

配置启动文件

修改为

其中

--export-all目的是解决 用git clone git://... 时报错,"server log: Repository not exported. " 可以在git文件夹里创建一个叫git-daemon-export-ok的文件或者git-daemon --export-all

--base-pathGit的工程目录

设置好了只后,那么每次开机就会自己启动了。

  • 启动git-daemon

至于剩下的,GIT工程,可以直接拷贝到"/nfs/Public/Git"目录下面就可以了。

有其他的错误的话,详细信息可以在/var/log/git-daemon/current中看到,分析一下日志即可。

  • 初始化远程git工程

服务器仓库使用git --bare init不要使用git init

  • 设置SSH访问

使用上面的设置之后,会发现当使用Git Push命令的时候,经常会长时间卡住,然后无法Push上去,经过Google一番之后,发现是GitBUG,如果想要规避这个BUG的话,老老实实的用SSH来同步就可以了。

1.增加Git用户,并指定工作目录为 “/nfs/Public/Git

2.设置用户的密码

3.更改目录的所有者,并且赋予所有者全部权限

4.增加到SSH用户列表

找到AllowUsers所在行,在已经有的用户后面增加(如果找不到,则在尾部增加git

修改为

用户之间用空格隔开,如果没有这行,可以自行添加即可。
5.重启SSHD服务

6.修改访问Git的方式,把

修改为

7.SSH免密码登录
(1)生成公钥/私钥对

注意"-P"后面输入的内容为空的时候代表不需要输入密码。
完成后会在当前用户目录下的.ssh目录下生成id_rsa,id_rsa.pub这两个文件。
(2)拷贝证书到本地机器
.ssh/id_rsa.pub拷贝下来,然后重命名成id_rsa.pub.git也就是Key加上用户名的命名方式,这样在Linux或者执行命令行的时候SSH可以自动进行用户名,密码的对应。
(3)对于Linux复制的id_rsa.pub.git添加到.ssh/authorzied_keys文件里

authorized_keys的权限要是600
(4)对于Windows,则需要把id_rsa这个文件拷贝下来,然后使用TortoiseGit自带的Puttygen转换为被TortoiseGit支持的.ppk文件。

点击"Conversions"菜单中的"Import key"选项,然后导入我们下载到的id_rsa

PuttyKeyGeneratorImportKey

导入后,

SavePPK

由于Puttygen的BUG,导致如果直接点击"Save private key",会导致生产的Public key是不正确的,因此,需要先点击"Save public key",保存为文件后,无视这个文件即可。然后接下来点击"Save private key"按钮,保存为.ppk文件,这个PPK文件才是我们需要的。

(5)修改SSHD的配置文件/etc/ssh/sshd_config
找到

这句,然后去掉注释。然后重启SSH服务

(6)修改登录认证文件,把认证信息导入到需要认证的用户目录下的.ssh/authorized_keys文件中。

以上面添加的用户git为例子,通过命令:

可以看到输出如下信息:

从而找到用户git的工作目录在/share目录下面.

因此执行如下命令:

接下来,需要修改authorized_keys的所有者为用户git,否则git无法通过这个文件进行认证。

修改权限,否则无法用来登陆

然后修改authorized_keys中的最后用户名的部分为git(由于我们在root中生成的密钥,因此,默认的用户名是root,因此需要修改这个用户名).

最后的root@WDMyCloud修改为git@WDMyCloud.这样在认证的时候,才能成功进行用户名密钥的核对。
否则需要设置/etc/ssh/sshd_config里面的StrictModes yes修改为StrictModes no,这样SSH会忽略用户名的校验。

参考链接


login using ssh on multiple user accounts using the same id_rsa and id_rsa.pub [closed]
Linux下如何修改用户默认目录

解决WD MyCloud 通过SSH 登陆之后中文显示问题

WD MyCloud通过SSH登陆之后中文显示为问号,网上查询了一下,找到解决方法。

首先执行

可以看到,在输出中是存在中文的“zh_CN.utf8”,因此,只要启用就可以了。

因此,执行如下命令

然后修改里面的

然后,退出,重新登陆终端即可。

WD My Cloud NAS on Ubuntu

下文暂时没有办法处理有用户名,密码的情况。

I decided that 2014 for me was going to be the year of the Network Attached Storage (NAS). Last year was the year that I finally abandoned my desktops and went all laptop for both my Mac-based iOS development workflow and general purpose computing (i.e, everything else on my Acer i5 running Lubuntu). This year I wanted to have a massive centralized storage where I could put all my videos and photos so I can access it from any laptop or mobile device. What follows is what I chose and how to hook it up to Lubuntu.

I first looked at external cloud solutions (DropBox, Box, CrashPlan, BackBlaze) and although they were all cool they were unfortunately out for me due to three reasons. First, the storage limits – I didn’t want Gigs – I wanted Terabytes. Although, CrashPlan and BackBlaze both offer unlimited online storage they limit the number of devices. Two, I didn’t have all the files centralized on one computer and it would be best to centralized all my Mac, Linux, and iOS data first before I could go to one of these offsite back-up solutions. Third, these all cost money in a form of a monthly fee of $5 or $50 yearly subscriptions. These offline solutions are definitely part of the final solution but I decided that would be a second phase for me. It looked like I had developed a phased project that broke down into two phases of centralization first and then offsite continuous backup second.

The first phase then came down to having a Network Attached Storage (NAS) type unit. The new Airport Time Capsule looked cool but I wanted something less Appley. I have had good experiences with Western Digital (WD) drives and saw in the January 2014 issue of Maximum PC a head-to-head between Dropbox and the new WD My Cloud product. A successor to the My Book branded drive this new My Cloud branded offering provides a shell to a NAS device and it was cheaper than a Time Capsule. I was sold and for X-mas asked Santa for the WD My Cloud 4TB Personal Cloud Storage – NAS (WDBCTL0040HWT-NESN) device.

Set-up was literally plug and play. There is an iOS App for iPad and iPhone/iPod Touch which allows upload to and download/stream from the NAS. The WD website and User Manual mention Mac and PC software to mount and sync that make connection a breeze. The device supports Time Capsule so I’ll be doing that with my Mac laptops (yes – there is no limit to how many computers connect to this thing). Then came my Linux laptop. There was no mention of Linux which is a shame since you would think that they are leveraging the community’s efforts in their products. But it was easy enough to connect my Lubuntu laptop as a Network File System (NFS) Client via three shell commands.

First, I changed directory to my home directory and created a nfs directory in there:

Then I applied the following three shell commands:

If you cd into nfs you’ll be accessing the WD My Cloud device. That’s it. I started to copy twenty mp4 files totalling 1.6GB into the device through 802.11g and it took 8 minutes. I was then streaming these on my iPad mini.

I hope this helps assure you you can connect to this from Linux. I know once I finished the plug and play I panicked for a bit thinking I wouldn’t be able to connect my Linux machines to this device but now I happily throw everything I have onto this. Also, it has a USB 3 port on the back so I can simply plug another 4TB USB drive on it and expand it in the future.

引用链接 http://cocoaallocinit.com/2014/01/04/wd-my-cloud-nas-on-ubuntu/

拯救死翘翘了的WD MyCloud

WD MyCloud 在通过SSH 进入命令行的时候误操作,导致系统彻底完蛋,查找了很长时间,找到了解决方法。

  • 对于彻底完蛋了的系统,比如,已经无法进入系统了,不管是SSH 还是网页,总之就是系统动不了。 则参考如下操作:(注意本方法会导致数据被彻底删除,使用时候要慎重

1.从http://pan.baidu.com/s/1eQBVbc2 下载3TB 版本的系统恢复镜像。

2.拆开机器,系统出厂自带的是Debian linux系统,重装系统需要将外壳拿掉,将硬盘取出。外壳是通过卡扣连接主体的,拆的时候有可能会折断卡扣,但不会影响重装回去之后的外观。大致方法就是,找几张废旧电话卡或银行卡从机子的后背也就是网卡口的左右两侧的外壳缝隙插进去,稍微撬开一点缝隙,保持卡片不动,然后将外壳用巧力使劲往 前推,慢慢的推出去,即可把外壳拆下。硬盘和壳子通过4个胶垫固定,先抬起硬盘一侧,使得两个胶垫脱离壳子,然后再慢慢向上和向外取出即可,过程没什么技 术含量,只需要小心一点就是了。连接主板和硬盘有4颗螺丝,其中一颗在led灯胶垫下,掰开胶垫可见,一并拧下。

3.把硬盘挂载到一台Linux的机器,推荐使用 Ubuntu ,本机使用的是 Ubuntu 13.10 .挂载的时候,可以使用USB 或者 ESATA接口的移动硬盘盒即可。

4.建议删除原始磁盘上的所有分区

5.使用 如下命令强制还原镜像到硬盘,假定此时硬盘被挂载到了 /dev/sdb上

6.装回硬盘到 WD My Cloud ,(注意此时不要用Linux 自带的gparted 操作硬盘,否则会导致无法启动),然后开启 SSH ,在命令行中执行 parted 命令,此时,会提示分区存在问题,按照提示修复即可。尽量在My Cloud 里面执行脚本命令,外面的Linux 执行命令的话,经常导致无法启动问题,最好在My Cloud 里面执行一下 e2fsck 来检查一下磁盘,尤其是最后的数据分区,恢复的时候一般都会有分区表错误,貌似只有在SSH 里面执行的才是正常的,原因未知。至于下面的分区大小调整,如果能在SSH 中处理的话,是最好的,问题最少。 下面是SSH 处理的SHELL 记录

最好升级一下 usb 接口的程序版本,新版本貌似修正了大文件拷贝会死机的问题

7.再次拆卸硬盘,用Linux 中的 gparted 来根据实际硬盘的大小来调整硬盘,比如,我的是4T 版本的,刷完之后,会有1T 的空白分区,这个时候可以通过gparted 来调整到整个硬盘。 (注意,外面调整分区可能导致不能启动,原因未知,因此恐怕要多尝试几次

8.装回硬盘,重新启动,最好恢复一下出厂设置。

  • 如果分区都还在,又不想损坏数据,可以试试如下方法

1.下载最新的固件版本比如 http://download.wdc.com/nas/WDMyCloud-030104-139-20131028.zip 解压缩数据 从CacheVolume 目录中找到 rootfs.img 文件,大约2G 的样子,解压缩到某个目录即可。

2.按照上文方法拆卸硬盘,并挂载到Ubuntu。

3.在磁盘管理器中打开如下界面,还原到的分区为管理器中现实Raid 的两个分区中,两个分区逐个还原。

original

选择 "Restore Disk Image"

original2

上面的方法有些人可以恢复成功,有些没有办法恢复成功,中间的差别一般在于有些人机器上安装了mdadm。如下图所示,磁盘挂载后会识别出"2.0GB RAID-1阵列",如果下面的挂载位置不是"/dev/md/0",而是显示"/dev/md127"或者"/dev/md126",那么,即使什么都不操作,直接装回去,也可能发现WDMyCloud不能正常启动了。
 这个原因是由于机器上安装的mdadm无意之间修改了部分内容,导致WDMyCloud无法识别。解决办法是在电脑上重建这个"2.0GB RAID-1阵列",以系统会把磁盘挂载到/dev/sdb为例子,方法如下:

重建完成后,挂载位置被修正为"/dev/md/0",然后通过在"2.0GB RAID-1阵列"上点击"对分区映像恢复"(英文应该是"Restore Disk Image")进行镜像的恢复工作。

恢复完成后,先执行

停止阵列,然后点击顶部的"Power Off"按钮,移除磁盘。如下图:

上面的操作完成后,一般会出现磁盘错误,建议进行磁盘检查,具体操作过程如下:

上述操作完成后,如果首页容量部分一直显示0KB,则参考WD MyCloud拆硬盘恢复系统后容量部分显示0KB

参考链接


WD My Book Live 离线升级固件

MBL通电后登录Web管理界面,第一件事就是要求升级固件,点了确定后才发现下载进度堪比蜗牛,一个半小时进度大约50%。升级不完还没办法进一步设置,实在无法忍了,边下边找办法看能不能快速搞定吧。

MBL官网上没找着固件下载链接,只见一行小字写着现在已经不再支持手动升级固件。肯定会有办法的,能自动升级必须可以手动。

用SSH连接上,果然在 /usr/local/sbin 目录下发现了一堆设置相关脚本,其中有两个:

第一个脚本看名字就知道干啥用的,正是下载好固件手动升级用的,等下再细看怎么用;直接看第二个吧,真相来了,第24行代码直接告诉你怎么拿到最新固件的下载地址:

在shell中敲入下面的命令:

下载链接是不是已经出来了(前提是Web管理界面里的自动下载还在进行,如果已经没有执行或已经取消,/tmp/update_url 文件是不存在的,你知道该怎么办)。接下来的事情更加简单了,用迅雷或是QQ旋风等任意工具将固件下载回来,应该是一个.deb文件,然后通过 winscp或是文件共享把它放到MBL的目录里,MBL共享用的 /shares/Public 目录就挺好,最后在 /usr/local/sbin 目录下执行:

你将会惊奇地发现Web管理界面上已经显示出了升级进度,耐心等待……几分钟就好。

参考链接 http://i.migege.com/my-book-live-manual-updating.html