centos 升级 jdk，centos现在哪个版本最流行
很多朋友对于centos 升级 jdk和centos现在哪个版本最流行不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
CentOS 7 下Tomcat启动超慢的原因及解决方案
CentOS 7系统中安装好openjdk和Tomcat后，启动过程很慢，长达数分钟，日志如下：
tomcat启动耗时278084ms折合278秒，对于刚刚安装的干净tomcat，这肯定是不对劲的。
其中有一条日志引起了笔者的注意：
显然tomcat执行到这里时出问题了，google了一下，经过一番搜索明白了其中的缘由。
在tomcat官方wiki文档的 HowToFasterStartUp章节中，Entropy Source部分有一段这样的说明：
从这里我们得知Tocmat的Session ID是通过SHA1PRNG算法计算得到的，计算Session ID的时候必须有一个密钥，为了提高安全性Tomcat在启动的时候会通过随机生成一个密钥，它强依赖于获取熵池中的随机数来进行创建。
那么什么是/dev/random？什么是熵池？
/dev/random
从维基百科得知，在UNIX操作系统（包括类UNIX系统）中，/dev/random是一个特殊的设备文件，可以用作随机数生成器或伪随机数生成器。
Linux内核中的是第一个以背景噪声产生真正的随机数产生的实现，它允许程序访问来自设备驱动程序或其它来源的背景噪声。
Linux上有两个通用的随机设备：/dev/random和/dev/urandom。其中/dev/random的随机性最好，因为它是一个阻塞的设备。而/dev/random的一个副本是/dev/urandom（“unblocked”，非阻塞的随机数生成器），它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞，但其输出的熵可能小于/dev/random的。所以它可以作为生成较低强度密码的伪随机数生成器，不建议用于生成高强度长期密码。
熵池
熵池本质上是若干字节，/proc/sys/kernel/random/entropy_avail中存储了熵池现在的大小，/proc/sys/kernel/random/poolsize是熵池的最大容量，单位都是bit。如果 entropy_avail的值小于要产生的随机数bit数，那么/dev/random就会堵塞。
为什么熵池不够用？
熵池实际上是从各种noice source中获取数据，noice source可能是键盘事件、鼠标事件、设备时钟中等。linux内核从2.4升级到2.6时，处于安全性的考虑，废弃了一些source。source减少了，熵池补给的速度当然也变慢，进而不够用。
其实，通过消耗熵池，可以构造DDOS攻击。原理很简单，熵池空了，依赖随机数的业务（SSL，加密等）就不能正常进行。
通过以上信息，笔者得知该问题是由于熵池不足导致的。怎么解决？
使用非阻塞性的生成器/dev/urandom代替/dev/random。
1、可在JVM环境中配置
通过配置发生器指定熵收集守护进程
修改$JAVA_PATH/jre/lib/security/java.security中参数 securerandom.source为：
2、也可在Tomcat环境中配置
通过配置JRE使用非阻塞的Entropy Source获取熵
在$TOMCAT_HOME/bin/catalina.sh中加入：
这个系统属性egd表示熵收集守护进程(entropy gathering daemon)。
1、[硬件随机数生成器]安装并使用rng-tools作为额外的熵随机数生成器（推荐）
cat/dev/random命令会消耗熵池， rngd守护进程会补充熵池，可使用如下命令来测试随机数生成的情况：
2、[软件随机数生成器]在rng-tools仍不满足的情况下，可使用haveged作为额外的熵随机数生成器
要检查是否需要 Haveged，可使用下面命令查看当前收集到的熵：
如果结果比较低(<1000)，建议安装 haveged，否则加密程序会处于等待状态，直到系统有足够的熵。
安装 haveged之后，可以再次查看系统熵看下有无提升。
因为方法一存在一定的不安全性，且需要对环境进行配置，为了满足熵的需要，这里笔者选择了第二种方法，使用rng-tools作为额外的熵随机数生成器，同以上操作后顺利解决了问题。
操作后重启tomcat日志如下，启动速度快了两个数量级：
参考文档：
服务器操作系统应该选择 Debian/Ubuntu 还是 CentOS
著作权归作者所有。
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：彭勇
链接：
来源：知乎
早期，我们使用 Debian作为服务器软件，后来转向了CentOS，主要原因如下：
1、CentOS/RHEL的生命周期是7年，基本上可以覆盖硬件的生命周期，也就意味着一个新硬件安装以后，不用再次安装操作系统。要知道重新折腾一个生产机是很麻烦而且有风险的事情。
[2012.2.1]今天刚刚收到红帽子的通知邮件，RedHat 5, RedHat 6的生命周期，延长到10年，太牛叉了。这个对企业用户很重要。
而Debian的生命周期是不固定的，一般新版本发布以后，上个版本再维护18个月。而Debian的版本发布时间间隔不稳定，经常会延期。综合起来一个版本的生命周期一般在3～4年。
[2014.4.24]Debian宣布对Squeeze(6.0)，提供5年的LTS长期支持。
Ubuntu的LTS版生命周期是5年。
如果你选用了 Debian或者 Ubuntu作为服务器，等生命周期过了以后，就没有安全补丁，你的服务器就会裸奔或者需要重新安装系统。
2、RedHat是一个值得尊敬的开源公司，长期以来Linux内核RedHat的贡献程度都是最多的。可以这么说，如果一个Linux方面的问题，RedHat搞不定，那么也很少有其他公司可以搞定了。公司有一批Linux内核方面的如雷贯耳的大牛，比如：
Alan Cox- Core developer, numerous contributions
Ingo Molnar- x86 subsystem maintainer
Al Viro- VFS subsystem maintainer, linux内核贡献第二多的个人
David Miller- Sparc Port maintainer, linux网络部分开发者， linux内核贡献最多的个人
Jeff Garzik- Sata subsystem maintainer
John Linville- Wireless subsystem maintainer
Stephen Tweedie- Ext3 filesystem developer
Eric Sandeen- XFS, Ext4 filesystem developer
Josef Bacik- Btrfs filesystem developer
Rik Van Riel- VM developer
Ric Wheeler- Filesystem developer
Val Henson- Filesystem developer
Dave Jones- Fedora kernel maintainer
Kyle McMartin- Fedora kernel maintainer
Chuck Ebbert- Fedora kernel maintainer
Eric Paris- LSM/SELinux/Audit/Capabilities maintainer
Eugene Teo- Security Response
Kay Sievers- Hotplug
3、CentOS/RHEL对硬件的支持很好，主流硬件厂商早就将服务器拿过去测试，一般不存在硬件的兼容性问题。
而Debian就麻烦了，由于有版权上的考虑和代码纯洁性上的洁癖，一些硬件驱动和软件被删掉了，导致安装过程有问题。比如 Dell服务器上，大量使用的网卡 BroadCom，就驱动不了，安装了以后，网络起不来。
4、大量商业软件，比如 Oracle，都是针对 Redhat认证的，有大量的帮助文档和使用说明，有良好的技术支持。出了问题，也容易在网上找到类似的答案和经验。
5、CentOS是RedHat的克隆版，如果需要可以随时平滑切换到 RedHat，从而享受RedHat的服务支持。要知道厂商的服务，是最后一道防火墙，如果你给一个大客户做方案，他们一般会倾向选用商业服务。万一出了什么问题，还有Redhat可以求助，或者有一个RedHat可以承担责任:-)
6、如果你是一个工程师，熟悉了 CentOS/RedHat，找工作更加容易。如果你是一个企业老板，相对也容易招聘到熟悉CentOS/RedHat的工程师。RHCE的培训，也相对较完善，认同程度高。
7、CentOS/RHEL的批量安装更加方便
在机房，使用kickstart+ PXE安装，给客户，使用定制的kickstart光盘，一键安装，一般在5分钟左右就可以安装完。
上述3，4，5，6几点中，都说明CentOS/RHEL相对于其他Linux操作系统，有相对完整的生态环境，很多公司在CentOS/RHEL投入了大量资源，积累了大量经验，绑定了自己的利益，这个是CentOS/RHEL得以长期良好发展的保证。
=============
补充对评论的一些回复
1.所谓的“centos稳定性非常差”，不知道你指的是什么？能否举一些CentOS不稳定的例子？至少我们用了这么多年CentOS，稳定性上可以说是坚如磐石的。如果是你说的由于yum升级造成的混乱，那只能说明你对centos不熟悉。
2、RHEL/centos对于一些新的软件的支持，采用 SCL的方式支持，比如ruby193，python27, python 33, PHP 54, nodejs 0.10, mariadb55, postgresql 9.2
AdditionalResources/Repositories/SCL
3、debian/ubuntu同样存在版本稳定和程序太老的矛盾，比如他们的LTS版本，一般是两年多更新一次。squeeze是2011年2月发布，wheezy是2013年5月发布，如果你在2013年4月使用Debian，你会发觉好多软件太老，比如：
内核：2.6.32，和Centos 6一样的
glibc还是使用的2.11.2
mysql使用的5.1.49
openjdk使用的是 6
php使用的是 5.3.3
python使用的是2.6.6
下一个版本的Deiban，至少要到 2015年下半年才能发布，而RHEL7/CentOS7的正式版发布在即，里面用到的不少软件，都比wheezy的要新。按照你的逻辑，在接下来较长的时间里，是否CentOS比起Debian更加前卫？
再看看Rio的回复：“之前我用了很长一段时间的 Debian，但它的更新实在太慢了（好几年啊有木有！）”，呵呵
4、“debian的支持时间也非常长期”，这个最近确实有了改善，Debian刚刚宣布对 Debian 6.0有了5年的LTS长期支持。可以这么说，Debian也看到了LTS的重要性，向CentOS学习了一把。
Debian-- News-- Long term support for Debian 6.0 Announced
但Debian做得还不够，因为Debian的LTS在后续版本，比如 Debian 7(wheezy)， Debian 8(jessie)里的支持政策还不明朗：
Debian-- Security Information-- DSA-2907-1
Debian的LTS支持，也不是Debian官方安全团队维护的，而是由其他志愿者维护的，工作效率和质量是否有保证还不知道。相比RHEL明晰的发展策略和安全更新策略，有10年的安全补丁保证，还有不少差距。
5、“debian这个系列的软件包也比较新，debian和他儿子ubuntu很多软件包维护是共享的，更新速度非常快”，不知道你使用的是稳定版还是测试版。稳定版里面你是如何看到软件包“更新速度非常快”的。
centos7下部署jenkins+jdk8+适配插件下载
在CentOS 7环境中，部署Jenkins 2.289.3版本并配置适配JDK 1.8版本的插件下载，我们面临一个挑战。默认情况下，jenkins要求使用JDK 11及以上版本，但这与我们强制使用JDK 1.8的需求不符。为了解决这个问题，我们需要调整jenkins的自动更新设置，以便在JDK 1.8的限制下安装插件。
首先，从官方下载jenkins.war包，地址为：jenkins下载地址。下载后将其上传到服务器的部署目录，如我的jenkins安装在app目录下。确保以admin用户权限对war包进行操作。
接着，进入jenkins安装目录并使用以下命令启动jenkins：
使用--httpPort指定端口，如8080（默认值）;
如果需要，--prefix设置访问根路径，但这里可能需要解决初始登录跳转问题，所以未设置。
然而，当尝试安装插件时，由于jenkins版本限制，我们收到提示，需要更高版本的jenkins。为解决这个问题，我们需调整插件下载设置：
避免首次登录时自动安装插件，这可以通过修改default.json文件实现。首先，使用sudo find命令定位default.json文件，然后备份原始文件，并从适合JDK 1.8的镜像源（如清华镜像链接）复制相应json内容替换。
在Jenkins管理界面，进入插件管理的高级选项，将Update Site更改为国内的插件仓库地址。
重启jenkins，重新登录后，你将能够正常下载JDK 1.8兼容的插件，而无需升级jenkins版本。
通过这些步骤，我们成功地在JDK 1.8环境中部署并管理了Jenkins，确保了插件的正常安装。
