# rm-rf.es | Administración de sistemas

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

Missing required Permissions Manifest SecurityException en Java

A partir de Java 7 Update 51 se han ampliado las medidas de seguridad para hacer menos vulnerables los sistemas antes amenazas externas. Los errores principales que nos podemos encontrar al ejecutar una aplicación Java desde el navegador son los siguientes:

Missing required Permissions manifest attribute in main jar

Missing Application-Name manifest attribute

Java applications are blocked by your security settings

Java no permite a los usuarios ejecutar aplicaciones no firmadas o firmadas por una autoridad no verificada (el típico certificado self-signed) así como aquellas que no tienen configuradas los atributos de permisos correspondientes.

Si conocemos los riesgos, o se trata de una aplicación propia o conocida, podemos aplicar un workaround para saltarnos estas medidas de seguridad en un website concreto y así evitar los errores anteriormente mencionados. Se trata de añadir la URL de la aplicación bloqueada en la lista de excepciones de seguridad en el panel de control de Java:

  1. Acceder al panel de control de java (en Windows -> Inicio -> Configurar JAVA.
  2. Click en la pestaña de seguridad.
  3. Click en Editar lista de sitios.
  4. Añadir la URL como excepción.
Java Security Settings

sFTP server: conectar con Filezilla

Una entrada rápida para explicar cómo conectar a un servidor sFTP a través del cliente Filezilla.

  1. Abrir Filezilla
  2. Establecer una conexión rápida indicando el host, usuario, password y puerto de conexión. El único punto que puede llevar a confusión aquí es el puerto de conexión. Al ser una conexión sFTP tenemos que configurar el puerto por el cual esté escuchando el servicio SSH en el servidor.  Por defecto es el puerto TCP 22.
    sFTP  server Filezilla
  3. Una vez configurados los datos, establecemos la conexión pinchando en “Conexión rápida” o “Quick Connect“.
  4. Si es la primera vez que conectamos al sFTP Server, nos pedirá autorizar y guardar el fingerprint del servidor.
    sFTP  server Filezilla
  5. Si todo ha ido bien, la conexión se establecerá. En la ventana de estado y log veréis la cadena de conexión y como se ha establecido correctamente:
    Status:	Connecting to 192.168.1.129...
    Response:	fzSftp started
    Command:	open "alex@192.168.1.129" 22
    Command:	Trust new Hostkey: Once
    Command:	Pass: *********
    Status:	Connected to 192.168.1.129
    Status:	Retrieving directory listing...
    Command:	pwd
    Response:	Current directory is: "/home/alex"
    Command:	ls
    Status:	Listing directory /home/alex
    Status:	Calculating timezone offset of server...
    Command:	mtime ".VirtualBox"
    Response:	1408651609
    Status:	Timezone offsets: Server: 7200 seconds. Local: 7200 seconds. Difference: 0 seconds.
    Status:	Directory listing successful

RedHat Cluster: comandos básicos

redhat logoEstos son los comandos básicos para controlar un RedHat Cluster (RHCS) desde línea de comandos. Ver el estado del Cluster, modificar y replicar configuraciones, arrancar/parar/reiniciar/mover recursos y servicios, etc.

Ver el estado del Cluster

El comando clustat permite ver el estado del cluster. Se ejecuta como root y muestra los nodos activos del cluster, el estado general del cluster, si hay quorum y el estado de los servicios junto con el nodo en el que se están ejecutando:

# clustat

Cluster Status for clstr-app @ Tue Jul 29 01:23:53 2014

Member Status: Quorate

 Member Name                                   ID   Status
 ------ ----                                   ---- ------
 nodo1                                         1 Online, Local, rgmanager
 nodo2                                         2 Online, rgmanager
 /dev/block/8:32                               0 Online, Quorum Disk

 Service Name                Owner (Last)          State
 ------- ----                ----- ------          -----

 service:ftpd                nodo1                 started
 service:httpd               nodo2                 started

Modificar, verificar y replicar configuración

Los pasos para realizar un cambio en la configuración del cluster (archivo /etc/cluster/cluster.conf) son los siguientes:

Aumentar el número de versión:

<cluster config_version="2" name="clstr-app">

Validar la configuración para descartar errores:

# ccs_config_validate

Y replicar al resto de nodos:

# cman_tool version -r

Iniciar, parar y reiniciar servicios

Para controlar los servicios del cluster usamos el comando clusvcadm:

Iniciar un servicio:

# clusvcadm -e httpd

Local machine trying to enable service:httpd...Success
service:httpd is now running on nodo1

Parar un servicio:

# clusvcadm -d httpd

Local machine disabling service:httpd...Success

Reiniciar un servicio:

# clusvcadm -R httpd

Mover un servicio a otro nodo del Cluster

También con el comando clusvcadm, lo que hace es parar el servicio en el nodo activo y arrancarlo en el nodo de destino. Por ejemplo, para mover al “nodo2″ el servicio httpd:

# clusvcadm -r httpd -m nodo2

Member nodo1 trying to enable service:httpd...Success
service:httpd is now running on nodo2

Arrancar y parar el cluster de forma ordenada

Para sacar un nodo del cluster, lo primero que hacemos es mover todos los servicios que tenga activos a otro nodo del cluster y después parar por orden los procesos correspondientes:

# clusvcadm -r INSTANCIA -m NODO # Mover todas las instancias que estén corriendo al otro nodo
# service rgmanager stop # Paramos el gestor de recursos
# service gfs2 stop # paramos GFS si usamos estos FS
# service clvmd stop # Paramos LVM en cluster)
# service cman stop # paramos cman

Y para añadir un nodo al cluster, sería a la inversa:

# service cman start
# service clvmd start
# service gfs2 start
# service rgmanager start

Con estos comandos básicos podéis gestionar de forma eficiente la RHCS (Red Hat Cluster Suite) desde línea de comandos.

Tomcat Manager: usuario, contraseña y accesibilidad

Si en un servidor de aplicaciones Tomcat hacemos uso del Manager Webapp, lo primero que debemos tener en cuenta es su securización, y aquí entran dos factores, el usuario y contraseña que utilicemos para acceder (gestión de roles) y desde donde permitimos el acceso.

Por defecto el rol de admin para el Manager está deshabilitado. El archivo donde se encuentran todos los roles es “tomcat_users.xml“:

/usr/share/tomcat/conf/tomcat_users.xml

<!-- <user name="admin" 
password="adminadmin" roles="admin,manager,admin-gui,admin-script,manager-gui,manager-script,manager-jmx,manager-status" /> -->

Como podéis ver, está comentado. Así que lo primero que tendríamos que hacer es crear un nuevo usuario con los roles que queramos asignar. En el ejemplo anterior tiene todos los necesario pero se puede afinar según requerimientos. Por ejemplo:

<user name="foo" password="foo_password" roles="manager-gui" />

Con esto ya tenemos el usuario. Ahora lo importante es bloquear el acceso al Manager desde cualquier ubicación a excepción de las redes que nosotros indiquemos. Lo óptimo sería habilitarlo únicamente para conexiones locales (localhost) y acceder al Manager por un tunel SSH.

Para configurar las redes permitidas tenemos el archivo context.xml dentro del directorio META-INF de la aplicación y la Valve RemoteAddrValve:

/var/lib/tomcat/webapps/manager/META-INF/context.xml

Podemos descomentar la configuración por defecto que limita el acceso a localhost:

<Context antiResourceLocking="false" privileged="true" >
<!--
Remove the comment markers from around the Valve below to limit access to
the manager application to clients connecting from localhost
-->
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
</Context>

También podríamos añadir segmentos privados:

<Context antiResourceLocking="false" privileged="true" >
<!--
Remove the comment markers from around the Valve below to limit access to
the manager application to clients connecting from localhost
-->
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|192\.168\.1\.d+" />
</Context>

Con estos tips, vuestro Tomcat Manager estará más securizado.

Telnet en Linux: forzar IP de origen

En un sistema Linux con varias interfaces de red o múltiples IPs, es posible que en algún momento sea necesario hacer pruebas de Telnet pero forzando que la IP de origen sea una concreta.

Para hacerlo, simplemente tenemos que especificar el parámetro “-b” seguido de la IP de origen que queremos utilizar, ejemplos:

IP de origen: 192.168.1.129:

$ telnet -b 192.168.1.129 74.125.203.27 25
Trying 74.125.203.27...
Connected to 74.125.203.27.
Escape character is '^]'.
220 mx.google.com ESMTP bi3si705006pbc.144 - gsmtp
quit

Comprobación de la conexión establecida con un NETSTAT:

tcp  0    0 192.168.1.129:48726     74.125.203.27:25     ESTABLISHED 4054/telnet

IP de origen: 192.168.1.199:

$ telnet -b 192.168.1.199 74.125.203.27 25
Trying 74.125.203.27...
Connected to 74.125.203.27.
Escape character is '^]'.
220 mx.google.com ESMTP jb8si847395pbd.78 - gsmtp

Comprobación de la conexión establecida con un NETSTAT:

tcp 0    0 192.168.1.199:54860  74.125.203.27:25  ESTABLISHED 3976/telnet

Configurar interfaces de red como “eth” en CentOS 7 y RHEL 7

En el anterior artículo hemos visto como configurar la red en CentOS 7 y RHEL 7. Una de las cosas que comentaba es que la nomenclatura de las interfaces de red ha cambiado de eth0, eth1, ethN a por ejemplo, enp0s3,enp0s4…:

Como podéis ver en la salida del comando ip addr list, las interfaces de red ya no se llaman eth0,eth1,ethN. Este es el otro gran cambio en esta nueva versión. Este cambio (Predictable Network Interface Names) pretende asignar identificadores estables a las interfaces de red basándose en el tipo (local Ethernet, WLAN, WWAN…) y evitar los problemas de la nomenclatura clásica. Si os interesa profundizar en el tema recomiendo leer la documentación al respecto. Básicamente tenemos:

Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)

