Ext4 文件系统所支持最大分区

前段时间需要上个存储服务器,弄了个 20TiB 的分区使用。考虑到 Linux 上面的 ext4 文件系统已经比较成熟了(大多数发行版的默认文件系统),并且初略查看了一些资料发现能支持的分区最大值也远大于 20TiB ,所以装好系统后就执行了

mkfs.ext4 /dev/sdb1

结果却报错了:

mkfs.ext4: Size of device /dev/sdb1 too big to be expressed in 32 bit susing a blocksize of 4096.

google 了一圈才发现,虽然 ext4 文件系统是支持大于 16TiB 的分区,但是用来创建 ext4 文件系统的工具————e2fsprogs 的较低版本却不支持。需要 1.42 版本以上才支持。

"This release of e2fsprogs has support for file systems > 16TB. "
http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.42

不想升级 e2fsprogs 了,于是转而按照 Red Hat 推荐用了 XFS。

mkfs.xfs /dev/sdb1

SELinux 相关链接

今年的主要成果就算是对SELinux的一点研究了,没搞到内核源代码的级别去,不过至少对它的使用、配置、troubleshooting以及策略编写是熟悉了。

FAQ里面算是总结的一些对SELinux使用常见的一些问题了,后面还有些实用链接,不过真的要学习SELinux的话,光这些是远远不够的。

1.  FAQ

1.1. 是否应该开启SELinux

Q: 系统安装完之后,SELinux 默认是开启的,但是它导致了我部署的非常多的应用无法正常运行,所以我把它关闭了。但是现在又有很多人提倡不要关闭SELinux,甚至还专门为此建立了一个网站——http://stopdisablingselinux.com/ ,请问关闭SELinux 真的会使得系统不安全吗?我到底是该关闭它还是不关闭呢?

A:

简短版:

如果您对是否应该开启SELinux 有点犹豫,那么您应该关闭它。

详细版:

关闭SELinux 并不一定是等于降低系统安全,系统的安全最重要的是取决于运行在上面的程序本身,SELinux 只是一个防护机制,它也并不能从根本上消除程序里面的bug。相反,如果用户并不熟悉使用SELinux 的话,他会在使用过程中遇到许多有SELinux 导致的“未知原因”故障,在不知情的时候,用户往往会采取其它的比如:关闭防火墙,关闭程序自身的保护措施来排查问题,这反而是导致了其它安全防护措施的去除,并且也严重影响了这些用户对系统的正常使用。

许多人提倡保留开启SELinux 的原因是现在的发行版自带策略已经可以使得用户基本无法感受到SELinux 的存在,但这并不是绝对的,在运行httpd,ftpd,samba 等服务的时候还是很容易遇到被SELinux 策略阻止而导致的访问拒绝。而发行版自带的策略包里面还会有bug,导致一些难以排查的错误。用户如果要学习SELinux 也并不容易,SELinux 非常复杂。

所以,如果您运行的系统上面没有关键的应用或者数据,或者没有足够的排查、解决SELinux 问题的能力以及比较多的耐心和时间来学习SELinux 的话,建议从实际出发,把它关掉。

1.2. 开启和配置SELinux

Q: 怎样开启和配置SELinux

A建议首先将/etc/selinux/config 文件中的配置修改为Permissive 模式后重启,在Permissive 模式下所有的AVC 访问拒绝都会被记录,但并不会真的拒绝。重启系统后,请您使用aureport -a 命令查看在启动过程中有哪些AVC产生,直到将所有的AVC都消除后,再将配置由Permissive 模式改为Enforcing 。

1.3. 设置SELinux为Enforcing模式后系统无法启动

Q: 我将它设置为Enforcing 模式重启后,系统都起不来了!连单用户模式都无法进入,只能再用光盘进行修复了吗?

A: 不需要。在grub 的kernel 行加上selinux=0 的参数即可禁用SELinux 进入系统。

1.4. 如何正确修改文件安全上下文

Q: 我的网站文件放在/web 目录下,但是SELinux 导致网站无法正常运行起来,我把/web目录的context 改成了httpd_sys_content_t 等类型后可以正常运行网站了,但是重启系统后就又变回原来的default_t 了,有什么办法可以使对/web 路径的context 修改永久生效吗?

A: 这种情况下正确的做法是手动为您使用的非系统默认路径创建默认context 规则,使用semanage fcontext 命令:

semanage fcontext -a -t httpd_sys_content_t “/web(/.*)?”

然后执行

restorecon -Rv /web

应用对/web 目录添加的策略规则。

1.5. 能否只针对某一个服务关闭SELinux

Q: 既然系统默认的targeted 策略是针对各个服务而编写的,那么我可以只针对Apache httpd 服务或者vsftpd 关闭SELinux 吗?

A: 可以。永久关闭httpd 策略:

setsebool -P httpd_disable_trans on

另外还有,永久关闭vsftpd 策略:

setsebool -P ftpd_disable_trans on

