Java9 – new features

  • More Module System, e.g.  self-describing collection of code and data
    • Using jlink, to introduce a new optional phase, link time, which is in-between compile time and run time, during which a set of modules can be assembled and optimized into a custom runtime image
    • The modular JAR file with module-info.class file in its root directory.
    • Using jmod tool, the New JMOD format can be created. (new packaging format similar to JAR)
  • New version schema ($MAJOR.$MINOR.$SECURITY.$PATCH)
  • java shell: jshell
  • Compile for old java version (6 – java6)
    javac -source 6 -target 6 HelloWorld.java
  • More Diagnostic Commands: jcmd (jcmd pid help command)
  • Multi-Release JAR Files: Extends the JAR file format to enable multiple, Java release-specific versions of class files to coexist in a single archive
  • Removes the hprof, jhat from the JDK
  • More Security: DTLS, TLS,  disable X.509 certificate chains with SHA-1-based signatures,  PKCS12 keystores by default, SHA-3 cryptographic hash functions
  • The Garbage-First Garbage Collector (G1 GC) is the default garbage collector in JDK 9.
  • JavaDB, which was a rebranding of Apache Derby, isn’t included in JDK 9.
  • The launchers java-rmi.exe from Windows and java-rmi.cgi from Linux and Solaris have been removed.
  • In JDK 9, the Windows 32–bit client VM is not available. Only a server VM is offered.
  • Java VisualVM isn’t bundled with JDK 9.
  • The AppleScript engine is removed in JDK 9.

Windows Registry Key Changes

The Java 9 installer creates these Windows registry keys when installing the JRE:

  • “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE”
  • “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE\9”

The Java 8u152 installer creates these Windows registry keys when installing the JRE:

  • “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment”
  • “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8”
  • “HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_152”
Advertisements

CentOS 7.4 is released

CentOS-7 (1708) – 7.4 is released

centos
CentOS 7.4 (1708)

Some known issues:

  • ip6tables where the iptables service fails to start - apply the fix:  iptables-1.4.21-18.0.1.el7
    https://bugzilla.redhat.com/show_bug.cgi?id=1477413
  • The version of libgpod in EPEL repository is different in CentOS 7.4, workaround:
    yum downgrade libgpod.
  • Use VirtualBox 5.1.28 or later in CentOS 7.4. (old version is not fully compatible in CentOS 7.4
  • From RHEL/CentOS7.4, the size of the /boot partition changed to be minimum 1GB, because of significant increase of the initramfs.
  • Samba problem, apply the workaround: krb5-libs-1.15.1-8.el7
    Except in this case:
    Samba share with sssd authentication is broken. A workaround is to downgrade the samba packages to an earlier version.
  • At least 1024 MB RAM is required is for CentOS 7.4, Use at least 1344 MB RAM, for the installation of LiveGNOME/LiveKDE.
  • The screen resolution is 800×600 or superior.
  • Changed icon size if necessary with the workaround:
    gsettings set org.gnome.nautilus.icon-view default-zoom-level ‘small’

Upgrade problem:

  • For users of openldap-servers with ppolicy, before the upgrade, check this: https://bugs.centos.org/view.php?id=13750
  • For users need rdma, do this before upgrade: yum install rdma-core && yum update
  • Gnome is too dark colours, workaround: yum reinstall vte291

For VMs:

  • VMware Workstation/VMware ESXi (SCSI adapters: BusLogic and LsiLogic)
    The default kernel from CentOS 7 does not include the corresponding driver, e.g
    an unbootable system if you install on a SCSI disk using the defaults for CentOS
    workaround: Select “Red Hat Enterprise Linux” and “paravirtualized SCSI adapter”.
  • CentOS-7 as a Xen domU in ParaVirtualization (PV) mode, an upgrade to CentOS-7 (1708) will cause the VM to not be able to boot.
    workaround: Use HVM (full emulation) or PV-on-HVM mode

 

CVE-2017-7494 – Samba 漏洞

漏洞警报(CVE-2017-7494)

All versions of Samba from 3.5.0 onwards are vulnerable to a remote
code execution vulnerability, allowing a malicious client to upload a
shared library to a writable share, and then cause the server to load
and execute it.

Manual fix/Workaround

Add the parameter:
nt pipe support = no

to the [global] section of your smb.conf and restart smbd. This
prevents clients from accessing any named pipe endpoints. Note this
can disable some expected functionality for Windows clients.