Muestra:

# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:99:f6:7a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.199/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe99:f67a/64 scope link 
       valid_lft forever preferred_lft forever

¿Cómo podemos volver a la nomenclatura anterior? Sinceramente, no veo el motivo ni que tenga beneficios excepto la comodidad de que es lo conocido y con lo que llevamos trabajando años y años. No obstante, cuanto antes nos acostumbremos al nuevo método, mejor.

Si aún así quieres cambiarlo, estos son los pasos:

  1. Modificar la línea de arranque de Kernel en el grub y añadir los siguientes argumentos:
    net.ifnames=0 biosdevname=0

    Por ejemplo:

    linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=3569ac5d-58a2-479b-b6a9-967bb66adf7e ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=es rd.lvm.lv=centos/root crashkernel=auto LANG=en_US.UTF-8 net.ifnames=0 biosdevname=0
  2. Modificar los nombres de los ficheros de interfaces en /etc/sysconfig/network-scripts/ y las referencias internas:
    # ls -l /etc/sysconfig/network-scripts/ifcfg-*
    -rw-r--r--. 1 root root 368 ago 24 10:15 /etc/sysconfig/network-scripts/ifcfg-enp0s3
    
    # grep NAME /etc/sysconfig/network-scripts/ifcfg-*
    /etc/sysconfig/network-scripts/ifcfg-enp0s3:NAME="enp0s3"
    