提示:使用getsebool -a | grep disable_trans 命令可以找到其它更多的关闭某一项服务策略的布尔值。

1.6. 确认某一个路径的文件context 规则

Q: 如何确认某一个路径的文件context 规则?

A: 简单检查某个路径的安全上下文可以使用matchpathcon命令,比如:

matchpathcon /var/www

但是matchpathcon并不能查看是哪一条规则决定了/var/www 路径的安全上下文,这需要semanage fcontext -l命令查看。

1.7. 遇到AVC 的时候怎么办

Q: 遇到AVC 的时候怎么办?

A: 如果您确实需要保持SELinux 开启的话,请采用以下步骤解决AVC:

1、首先应该使用getsebool -a命令查看是否有某个布尔值决定了您程序的访问被拒绝;

2、留意您的文件是否被贴上了正确的安全上下文

3、如果以上都不符合。使用audit2allow 工具创建新的模块,并且加载

1.8. 域和类型的区别是什么

Q: 域和类型的区别是什么?

A: 域和类型之间没有区别,虽然有时候域是用于指代进程的类型。域的这种用法是出于域-类型强制模型(DTE),这个模型里面的域和类型是分离的。

2.  参考资料

目前SELinux的使用还并不是非常的广泛,因此能找的相关配置和原理等文档也比较少。这些是我目前所找到的一些很有用的资料,但不是全部。

http://danwalsh.livejournal.com/

一个资深红帽SELinux专家的博客,里面有非常多的实用信息。

SELinux from the inside out

Google 安全人员对SELinux 的一些引导研究,稍微涉及到了内核代码

http://selinuxproject.org/page/Main_Page

SELinux项目的官方wiki

http://www.crypt.gen.nz/selinux/faq.html

https://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/

Fedora SELinux FAQ

启用IPv6

今天才记起来所用的这个vps提供商其实是支持IPv6的,所以把它启用了

在现在的主要服务——web,email 等上面的配置都并不复杂,稍微再花了一点时间在改ip6tables脚本上面了。

UEFI安装及卸载Linux

在启用了secure boot的笔记本上面装了一下Kubuntu 13.10,体验还是比较差,于是把它又卸掉了,安心的用Windows 算了,以后要是还能搞个台式机再跑Linux 吧。这里记一下整个安装及卸载过程。

其实安装引导的过程没有想象的复杂,用unetbootin 做个u盘启动就行了,开机按Esc 可以自动识别出U盘,加载也没有问题,因为(K)ubuntu 新的版本已经兼容secure boot。但后面的东西比较让人不爽,先是进入安装界面都会被nouveau 驱动把内核搞挂(加nomodeset 启动参数解决),而安装上去后,即使安装了Nvidia 官方驱动,图形界面性能还是太差。而另外的问题还有plasma-nm 记不住WiFi 密码,DPI 放大后整个桌面太不和谐(不放大更不能用,太小)等问题。

于是在用了一天后,我决定卸载它。先是在Windows 里面把几个Linux 分区干掉了,然后使用管理员权限执行cmd,运行

bcdboot c:\windows /l zh-cn

就修复了启动管理器。或者用bcdedit 去编辑也行。。。

如果还和我一样,对于系统EFI 分区底下还有个没用的ubuntu 文件夹存在而不自在的话,可以以管理员身份进入命令提示符,用diskpart 给EFI 分区分配盘符,然后cd 进去直接rd /s /q ubuntu 就行。

bash: $RANDOM 不够randomly?

为了小小的测试一个东西,写了一个小脚本,想将ftp取下来的文件随机命名(file.32489, file.324, file.xxxx这样)。

本来用file.$RANDOM 这样的方式生成文件名(在我看来,使用这个内置的bash 变量来达到目的会是个很简单的方法),但结果却不尽如人意:1000次循环跑下来,“取”下来的文件却只有981个,这不是取文件时失败了,而是有重名,导致文件被覆盖了。$RANDOM 的范围是0~32767(bash(1)),循环一千遍就出现19次重复了。。。

于是又费神写了一个复杂点的随机字符生成函数。哈,终于没有重复了!

但后来再一想,有点不对劲,脑子似乎不太灵光。一个$RANDOM 不够随机,两个、三个活着更多不就完了?

file.$RANDOM$RANDOM$RANDOM….

Kubuntu 11.10 不显示ibus 的选词框和系统托盘

折腾了一下,把自己的电脑换成了Kubuntu 11.10 ,但结果发现用装好(aptitude install ibus-pinyin-db-open-phrase ibus-qt4 ibus-gtk ibus-gtk3 ibus-pinyin)ibus-pinyin 输入法之后,它怎么也不会显示出选词框和系统右下角的托盘。

解决办法:用ibus-daemon -x -v 命令启动ibus 服务可以发现一些错误提示;安装gnome-icon-theme 可以解决这个问题。

Gnome 3 还好

