Reprint

PXE http://blog.csdn.net/nirendao/article/details/76012939 PXE启动原理以及与普通Linux启动的对比 原创 2017年07月24日 11:28:36 标签: PXE /boot /Linux 1011 关于PXE部署的详细配置的文章已经有不少了,这篇文章主要讲一下PXE启动的原理以及PXE启动和普通Linux启动的对比。 一、PXE启动原理: 原理图如下: DHCP的用途是: 提供client network参数和TFTP服务器的地址,最初的bootstrap程序 (即DHCP或BootP等) 和所需的程序。 首先,PXE client端 (BIOS里面的PXE固件) 广播一个DHCPDISCOVER的包,它询问所需的网络配置以及网络启动的参数。标准DHCP服务器 (非PXE enabled) 将回复一个普通的DHCPOFFER包,其中包含网络信息 (如IP地址) ,但并不能提供PXE相关参数,因此PXE Client并不能启动。而PXE enabled的DHCP服务器所回复的DHCPOFFER包里则包含PXE相关信息。 在解析一个PXE enabled的DHCP服务器返回的DHCPOFFER包后,PXE client就能够设置自己的IP地址、IP Mask等等,并且指向网络上的启动资源,比如TFTP服务器上的vmlinuz文件和initrd文件。 然后PXE client就通过TFTP下载这些启动资源到自己的内存中；如果是UEFI Secure Boot (而不是Legacy的BIOS) 则还会检验一下这些启动资源。下载完成后就会用这些资源来启动了。 这些启动资源其实就是最小的操作系统 (比如WindowsPE,又比如一个basic Linux kernel+initrd) 。这个最小操作系统在装载了网络驱动和TCP/IP协议栈之后,就会开始boot或者install完整的操作系统了。而这个boot或install的过程,就不再通过TFTP来做,而是通过更加健壮的网络传输协议 (如HTTP、CIFS、iSCSI或NFS) 来做。而boot或者install所用到的实体,比如磁盘或者CD-ROM,是位于远端的,因此需要通过网络传输协议来做。 二、PXE启动过程和普通的Linux系统启动过程的对比: 内核引导之前的不同: 普通的从硬盘启动Linux系统最初是BIOS将MBR加载入内存,然后将控制权交给MBR中的bootloader程序 (如GRUB) ,bootloader程序经过几个stage的加载后,最后将vmlinuz加载入内存,开始内核引导； 而PXE的启动过程在内核引导之前,是由BIOS中的PXE固件开启NBP程序 (比如DHCP的网络通信) ,然后下载vmlinuz和initrd,之后再进入内核启动过程。 内核引导之后的不同: vmlinuz和initrd运行得差不多了之后,普通的硬盘Linux启动就从本地硬盘加载/sbin/init并运行为1号进程,以及启动系统服务等等,而PXE的启动在内核引导完成之后,仍然会通过网络的方式 (但不是TFTP协议,而是其他更加健壮的协议如NFS、iSCSI等) ,加载真正的完整操作系统,如/sbin/init应该就是位于网络远端的硬盘上。 以iSCSI为例,网络远端的硬盘以iSCSI协议挂载到了当前机器,就好像是本地磁盘一样。这就是PXE+iSCSI的启动方式了。 参考文献: https://en.wikipedia.org/wiki/Preboot_Execution_Environment http://blog.csdn.net/nirendao/article/details/75949536 Diskless iSCSI boot with PXE HOWTO

golang cron https://www.jianshu.com/p/626acb9549b1 cron 表达式的基本格式 用过 linux 的应该对 cron 有所了解。linux 中可以通过 crontab -e 来配置定时任务。不过,linux 中的 cron 只能精确到分钟。而我们这里要讨论的 Go 实现的 cron 可以精确到秒,除了这点比较大的区别外,cron 表达式的基本语法是类似的。 (如果使用过 Java 中的 Quartz,对 cron 表达式应该比较了解,而且它和这里我们将要讨论的 Go 版 cron 很像,也都精确到秒) cron(计划任务),顾名思义,按照约定的时间,定时的执行特定的任务 (job) 。cron 表达式 表达了这种约定。 cron 表达式代表了一个时间集合,使用 6 个空格分隔的字段表示。 字段名 是否必须 允许的值 允许的特定字符 秒(Seconds) 是 0-59 * / , - 分(Minutes) 是 0-59 * / , - 时(Hours) 是 0-23 * / , - 日(Day of month) 是 1-31 * / , – ? ...