Repito que personalmente no lo recomiendo. ¡Ahí queda eso!

Configurar red en CentOS 7 | RHEL 7

En esta entrada vamos a aprender a configurar las interfaces de red en el sistema operativo GNU/Linux CentOS 7, lo mismo servirá para RHEL 7 ya que es exactamente igual.

¿Qué es lo que cambia respecto a la configuración de red de versiones anteriores de CentOS y Red Hat? Vamos a ir viéndolo.

Lo primero que os llamará la atención, aunque es algo que se sabía desde versiones anteriores es la desaparición del comando ifconfig para la estandarización completa del comando ip:

[root@localhost ~]# ifconfig
-bash: ifconfig: command not found

[root@localhost ~]# whereis ifconfig
ifconfig:

Para los que todavía no sepáis usar bien el comando IP, hace ya dos años (como pasa el tiempo) que hice un tutorial de uso comparando comandos de ip e ifconfig:

Cómo usar el comando ip en Linux (ejemplos vs ifconfig)

# ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:99:f6:7a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.130/24 brd 192.168.1.255 scope global dynamic enp0s3
       valid_lft 258471sec preferred_lft 258471sec
    inet6 fe80::a00:27ff:fe99:f67a/64 scope link 
       valid_lft forever preferred_lft forever

Nomenclatura de interfaces de red