我把Ubuntu 从11.04 升级到了11.10 的开发版。(令我感到意外的是——尽管升级过程并不顺利(强迫重启了2次),但升级后的新系统记过一些调整后却很似乎很稳定,没见到太多的软件包本身的bug,比之前从10.10 升级到11.04 alpha 轻松多了。)

升级后,我并没感到Unity 桌面环境有什么大的改进。相反,对于新的ctrl+tab 的功能设置我实在无法接受,我以前都用它切换浏览器标签的。。。

11.10 的一个好处是GNOME shell 可以和Unity 共存,所以我又安装了GNOME shell,这东西比我想象中的要好。最主要的就是响应速度上了,比那个基于糟糕compiz 的Unity 好太多了。举个例子,在GNOME shell 和Unity 环境中分别按下Windows 键,GNOME shell 几乎是立即就弹出那个Acitivites 界面了,而Unity 底下往往得卡个一两秒钟。。

GNOME shell 另一个明显强于Unity 的地方就是屏幕左边那个“panel”了。使用Unity 时,鼠标往屏幕左边移动时都得很小心,以防止把那个panel 给激活了;而在GNOME shell 中则是无需担心的,屏幕左上角才是用户需要“担心”的。

目前就这点感觉吧。。。

Systemd 让Linux 不再那么Unixy

Systemd 会让Linux 变得很不那么Unixy 是因为systemd 本身可以说是一个完全的anti-Unix 的产品。它违反了众多的Unix 的哲学:它不爱“KISS” 原则;同样对“do one thing and do it well” 也不感冒;它为了效率而牺牲了可移植性;它反对shell 脚本的使用(同样是为了效率)。。。是的,这个严重被Mac OS X 的launchd 所影响的init system 就是这么的反Unix,因为它所有一切的追求就是“功能强大”和“高效率”。

  • systemd 不Simple 也不止do one thing,它远不止一个单纯的init system。除了取代/sbin/init 作为PID 1 进程以引导整个系统启动和启动后作为整个系统的超级守护进程,systemd 还要取代cron,at 和inetd 这样的守护进程。systemd 的创造者Lennart Poettering 解释这么做的原因大概是——既然每个Linux 都得有cron,at 和inetd 这样的服务,那么让他们各自有可执行文件在系统启动时来产生新的进程就完全是用了很多重复代码了。直接让systemd 在系统启动时用同一段代码就可把cron,at 启动起来,并且启动速度上也会有提升。
  • systemd 无法移植到非Linux 内核的操作系统上去。因为它从根本上是依赖于Linux 内核的cgroups (control groups) 的。因为利用了cgroups,systemd 才可以完完全全地将一个服务的所有进程都固定在一个group 里,double-fork 也无法让一个非特权进程跳出这个group。基于cgroup,systemd 提供了很强大的针对某个服务的进程的管理[1]。
  • systemd 认为使用shell script 的结果是效率低下。脚本过多的调用了系统中的像sed,awk,find,grep 这样的工具,而每调用一次则会产生一个新的进程,这严重地影响了操作系统的启动(看看Linux 刚刚启动后,系统最大的PID 到了多少?再看看Mac OS X 的呢?)。

Lennart Poettering 说:

…if you tell me that systemd is not Unixy, then I can only agree, and I don’t feel ashamed at all of that. Because my horizon is much further than just Unix.

引入systemd 无疑与传统Unix 哲学在多方面冲突的。Linux 20 年来几乎所有方面都是在跟着传统Unix 哲学在做,sysfs 和proc 文件系统的引入尤其如是,它们使得Linux 在这点上比之“Unix 正统后代”——*BSD 更加Unixy。因为,在Unix 里一切都是文件。

Fedora 15 已经是确定要从Upstart 转向使用systemd 了,OpenSUSE也在跟进。另外重要的应该就是Debian 和Ubuntu 的反应了,Debian 到最近的6.0 也还没有使用Upstart,并且systemd 也已经进入unstable 源。而对于Ubuntu 来说,早在自行开发出Upstart 之前,他们就准备使用launchd,后来因为协议问题而未果,继而自己开发了Upstart。以后要是转向systemd 应该也算是圆了多年前的梦想吧。

[1]. http://0pointer.de/blog/projects/systemd-for-admins-4.html

chroot 环境的配置

  • ldd(1) 的使用。将要放进chroot 环境中的可执行文件所需的库文件大多(并不是所有)可以用ldd(1) 先在宿主环境中运行它来找到。strace(1) 也许也会有用。
  • 直接切换到那个chroot 环境中。基本的库文件复制到chroot 环境中后,可以用chroot(8) 试着执行里面的可执行文件了。另外还可以将/bin/sh 复制到chroot 环境中并执行,这样也许更方便。/bin/sh 链接到的动态库很少,所以复制它,但是复制一个静态链接的shell 进去也行。
  • 某些程序运行所需的非动态链接库文件。如关于时区的/usr/share/zoneinfo/ 。
  • 必备的库文件。如libnss_dns.so.2 ,否则即便有resolv.conf(5) 在etc 目录底下,也还是不能进行域名解析。