archlinux 内网域名 ping 结果和 dig 结果不一致 检查 /etc/resolv.conf 配置 确认/etc/hosts中是否添加了额外域名: 没问题； 确认域名服务器中正确的内网域名对应的IP,并和同事确认发现内网域名更新过,ping的结果指向了旧的IP,nslookup的解析结果正确； linux服务器本地会有域名缓存以加快域名解析,centos下用的是nscd ping一般会直接使用缓存的域名,nslookup会直接到域名服务器查询 systemctl restart systemd-resolved

zmodem, rz, sz install pacman -S lrzsz yum install lrzsz konsole Edit>Zmodem upload ( ctrl + alt + U ) http://www.cnblogs.com/strikebone/p/3454679.html zssh 的全名叫 ZMODEM SSH. 看名字就知道, 使用的 zmodem zmodem 协议方便主要表示在以下点 其一,不需要输入很长的命令和密码,直接使用rz,sz加文件名,就能实现文件的收发。速度还很快。 其二,在中转了一台主机时,要在目标主机和本地主机之类,要传送文件,scp相当的麻烦,需要输入多次命令用户密码.但sz直接可以穿透。 好了,讲使用,如下,和使用ssh完全一样,只是打命令时,变成了zssh #zssh root@192.168.1.1 好了,在进入后,你需要上传文件的话。先 #ctrl+@ zssh >//这里切换到了本地机器 zssh>pwd //看一下本地机器的目录在那 zssh>ls //看一下有那些文件 zssh>sz 123.txt //上传本地机器的当前目录的123.txt到远程机器的当前目录 下载文件的话 #sz filename //在远程机器上,启动sz, 准备发送文件 看到一堆乱码 然后在 #ctrl+@ zssh > pwd //看看在那个目录,cd 切换到合适的目录 zssh > rz //接住对应的文件 我靠, 这个rz , sz的命令太难理解了. 还好有高手指点. 文件传输协议: ...

jetty-maven-plugin, jetty maven plugin maven plugin <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.33.v20201020</version> <configuration> <stopKey>stop</stopKey> <stopPort>5599</stopPort> <webApp> <!-- <contextPath>/app0</contextPath> --> <contextPath>/</contextPath> <defaultsDescriptor>src/main/resources/webdefault.xml</defaultsDescriptor> </webApp> <scanIntervalSeconds>2</scanIntervalSeconds> [httpConnector](httpConnector) <port>8080</port> </httpConnector> </configuration> </plugin> webdefault.xml 可以去maven的本地仓库找到 .m2\repository\org\eclipse\jetty\jetty-webapp\9.4.20.v20190813 解压后在这里可以找到webdefault.xml jetty-webapp-9.4.20.v20190813\org\eclipse\jetty\webapp run mvn jetty:run mvnDebug jetty:run # 默认调试端口8000 debug - mvnDebug https://blog.wiloon.com/?p=15212 mvnDebug -suspend默认为n, https://www.eclipse.org/jetty/documentation/jetty-11/programming-guide/index.html#jetty-maven-plugin http://www.blogjava.net/fancydeepin/archive/2015/06/23/maven-jetty-plugin.html https://my.oschina.net/jackieyeah/blog/524556 https://stackoverflow.com/questions/7875002/setting-debug-configuration-for-mavenjettyeclipse

maven plugins, pluginManagement https://www.jianshu.com/p/49acf1246eff 1.plugins和pluginManagement的区别概述 plugins 和 pluginManagement 的区别,和我们前面研究过的 dependencies 和 dependencyManagement 的区别是非常类似的。plugins 下的 plugin 是真实使用的,而 pluginManagement 下的 plugins 下的 plugin 则仅仅是一种声明,子项目中可以对 pluginManagement 下的 plugin 进行信息的选择、继承、覆盖等。 2.pluginManagement使用实战 假如存在两个项目,项目A为项目B的父项目,其关系通过pom文件的关系确定。项目A的父pom文件片段如下: org.apache.maven.plugins maven-source-plugin 2.1 true ...