Como podéis ver en la salida del comando ip addr list, las interfaces de red ya no se llaman eth0,eth1,ethN. Este es el otro gran cambio en esta nueva versión. Este cambio (Predictable Network Interface Names) pretende asignar identificadores estables a las interfaces de red basándose en el tipo (local Ethernet, WLAN, WWAN…) y evitar los problemas de la nomenclatura clásica. Si os interesa profundizar en el tema recomiendo leer la documentación al respecto. Básicamente tenemos:

Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)

¿Qué pasa si quiero volver a la nomenclatura anterior? Aquí la respuesta:

Configurar interfaces de red como “eth” en CentOS 7 y RHEL 7

Configuración manual de interfaces de red

La configuración manual sigue siendo exactamente igual que en versiones anteriores. Los ficheros que contienen la configuración de cada interfaz de red se encuentran en:

# ls -l /etc/sysconfig/network-scripts/ifcfg-*
-rw-r--r--. 1 root root 321 ago 22 23:54 /etc/sysconfig/network-scripts/ifcfg-enp0s3
-rw-r--r--. 1 root root 254 abr  2 17:30 /etc/sysconfig/network-scripts/ifcfg-lo

Sólo hay que editar el de la interfaz correspondiente y modificar según requerimientos:

Configuración IP dinámica DHCP

# cat /etc/sysconfig/network-scripts/ifcfg-enp0s3
HWADDR="08:00:27:99:F6:7A"
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="30d5594c-d4db-4f2d-bc0d-91ffd2571035"
ONBOOT="yes"

Configuración IP estática

# cat /etc/sysconfig/network-scripts/ifcfg-enp0s3
HWADDR="08:00:27:99:F6:7A"
TYPE="Ethernet"
BOOTPROTO="static"
IPADDR="192.168.1.199"
NETMASK="255.255.255.0"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="30d5594c-d4db-4f2d-bc0d-91ffd2571035"
ONBOOT="yes"

Reiniciar red

Para aplicar los cambios hay que reiniciar el servicio de red (Arrancar / Parar / Reiniciar servicios en RHEL 7 y CentOS 7):

# systemctl restart network.service

Y para ver el estado:

# systemctl status network.service
network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: active (exited) since dom 2014-08-24 10:16:49 CEST; 3s ago
  Process: 11002 ExecStop=/etc/rc.d/init.d/network stop (code=exited, status=0/SUCCESS)
  Process: 11169 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)