ARM, X86/Atom, MIPS, PowerPC http://blog.csdn.net/wangjianno2/article/details/52140936 四大CPU体系结构ARM、X86/Atom、MIPS、PowerPC 转载 2016年08月07日 02:54:10 6375 RISC (reduced instruction set computer,精简指令集计算机) 是一种执行较少类型计算机指令的微处理器,起源于80年代的MIPS主机 (即RISC机) ,RISC机中采用的微处理器统称RISC处理器。这样一来,它能够以更快的速度执行操作 (每秒执行更多百万条指令,即MIPS) 。因为计算机执行每个指令类型都需要额外的晶体管和电路元件,计算机指令集越大就会使微处理器更复杂,执行操作也会更慢。 性能特点一: 由于指令集简化后,流水线以及常用指令均可用硬件执行； 性能特点二: 采用大量的寄存器,使大部分指令操作都在寄存器之间进行,提高了处理速度； 性能特点三: 采用缓存—主机—外存三级存储结构,使取数与存数指令分开执行,使处理器可以完成尽可能多的工作,且不因从存储器存取信息而放慢处理速度。 其中ARM/MIPS/PowerPC均是基于精简指令集机器处理器的架构；X86则是基于复杂指令集的架构,Atom是x86或者是x86指令集的精简版。 根据各种新闻,Android在支持各种处理器的现状: ARM+Android最早发展、完善的支持,主要在手机市场、上网本、智能等市场； X86+Android 有比较完善的发展。有atom+Android的上网本,且支持Atom+Android 和 Atom+Window7双系统； MIPS+Android目前在移植、完善过程中； Powpc+Android目前在移植、完善过程中。 1.ARM ARM架构,过去称作进阶精简指令集机器 (Advanced RISC Machine,更早称作: Acorn RISC Machine) ,是一个32位精简指令集 (RISC) 处理器架构,其广泛地使用在许多嵌入式系统设计。由于节能的特点,ARM处理器非常适用于行动通讯领域,符合其主要设计目标为低耗电的特性。 在今日,ARM家族占了所有32位嵌入式处理器75%的比例,使它成为占全世界最多数的32位架构之一。ARM处理器可以在很多消费性电子产品上看到,从可携式装置 (PDA、移动电话、多媒体播放器、掌上型电子游戏,和计算机) 到电脑外设 (硬盘、桌上型路由器) 甚至在导弹的弹载计算机等军用设施中都有他的存在。在此还有一些基于ARM设计的派生产品,重要产品还包括Marvell的XScale架构和德州仪器的OMAP系列。 优势: 价格低；能耗低； ARM 授权方式: ARM 公司本身并不靠自有的设计来制造或出售 CPU ,而是将处理器架构授权给有兴趣的厂家。ARM 提供了多样的授权条款,包括售价与散播性等项目。对于授权方来说,ARM 提供了 ARM 内核的整合硬件叙述,包含完整的软件开发工具 (编译器、debugger、SDK) ,以及针对内含 ARM CPU 硅芯片的销售权。对于无晶圆厂的授权方来说,其希望能将 ARM 内核整合到他们自行研发的芯片设计中,通常就仅针对取得一份生产就绪的智财核心技术 (IP Core) 认证。对这些客户来说,ARM 会释出所选的 ARM 核心的闸极电路图,连同抽象模拟模型和测试程式,以协助设计整合和验证。需求更多的客户,包括整合元件制造商 (IDM) 和晶圆厂家,就选择可合成的RTL (暂存器转移层级,如 Verilog) 形式来取得处理器的智财权 (IP) 。借着可整合的 RTL,客户就有能力能进行架构上的最佳化与加强。这个方式能让设计者完成额外的设计目标 (如高震荡频率、低能量耗损、指令集延伸等) 而不会受限于无法更动的电路图。虽然 ARM 并不授予授权方再次出售 ARM 架构本身,但授权方可以任意地出售制品 (如芯片元件、评估板、完整系统等) 。商用晶圆厂是特殊例子,因为他们不仅授予能出售包含 ARM 内核的硅晶成品,对其它客户来讲,他们通常也保留重制 ARM 内核的权利。 生产厂商: TI (德州仪器) /Samsung (三星) /Freescale (飞思卡尔) /Marvell (马维尔) /Nvidia (英伟达) ...

Import the Certificate as a Trusted Certificate keytool -import -alias stan -file StanSmith.cer -keystore exampleruthstore https://docs.oracle.com/javase/tutorial/security/toolfilex/rstep1.html

CIDR IP 后面斜杠加子网掩码 无类别域间路由（Classless Inter-Domain Routing、CIDR） 定义网段的几种方式 192.168.1.1/24 192.168.1.0/24 192.168.1.0/255.255.255.0 CIDR prefix CIDR prefix 是子网掩码（subnet mask）中 bit 是 1 的个数 例如: 255.255.255.0 的CIDR prefix是/24 255.255.255.0 => 11111111.11111111.11111111.0 http://blog.csdn.net/hzhsan/article/details/44100215 如: xx.xx.xx.2/24 xx.xx.xx.0/24 通俗一点就是, 斜杠后面的数字就表示子网掩码, 数字具体代表32位子网掩码 (二进制形式) 中前面的"1"的个数。 而且前面的"ip地址"也不一定是一个ip地址, 也可能是一个网络号 (末位是0) 。 通过后面数字可以将前面的网段进一步细划分成具体的子网。 所以 xx.xx.xx.2/24 ——>表示一个ip地址xx.xx.xx.2,24告诉了这个ip地址所对应的子网掩码。 xx.xx.xx.0/24 ——>表示一个网段,并且24告诉了当前具体的子网掩码。 其实这个就是用 CIDR 的形式表示的一个网段,或者说子网。 CIDR: 无类别域间路由选择,Classless and Subnet Address Extensions and Supernetting 我们知道确定一个子网需要知道主机地址和子网掩码,但用CIDR的形式,可以简单得到两个数值。举例说吧,192.168.0.0/24"就表示,这个网段的IP地址从192.168.0.1开始,到192.168.0.254结束 (192.168.0.0和192.168.0.255有特殊含义,不能用作IP地址) ；子网掩码是255.255.255.0。 上面的子网掩码怎么来的呢？其实关键就在"24"上。我们知道IP地址是四个十进制数组成的,相当于32位二进制。用CIDR表示形式,后一个数字将这32位进行了间隔 (以24为例) : 前24位用"1"表示,后面8位用0表示,得到一个二进制数: 11111111 11111111 11111111 00000000。将其转化为十进制,就是: 255.255.255.0了。 例如: 192.168.1.0/24 表示网段是192.168.1.0, 子网掩码是24位, 子网掩码为: 255.255.255.0, 用二进制表示为: 11111111 11111111 11111111 00000000 ,这里为什么是24呢,就是因为子网掩码里面的前面连续的"1"的个数为24个,一定要连续的才行。 ...

socks 采用socks协议的代理服务器就是SOCKS服务器,是一种通用的代理服务器。Socks是个电路级的底层网关,是 DavidKoblas在1990年开发的,此后就一直作为Internet RFC标准的开放标准。Socks不要求应用程序遵循特定的操作系统平台,Socks 代理与应用层代理、 HTTP 层代理不同,Socks代理只是简单地传递数据包,而不必关心是何种应用协议 (比如FTP、HTTP和NNTP请求) 。所以,Socks代理比其他应用层代理要快得多。它通常绑定在代理服务器的1080端口上。 https://baike.baidu.com/item/SOCKS