ago 24 10:16:48 localhost.localdomain systemd[1]: Starting LSB: Bring up/down networking...
ago 24 10:16:48 localhost.localdomain network[11169]: Bringing up loopback interface:  Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 24 10:16:48 localhost.localdomain network[11169]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 24 10:16:48 localhost.localdomain network[11169]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 24 10:16:48 localhost.localdomain network[11169]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 24 10:16:48 localhost.localdomain network[11169]: [  OK  ]
ago 24 10:16:49 localhost.localdomain network[11169]: Bringing up interface enp0s3:  Connection successfully activated (D-Bus active path: /org/free...ction/3)
ago 24 10:16:49 localhost.localdomain network[11169]: [  OK  ]
ago 24 10:16:49 localhost.localdomain systemd[1]: Started LSB: Bring up/down networking.
Hint: Some lines were ellipsized, use -l to show in full.

Gateway, Hostname y DNS

La configuración de Gateway, Hostname sigue siendo exactamente igual Especificaremos nuestro HostName y puerta de enlace en el siguiente fichero:

vi /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=pruebas
GATEWAY=192.168.1.1

Y los DNS en lugar de configurarlos en /etc/resolv.conf vemos que es preferible añadirlos dentro del fichero de configuración de la interfaz de red:

vi /etc/resolv.conf

# Generated by NetworkManager


# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# DOMAIN=lab.foo.com bar.foo.com

Configuración en módo gráfico

La configuración en modo gráfico se basa en Network Manager, que en instalaciones MINIMAL de CentOS 7/RHEL 7 no está disponible. No obstante, si lo utilizáis (no lo recomiendo) veréis que es muy intuitivo, aunque no es recomendable utilizar ambos métodos a la vez (modificaciones manuales y network manager) por que los cambios del Network Manager suelen pisar a las configuraciones manuales.

Os dejo un screenshot del Network Manager disponible durante la instalación del SO:

instalacion centos 8 network configuration

 

Arrancar / Parar / Reiniciar servicios en RHEL 7 y CentOS 7

En RHEL 7 y CentOS 7 (ver guía de instalación)la forma de controlar los servicios del sistema cambia completamente. Pasamos del uso del comando “service” y de la control de servicios a través de “/etc/init.d” a la gestión a través del service manager systemctl.

La explicación la tenemos directamente en el fichero README de /etc/init.d:

# more /etc/init.d/README 
You are looking for the traditional init scripts in /etc/rc.d/init.d,
and they are gone?

Here's an explanation on what's going on:

You are running a systemd-based OS where traditional init scripts have
been replaced by native systemd services files. Service files provide
very similar functionality to init scripts. To make use of service
files simply invoke "systemctl", which will output a list of all
currently running services (and other units). Use "systemctl
list-unit-files" to get a listing of all known unit files, including
stopped, disabled and masked ones. Use "systemctl start
foobar.service" and "systemctl stop foobar.service" to start or stop a
service, respectively. For further details, please refer to
systemctl(1).

Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization.

Thank you!

Further reading:
        man:systemctl(1)
        man:systemd(1)

http://0pointer.de/blog/projects/systemd-for-admins-3.html


http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

Vamos a ver entonces los comandos básicos de gestión de servicios con systemctl.

Listar servicios del sistema

El comando systemctl sin parámetros nos mostrará el listado de todos los servicios del sistema, incluyendo los que están activos, parados o en estado fallido.

# systemctl 
UNIT                                                LOAD   ACTIVE SUB       DESCRIPTION
proc-sys-fs-binfmt_misc.automount                   loaded active waiting   Arbitrary Executable File Formats File System Automo
sys-devices-pci0...et1:0:0-1:0:0:0-block-sr0.device loaded active plugged   VBOX_CD-ROM
sys-devices-pci0...0-0000:00:03.0-net-enp0s3.device loaded active plugged   PRO/1000 MT Desktop Adapter
sys-devices-pci0...-0000:00:05.0-sound-card0.device loaded active plugged   82801AA AC'97 Audio Controller
sys-devices-pci0...:0-2:0:0:0-block-sda-sda1.device loaded active plugged   VBOX_HARDDISK
sys-devices-pci0...:0-2:0:0:0-block-sda-sda2.device loaded active plugged   LVM PV F3zoLx-uSaP-faJK-Vhz7-iJC4-XFml-QjX37E on /de
sys-devices-pci0...et2:0:0-2:0:0:0-block-sda.device loaded active plugged   VBOX_HARDDISK