apache portable run time libraries http://blog.csdn.net/swartz_lubel/article/details/79215764 随着Apache的进一步开 发,Apache组织决定将这些通用的函数独立出来并发展成为一个新的项目。这样,APR的开发就从Apache中独立出来,Apache仅仅是使用 APR而已。目前APR主要还是由Apache使用,不过由于APR的较好的移植性,因此一些需要进行移植的C程序也开始使用APR,开源项目比如 Flood loader(http://httpd.apache.org/test/flood/,该项目用于服务器压力测试,不仅仅适用于Apache)、FreeSwitch(www.freeswitch.org),JXTA-C(http://jxta-c.jxta.org,C版本的JXTA点对点平台实现)；商业的项目则包括Blogline(http://www.bloglines.com/,covalent(http://www.covalent.net、FreeSwitch(www.freeswitch.org),JXTA-C(http://jxta-c.jxta.org,C版本的JXTA点对点平台实现)；商业的项目则包括Blogline(http://www.bloglines.com/,covalent(http://www.covalent.net))等等。 APR使得平台细节的处理进行下移。对于应用程序而言,它们根本就不需要考虑具体的平台,不管是Unix、Linux还是Window,应用程序执行的接口基本都是统一一致的。因此对于APR而言,可移植性和统一的上层接口是其考虑的一个重点。而APR最早的目的并不是如此,它最早只是希望将Apache中用到的所有代码合并为一个通用的代码库,然而这不是一个正确的策略,因此后来APR改变了其目标。有的时候使用公共代码并不是一件好事,比如如何将一个请求映射到线程或者进程是平台相关的,因此仅仅一个公共的代码库并不能完成这种区分。APR的目标则是希望安全合并所有的能够合并的代码而不需要牺牲性能。 APR的最早的一个目标就是为所有的平台(不是部分)提供一个公共的统一操作函数接口,这是一个非常了不起的目的,当然也是不现实的一个目标。我们不可能支持所有平台的所有特征,因此APR目前只能为大多数平台提供所有的APR特性支持,包括Win32、OS/2、BeOS、Darwin、Linux等等。为了能够实现这个目标,APR开发者必须为那些不能运行于所有平台的特性创建了一系列的特征宏(FEATURE MACROS)以在各个平台之间区分这些特征。这些特征宏定义非常简单,通常用APR_HAS_FEATURE参数设置: 如果某个平台具有这个特性,则该宏必须设置为true,比如Linux和window都具有内存映射文件,同时APR提供了内存映射文件的操作接口,因此在这两个平台上,APR_HAS_MMAP宏必须设置,同时ap_mmap__函数应该将磁盘文件映射为内存并返回适当的状态码。如果你的操作系统并不支持内存映射,那么APR_HAS_MMAP必须设置为0,而且所有的ap_mmap__函数也可以不需要定义。第二步就是对于那些在程序中使用了不支持的函数必须提出警告。

systemd script, systemd unit, 启动脚本 service unit 配置文件 template vim /etc/systemd/system/foo.service [Unit] Description=start proxy After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/proxy.sh RemainAfterExit=true [Install] WantedBy=multi-user.target [Unit] # 服务启动时会在 journal 里打印 description0 Description=description0 After=network.target sshd-keygen.service [Service] # 脚本路径必须是绝对路径 /bin/sh 为 shell 解释器不能省 ExecStart=/bin/sh /usr/local/bin/shell-script0.sh Environment="GODEBUG='gctrace=1'" Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd" [Install] WantedBy=multi-user.target # 在哪个服务后面启动 (如依赖的服务) Requires=pulseaudio.service # 在哪个服务后面启动 (如依赖的服务) After=pulseaudio.service [Unit] 启动顺序与依赖关系 After 字段: 表示如果 network.target 或 sshd-keygen.service 需要启动, 那么 foo.service 应该在它们之后启动。 相应地,还有一个 Before 字段, 定义 foo.service 应该在哪些服务之前启动。 注意, After 和 Before 字段只涉及启动顺序,不涉及依赖关系。 ConditionPathExists, AssertPathExists: 要求给定的绝对路径文件已经存在，否则不做任何事(condition)或进入failed状态(assert)，可在路径前使用!表示条件取反，即不存在时才启动服务。 ConditionPathIsDirectory, AssertPathIsDirectory: 如上，路径存在且是目录时启动。 StartLimitIntervalSec=400 StartLimitBurst=3 [Service] 区块 用来 Service 的配置，只有 Service 类型的 Unit 才有这个区块。它的主要字段如下 Type：定义启动时的进程行为。它有以下几种值。 Type=simple：默认值，执行ExecStart指定的命令，启动主进程 Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出 Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行 Type=dbus：当前服务通过D-Bus启动 Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行 Type=idle：若有其他任务执行完毕，当前服务才会运行 ExecStart：服务启动时要执行的命令 ExecStartPre：启动当前服务之前执行的命令 ExecStartPost：启动当前服务之后执行的命令 ExecReload：重启当前服务时执行的命令 ExecStop：停止当前服务时执行的命令 ExecStopPost：停止当其服务之后执行的命令 RestartSec：自动重启当前服务间隔的秒数 Restart：定义何种情况 Systemd 会自动重启当前服务，no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always， 默认值: no TimeoutSec：定义 Systemd 停止当前服务之前等待的秒数 Environment：指定环境变量 EnvironmentFile: 指定文件，可定义多个环境变量，按分行方式存储。 WorkingDirectory, 工作目录, 程序启动时的当前目录。如果使用到 workingdirectory，需要先创建该目录 [Install] 段落相关的指令，它们只在systemctl enable/disable操作时有效。如果期望服务开机自启动，一般只配置一个WantedBy指令，如果不期望服务开机自启动，则Install段落通常省略。主要包含以下内容: WantedBy 本服务设置开机自启动时，在被依赖目标的.wants目录下创建本服务的软链接。例如WantedBy = multi-user.target时，将在/etc/systemd/multi-user.target.wants目录下创建本服务的软链接。 RequiredBy 类似WantedBy，但是是在.requires目录下创建软链接。 Alias 指定创建软链接时链接至本服务配置文件的别名文件。例如reboot.target中配置了Alias=ctrl-alt-del.target，当执行enable时，将创建/etc/systemd/system/ctrl-alt-del.service软链接并指向reboot.target。 DefaultInstance 当是一个模板服务配置文件时(即文件名为Service_Name@.service)，该指令指定该模板的默认实例。例如trojan@.service中配置了DefaultInstall=server时，systemctl enable trojan@.service时将创建名为trojan@server.service的软链接。 可以通过以下两个选项来设置服务启动的频率： ...

netty tcp tls 输出tls握手日志 -Djavax.net.debug=SSL #生成服务端密钥对和证书仓库 keytool -genkey -alias tlsServer -keysize 2048 -validity 365 -keyalg RSA \ -dname "CN=wiloon" -keypass password0 -storepass password0 -keystore server.jks #生成客户端的密钥对和证书仓库, 用于将服务端的证书保存到客户端的授信证书仓库中,命令如下: keytool -genkey -alias tlsClient -keysize 2048 -validity 365 -keyalg RSA \ -dname "CN=localhost" -keypass password0 -storepass password0 -keystore client.jks #导出服务端自签名证书 keytool -export -alias tlsServer -keystore server.jks -storepass password0 -file server.cer # 导出客户端自签名证书 keytool -export -alias tlsClient -keystore client.jks -storepass password0 -file client.cer #将服务端的证书导入到客户端的证书仓库中: keytool -import -trustcacerts -alias tlsServer -file server.cer -storepass password0 -keystore serverTrust.jks keytool -import -trustcacerts -alias tlsClient -file client.cer -storepass password0 -keystore clientTrust.jks http://www.infoq.com/cn/articles/netty-security ...

证书, x509, keystore, truststore, pem 证书和编码 x509 X.509 证书, 其核心是根据 RFC5280 编码或数字签名的数字文档. 实际上，术语 X.509 证书通常指的是 IETF 的 PKIX 证书和 X.509 v3 证书标准的 CRL 文件，即如 RFC 5280 (通常称为 PKIX for Public Key Infrastructure (X.509））中规定的。 X.509 是一种常见通用的证书标准, 主要定义了证书中应该包含哪些内容. 其详情可以参考 RFC5280, TLS/SSL 使用的就是这种证书标准. X.509 是常见通用的证书格式。所有的证书都符合为 Public Key Infrastructure (PKI) 制定的 ITU-T X509 国际标准. X.509 DER 编码 (ASCII) 的后缀是: .DER .CER .CRT X.509 PEM 编码 (Base64) 的后缀是: .PEM .CER .CRT .cer/.crt是用于存放证书,它是2进制形式存放的,不含私钥。 .pem 跟 crt/cer 的区别是它以 Ascii 来表示。 ...

time command 执行命令并计时 【格式】time [-p] command [arguments…] 【说明】 执行命令行"command [arguments…]",命令行执行结束时在标准输出中打印执行该命令行的时间统计结果,其统计结果包含以下数据: 1)实际时间(real time): 从command命令行开始执行到运行终止的消逝时间； 2)用户CPU时间(user CPU time): 命令执行完成花费的用户CPU时间,即命令在用户态中执行时间总和； 3)系统CPU时间(system CPU time): 命令执行完成花费的系统CPU时间,即命令在核心态中执行时间总和。 其中,用户CPU时间和系统CPU时间之和为CPU时间,即命令占用CPU执行的时间总和。实际时间要大于CPU时间,因为Linux是多任务操作系统,往往在执行一条命令时,系统还要处理其它任务。 另一个需要注意的问题是即使每次执行相同命令,但所花费的时间也是不一样,其花费时间是与系统运行相关的。 例1: # time date Sun Mar 26 22:45:34 GMT-8 2006 real 0m0.136s user 0m0.010s sys 0m0.070s 在例1中,执行命令"time date"(见第1行)。系统先执行命令"date",第2行为命令"date"的执行结果。第3-6行为执行命令"date"的时间统计结果,其中第4行"real"为实际时间,第5行"user"为用户CPU时间,第6行"sys"为系统CPU时间。以上三种时间的显示格式均为MMmNN[.FFF]s。 在例1中,CPU时间 = 用户CPU时间 + 系统CPU时间 = 0m0.010s + 0m0.070s = 0m0.080s,实际时间大于CPU时间,说明在date命令运行的同时,还有其它任务在运行。 【参数说明】 -p 以POSIX缺省的时间格式打印时间统计结果,单位为秒。详细的输出格式见例2。 例2: # time -p date Wed Mar 27 00:33:11 GMT-8 2006 real 0.11 user 0.00 sys 0.02 在例2中,同样执行命令"time date"(见第1行)。系统先执行命令 “date”,第2行为该命令的执行结果。第3-5行为执行命令"date"的时间统计结果。注意本例的时间格式与例1中的时间格式差别,使用-p 参数后的时间显示格式为NN.FF,其单位为秒。 ...