Los servicios son llamados UNITS, y como veis podemos visualizar el estado del proceso, si está cargado en el sistema, descripción…

El parámetro list-units muestra la misma información:

# systemctl list-units

Ver estado de un servicio

Tan sencillo como pasar el parámetro status + el servicio. Vamos a ver el estado del firewall:

# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since sáb 2014-08-23 17:51:42 CEST; 9min ago
 Main PID: 549 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─549 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

ago 23 17:51:42 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall daemon.

Como podéis observar nos ofrece mucha más información que el típico status que teníamos en “init.d” y “service”. Incluso podemos ver el log completo o sólo la parte que engloba el arranque:

# systemctl status network.service
network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: active (exited) since sáb 2014-08-23 17:51:45 CEST; 10min ago
  Process: 830 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)

ago 23 17:51:43 localhost.localdomain systemd[1]: Starting LSB: Bring up/down networking...
ago 23 17:51:44 localhost.localdomain network[830]: Bringing up loopback interface:  Could not load file '/etc/sysconfig...g-lo'
ago 23 17:51:44 localhost.localdomain network[830]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 23 17:51:44 localhost.localdomain network[830]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 23 17:51:44 localhost.localdomain network[830]: Could not load file '/etc/sysconfig/network-scripts/ifcfg-lo'
ago 23 17:51:44 localhost.localdomain network[830]: [  OK  ]
ago 23 17:51:45 localhost.localdomain network[830]: Bringing up interface enp0s3:  [  OK  ]
ago 23 17:51:45 localhost.localdomain systemd[1]: Started LSB: Bring up/down networking.
Hint: Some lines were ellipsized, use -l to show in full.

Arrancar, parar y reiniciar servicios

Ya sabemos los servicios que hay en el sistema, así que podemos invocarlos para iniciarlos, pararlos o reiniciarlos:

Iniciar servicio:

# systemctl start firewalld.service

Parar servicio:

# systemctl stop firewalld.service

Reiniciar servicio:

# systemctl restart firewalld.service

Recargar servicio (si lo permite):

# systemctl reload firewalld.service

chkconfig vs systemctl

Esto lo quiero explicar más detenidamente en otro artículo, pero sólo añadir que chkconfig también es sustituido por systemctl.

Por ejemplo, para quitar la red del arranque:

[root@localhost ~]# systemctl disable NetworkManager.service
rm '/etc/systemd/system/multi-user.target.wants/NetworkManager.service'
rm '/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service'
rm '/etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service'

Y vemos que al lanzar un status aparece el servicio activo pero “disabled” en el arranque:

[root@localhost ~]# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled)
   Active: active (running) since sáb 2014-08-23 17:51:43 CEST; 15min ago
 Main PID: 676 (NetworkManager)

Si lo volvemos a configurar:

[root@localhost ~]# systemctl enable NetworkManager.service
ln -s '/usr/lib/systemd/system/NetworkManager.service' '/etc/systemd/system/dbus-org.freedesktop.NetworkManager.service'
ln -s '/usr/lib/systemd/system/NetworkManager.service' '/etc/systemd/system/multi-user.target.wants/NetworkManager.service'
ln -s '/usr/lib/systemd/system/NetworkManager-dispatcher.service' '/etc/systemd/system
/dbus-org.freedesktop.nm-dispatcher.service'
[root@localhost ~]# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
   Active: active (running) since sáb 2014-08-23 17:51:43 CEST; 16min ago

Esto es lo que tenéis que saber para iniciaros con systemctl. Recordad que la página man del comando tiene toda la información necesaria para administración avanzada. En algún otro artículo iré poniendo más funcionalidades interesantes (que no son pocas).