bios boot partition https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/zh-cn (parted)mkpart primary 1 3 (parted)name 1 grub (parted)set 1 bios_grub on (parted)print https://www.cnblogs.com/f-ck-need-u/p/7084627.html BIOS boot partition是一个分区,gnu grub[译注1]用它来引导基于legacy bios但启动设备上却包含GPT格式分区表时的操作系统。这种结构有时候被称为BIOS/GPT启动[译注2]。 下图非原文内容,是本人提供,用于直观地感受bios boot分区。 Bios boot分区是必要的,因为GPT使用紧跟在MBR后面的扇区来保存实际的分区表,但在传统的MBR分区架构中,这些扇区并没有特殊的作用,这样的结果是没有足够的可用空闲空间来存储stage2这段boot loader。MBR中也存储了boot loader,但MBR无法存储超过512字节的内容,所以MBR中的这段boot loader被当作stage1使用,它的主要作用是加载功能更多更复杂的stage2这段boot loader,stage2可以从文件系统读取和载入操作系统内核。 当使用了BIOS boot分区,该分区将包含stage2的boot loader程序,例如grub2文件,而stage1的boot loader代码仍保留在MBR中。使用bios boot分区不是解决基于传统bios但使用了gpt格式磁盘问题的唯一方法,但是复杂的boot loader如grub2无法将无法完全符合MBR中的398-446字节的区域,因此它们需要一个辅助的存储空间。在MBR磁盘上,一般使用紧跟在MBR后的扇区空间来存储这些复杂的boot loader,这些扇区空间就是大众所熟知的"MBR gap"。而在GPT磁盘上,由于没有与MBR gap等效的未使用空间,所以单独使用一个bios boot分区来分配这样的空间,以存储复杂的boot loader。 BIOS boot分区的GUID可以是"21686148-6449-6E6F-744E-656564454649"。在基于BIOS的平台下的GPT中,BIOS boot分区有点类似于EFI平台下的EFI系统分区,EFI系统分区使用UEFI保存文件系统和文件,而用于BIOS平台的BIOS boot分区则不使用文件系统来保存代码(见上面的图,在bios boot分区上是没有创建文件系统的)。 bios boot分区的大小非常小,可以小到只有31kB(由于第一个扇区是mbr,所以bios boot的内容从第2扇区到第63扇区),但是由于未来boot loader可能会扩展,所以建议bios boot分区设置为1M大小,而且很多磁盘分区工具都使用1MB分区对齐策略,这样MBR到第一个分区之间会保留一些空闲空间。 在Example 2中,grub 2在bios boot分区中存储它的core.img。 [译注1]gnu grub: 现在使用的grub都是gnu山寨出来的grub,原始的grub早已消失在历史中。 [译注2]: 也就是bios MBR和gpt混用的模式。 转载请注明出处: http://www.cnblogs.com/f-ck-need-u/p/7084627.html

linux 查看分区表类型 You can use parted -l to determine the type of partition table. Eg: $ sudo parted -l Model: ATA TOSHIBA THNSNS25 (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 4194kB 32.2GB 32.2GB primary ext4 boot 2 32.2GB 256GB 224GB primary ext4 https://unix.stackexchange.com/questions/120221/gpt-or-mbr-how-do-i-know

redis info instantaneous_input_kbps 每秒读字节数 instantaneous_ops_per_sec 每秒处理指令数 instantaneous_output_kbps 每秒写字节数 keyspace_hitrate Rate of successful lookup of keys in the main dictionary keyspace_hits : 查找数据库键成功的次数。 keyspace_misses : 查找数据库键失败的次数。 latest_fork_usec : 最近一次 fork() 操作耗费的毫秒数。 lru_clock : 以分钟为单位进行自增的时钟,用于 LRU 管理 master_repl_offset The replication offset of master (in ms) mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率 migrate_cached_sockets Current amount of cached sockets rdb_changes_since_last_save : 距离最近一次成功创建持久化文件之后,经过了多少秒。

ssh config, sshd config ssh config public key, authorized_keys vim ~/.ssh/authorized_keys ~/.ssh/config https://linux.die.net/man/5/ssh_config https://www.openssh.com/legacy.html Host foo Hostname remote.server.com IdentityFile ~/.ssh/id_rsa.github IdentitiesOnly yes port 22 host 这一项 ssh config 的别名, 在命令行里可以直接 ssh foo hostname 远程主机的主机名或 ip IdentityFile 私钥路径 IdentitiesOnly, yes: ssh 连接时只使用 IdentityFile 配置的私钥, 忽略 ssh agent 提供的私钥 KexAlgorithms, the key exchange methods that are used to generate per-connection keys The IdentitiesOnly yes is required to prevent the SSH default behavior of sending the identity file matching the default filename for each protocol. If you have a file named ~/.ssh/id_rsa that will get tried BEFORE your ~/.ssh/id_rsa.github without this option. ...

Java tls, JSSE Java JSSE Java Secure Socket Extension JDK 中的 JSSE (javax.net.ssl) ,提供了对 SSL 和 TLS 的支持 SSL/TLS 协议 (RFC2246 RFC4346) 处于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。 SSL/TLS 记录协议 (SSL/TLS Record Protocol) ,它建立在可靠的传输层协议 (如 TCP) 之上,为上层协议提供数据封装、压缩、加密等基本功能。 SSL/TLS 握手协议 (SSL/TLS Handshake Protocol) ,它建立在 SSL/TLS 记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等初始化协商功能。 从协议使用方式来看,又可以分成两种类型: SSL/TLS 单向认证,就是用户到服务器之间只存在单方面的认证,即客户端会认证服务器端身份,而服务器端不会去对客户端身份进行验证。 2.SSL/TLS 双向认证,就是双方都会互相认证,也就是两者之间将会交换证书。基本的过程和单向认证完全一样,只是在协商阶段多了几个步骤. 对称算法 (symmetric cryptography) : 就是需要双方使用一样的 key 来加密解密消息算法,常用密钥算法有 Data Encryption Standard (DES) 、triple-strength DES (3DES) 、Rivest Cipher 2 (RC2) 和 Rivest Cipher 4 (RC4) 。因为对称算法效率相对较高,因此 SSL 会话中的敏感数据都用通过密钥算法加密。 ...