dutsnekcirf's questions

Recentemente, configuramos um servidor FreeIPA. Estamos usando-o para gerenciamento central de usuários, DNS e CA. Tem funcionado muito bem com uma exceção.

Algumas das estações de trabalho que se autenticam com este servidor FreeIPA estão a vários milhares de quilômetros de distância. O tempo de ida e volta é de cerca de 300 ms. Notamos algumas falhas de autenticação imprevisíveis nessas máquinas. Em um segundo, eles falharão em autenticar uma tentativa de login e, em seguida, conseguirão autenticar apenas alguns segundos depois. Estamos pensando que o atraso é o culpado.

Existe uma maneira de estender o tempo limite nos clientes? Como alternativa, estamos considerando a configuração de uma réplica IPA no local onde residem essas estações de trabalho. Como o link de alta latência afetaria a capacidade da réplica de replicar com o servidor primário?

Estou tentando configurar dinamicamente vários servidores NFS no meu sistema gerando seus arquivos /etc/exports usando o Ansible. Espero poder fazer isso com um modelo jinja2. É o modelo jinja2 que não consigo descobrir com base na minha lista de exportações.

Eu tenho as seguintes variáveis ​​definidas na minha função nfs:

site_nfs_servers: ['ansibletarget1', 'ansibletarget2']

exports:
  - server: "ansibletarget1"
    shares:
      - path: "/my/first/share/path"
        client: "*"
        options: "rw,sync"
      - path: "/my/second/share/path"
        client: "*"
        options: "rw,sync,root_squash"
  - server: "ansibletarget2"
    shares:
      - path: "/another/shared/path/different/server"
        client: "*"
        options: "ro,sync"

Eu então tenho o seguinte ansible play para gerar o modelo:

- name: Generate the exports file.
  template:
    src: exports.j2
    dest: /etc/exports
    owner: root
    group: root
    mode: '0750'

Meu template atualmente está assim:

{% for export in exports %}
{% if ansible_hostname in export.server %}
{% for share in shares %}
{{ share.path }} {{ share.client }} {{ share.options }}
{% endfor %}
{% endif %}
{% endfor %}

Acho que não estou nem perto de ter a estrutura de modelo correta. Como diabos alguém itera nessa lista?

Tenho dois roteadores Linux (RHEL 7) participando de uma configuração VRRP redundante fornecida pelo pacote keepalived versão 2.0.20. Esses dois roteadores costumavam executar o RHEL 6 e a versão 2.0.16 do keepalived, mas recentemente os atualizamos para as versões mencionadas.

Antes de atualizarmos, eu tinha um script que poderia executar no roteador de backup que faria com que o roteador assumisse o controle do roteador mestre. O script coletaria o valor de prioridade do roteador mestre atual e, em seguida, incrementaria sua própria prioridade para ser 1 maior e, em seguida, reiniciaria o serviço keepalived. Isso faria com que o roteador de backup assumisse o controle do mestre.

O script coletaria o valor do roteador mestre atual emitindo os seguintes comandos:

kill -s $(keepalived --signum=DATA) $(cat /var/run/keepalived.pid)
vrrpPriority='more /tmp/keepalived.data | grep -m1 "Master priority" | awk '{print $4}''

Agora que atualizamos, parece que o primeiro comando não faz mais nada. O comando parece ser executado sem erros, mas nunca recebo um arquivo gerado em /tmp/keepalived.data. Portanto, o segundo comando falha, pois esse arquivo não existe.

Existe uma maneira melhor ou diferente de obter o valor de prioridade do roteador mestre atual?

Outra diferença é que quando estávamos rodando no RHEL 6, o keepalived estava rodando como um script upstart enquanto hoje o keepalived está rodando como um serviço systemd. Todos os outros aspectos do keepalived parecem estar funcionando corretamente.

Nossa rede suporta muitos fluxos multicast usando pimd. Muitos (mas não todos) desses fluxos multicast só fluem se usarmos a instrução "altnet multicast_source_ip masklen 24" na seção phyint do arquivo pimd.conf. Esses fluxos multicast são adicionados ou removidos dinamicamente à medida que determinados dispositivos de rede são ativados/desativados com base em eventos específicos ao longo do dia. Ao longo do dia, o arquivo pimd.conf pode ter essas instruções altnet adicionadas ou removidas muitas vezes. Cada vez que isso ocorre, temos que emitir o comando "pimd -l" para que a alteração tenha efeito. Cada vez que este comando é emitido, o daemon é recarregado e a tabela mroute é apagada. Após um curto período de redescoberta, os mroutes lentamente retornam à tabela de roteamento multicast.

Gostaria de saber se é possível adicionar/remover diretivas altnet sem ter que editar o arquivo pimd.conf e emitir o comando pimd -l para recarregar a configuração. Em outras palavras, eles poderiam ser adicionados ou removidos durante o tempo de execução? Ou adicionado sem afetar nenhum fluxo/rota multicast existente?

Estou tentando configurar um cliente openvpn em um raspberry pi 3 b+. O raspberry pi está executando o CentOS 7 armhfp.

Instalei o openvpn do repositório EPEL para plataformas armhfp. Eu coloquei minha configuração e chaves associadas e arquivo de autenticação em /etc/openvpn

[root@raspberrypi openvpn]# ll
total 24
drwxr-x---. 2 root openvpn 4096 Jan  1  1970 client
-rwxrwxrwx. 1 root root    2186 Jan 25 22:17 mullvad_ca.crt
-rwxrwxrwx. 1 root root     985 Jan  1  1970 mullvad_us.conf
-rwxrwxrwx. 1 root root      19 Jan 25 22:17 mullvad_userpass.txt
drwxr-x---. 2 root openvpn 4096 Nov 18 14:06 server
-rwxrwxrwx. 1 root root    1301 Jan 25 22:17 update-resolv-conf
[root@raspberrypi openvpn]#

Estou tentando iniciar o serviço com o comando: systemctl start openvpn-client@mullvad_us

Quando eu faço isso falha com o seguinte status:

[root@raspberrypi openvpn]# systemctl status openvpn-client@mullvad_us -l
● openvpn-client@mullvad_us.service - OpenVPN tunnel for mullvad_us
   Loaded: loaded (/usr/lib/systemd/system/openvpn-client@.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2020-01-26 01:17:19 UTC; 3h 10min ago
     Docs: man:openvpn(8)
           https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
           https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 994 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf (code=exited, status=1/FAILURE)
 Main PID: 994 (code=exited, status=1/FAILURE)

Jan 26 01:17:19 raspberrypi systemd[1]: Starting OpenVPN tunnel for mullvad_us...
Jan 26 01:17:19 raspberrypi openvpn[994]: Options error: In [CMD-LINE]:1: Error opening configuration file: mullvad_us.conf
Jan 26 01:17:19 raspberrypi openvpn[994]: Use --help for more information.
Jan 26 01:17:19 raspberrypi systemd[1]: openvpn-client@mullvad_us.service: main process exited, code=exited, status=1/FAILURE
Jan 26 01:17:19 raspberrypi systemd[1]: Failed to start OpenVPN tunnel for mullvad_us.
Jan 26 01:17:19 raspberrypi systemd[1]: Unit openvpn-client@mullvad_us.service entered failed state.
Jan 26 01:17:19 raspberrypi systemd[1]: openvpn-client@mullvad_us.service failed.

Parece estar falhando ao ler meu arquivo mullvad_us.conf. Eu dei a ele 777 permissões completas, bem como tentei alterar sua propriedade para openvpn:openvpn. Eu também desabilitei o selinux caso esse seja o problema. Eu também movi os arquivos para /etc/openvpn/client sem sucesso também.

Se eu iniciar o openvpn na linha de comando, ele funcionará bem. Vou executar o comando: "nohup openvpn --config /etc/openvpn/mullvad_us.conf &" e o túnel será construído e formado corretamente.

Eu simplesmente não consigo fazer com que ele apareça automaticamente na inicialização. Estou planejando executar isso de maneira headless e não quero ter que ssh no dispositivo toda vez que o ligo apenas para ativar o túnel vpn.

Eu vi artigos online dizendo para editar o arquivo em /etc/default/openvpn, mas esse arquivo não existe por algum motivo e não posso deixar de pensar que é devido ao sabor do CentOS que estou executando. Neste ponto estou bastante perplexo. Qualquer ajuda seria grandemente agradecida.

Estou tentando instalar um servidor FreeRADIUS em uma VM RHEL 6.9. Esta VM está operando no modo FIPS. Estou enfrentando o problema descrito em um relatório de bug da Red Hat encontrado aqui .

De acordo com esse relatório de bug de março de 2015, o protocolo RADIUS requer suporte MD5. FreeRADIUS (e RADIUS) não podem, portanto, ser suportados no modo FIPS.

Espero que nos 3 anos que se passaram desde o relatório do bug, tenha havido uma correção ou solução alternativa que eu possa implementar para contornar esse problema. Infelizmente, estou restrito a executar no modo FIPS de acordo com os requisitos DISA STIG. Alguém conhece uma maneira de fazer o FreeRADIUS funcionar em uma máquina que está operando no modo FIPS?

Eu tenho uma máquina Linux que está sendo usada como roteador. Tem quagga instalado e tem ip forwarding habilitado. Está formando uma adjacência OSPF com um roteador Cisco 3925.

Estou sendo solicitado a garantir que esta máquina Linux (executando o Redhat 6.8) não enviará nenhuma notificação ICMP Inacessível. Eu sei que em um roteador Cisco eu simplesmente definiria "sem icmp inacessível" em qualquer interface que precisasse. Mas como posso ter certeza de que eles estão desabilitados em uma máquina Linux?

Também estou sendo solicitado a garantir que nenhuma mensagem "ICMP Mask Reply" seja enviada do roteador. Da mesma forma, sei que em um roteador Cisco o comando "no ip mask-reply" seria usado. Existe um tipo equivalente de configuração no Redhat?

Obrigado por qualquer ajuda.

Tenho uma máquina localizada em um ambiente seguro que não possui acesso à internet. Eu tenho uma carga base do CentOS com um punhado de RPMs adicionais. Isso inclui uma instalação básica do PERL sem módulos adicionais. Também não tem o GCC instalado, então não posso instalar novos módulos manualmente nem usar o CPAN para instalá-los. Portanto, preciso de uma solução Perl pura.

Pediram-me para criar um script Perl que validará se a máquina possui uma lista específica de RPMs instalados e se eles são de uma versão específica ou mais recente.

Aqui está o que eu tenho até agora:

#!/usr/bin/perl

use strict;
use warnings;

# This is the list of RPMs to look for on the machine.
my @RPMs = ("bwm-ng",
        "celt051",
        "device-mapper-multipath",
        "device-mapper-multipath-libs",
        "dhcp",
        "dhcp-common",
        "ebtables",
        "freeglut",
        "glusterfs-api",
        "glusterfs-libs",
        "gnutls-utils",
        "gpm",
        "hmaccalc",
        "iftop",
        "iperf",
        "ipsec-tools",
        "iptraf",
        "iscsi-initiator-utils",
        "libsysfs",
        "lm_sensors",
        "lm_sensors-libs",
        "log4cpp",
        "lrzsz",
        "lzop",
        "mcsctrans",
        "minicom",
        "nc",
        "netcf-libs",
        "net-snmp",
        "net-snmp-libs",
        "net-snmp-utils",
        "omping",
        "perl-AppConfig",
        "perl-Pod-POM",
        "perl-Template-Toolkit",
        "pimd",
        "python-lxml",
        "quagga",
        "radvd",
        "smcroute",
        "usbredir",
        "yajl");

# These are the RPM versions that they should be equal to or newer than.
my @RPMVersions = ("bwm-ng-0.6-6.el6.2.x86_64",
        "celt051-0.5.1.3-0.el6.x86_64",
        "device-mapper-multipath-0.4.9-87.el6.x86_64",
        "device-mapper-multipath-libs-0.4.9-87.el6.x86_64",
        "dhcp-4.1.1-49.P1.el6.centos.x86_64",
        "dhcp-common-4.1.1-49.P1.el6.centos.x86_64",
        "ebtables-2.0.9-6.el6.x86_64",
        "freeglut-2.6.0-1.el6.x86_64",
        "glusterfs-api-3.4.0.57rhs-1.el6_5.x86_64",
        "glusterfs-libs-3.4.0.57rhs-1.el6_5.x86_64",
        "gnutls-utils-2.8.5-18.el6.x86_64",
        "gpm-1.20.6-12.el6.x86_64",
        "hmaccalc-0.9.12-2.el6.x86_64",
        "iftop-1.0-0.7.pre4.el6.x86_64",
        "iperf-2.0.5-11.el6.x86_64",
        "ipsec-tools-0.8.0-25.3.x86_64",
        "iptraf-3.0.1-14.el6.x86_64",
        "iscsi-initiator-utils-6.2.0.873-14.el6.x86_64",
        "libsysfs-2.1.0-7.el6.x86_64",
        "lm_sensors-3.1.1-17.el6.x86_64",
        "lm_sensors-libs-3.1.1-17.el6.x86_64",
        "log4cpp-1.0-13.el6_5.1.x86_64",
        "lrzsz-0.12.20-27.1.el6.x86_64",
        "lzop-1.02-0.9.rc1.el6.x86_64",
        "mcsctrans-0.3.1-4.el6.x86_64",
        "minicom-2.3-6.1.el6.x86_64",
        "nc-1.84-24.el6.x86_64",
        "netcf-libs-0.2.4-3.el6.x86_64",
        "net-snmp-5.5-54.el6.x86_64",
        "net-snmp-libs-5.5-54.el6.x86_64",
        "net-snmp-utils-5.5-54.el6.x86_64",
        "omping-0.0.4-1.el6.x86_64",
        "perl-AppConfig-1.66-6.el6.x86_64",
        "perl-Pod-POM-0.25-2.el6.x86_64",
        "perl-Template-Toolkit-2.22-5.el6.x86_64",
        "pimd-2.3.0-1.x86_64",
        "python-lxml-2.2.3-1.1.el6.x86_64",
        "quagga-0.99.23.1-2014082501.x86_64",
        "radvd-1.6-1.el6.x86_64",
        "smcroute-2.0.0-0.x86_64",
        "usbredir-0.5.1-2.el6.x86_64",
        "yajl-1.0.7-3.el6.x86_64");

my $RPMname; #This reprepsents an individual RPM name within the @RPMs array.

foreach $RPMname (@RPMs){ # Loop through the @RPMs array and query the RPM database for each RPM.
    my $cmd = "rpm -qa | grep " . $RPMname;

    my @cmdResults = `$cmd`;

    if (! @cmdResults){
        print "\tMissing RPM: " . $RPMname . "\n\n"; # If the RPM isn't installed; inform the user.
    } else {
        foreach(@cmdResults){
            print "\t" . $_ . "\n"; # Print the version of the RPM that's currently installed.

            # Compare the RPM version that's installed with the corresponding version that should be installed
            # as listed in the @RPMVersions array.
            # write some magic here. <------

        }
    }
}

exit(0);

Eu encontrei o que parece ser uma solução possível, mas não consigo descobrir como ajustar o código de ajuste ao meu cenário.

veja aqui: http://www.perlmonks.org/bare/?node=240384

Não posso usar o RPM::VersionSort ou vários outros módulos relacionados ao RPM por causa das restrições que mencionei acima.

Qualquer ajuda seria grandemente agradecida.

Obrigado!

Eu tenho um mini-pc com seis interfaces de rede rodando CentOS 7.2 com Kernel 3.10 com uma instalação mínima.

Quero nomear minhas interfaces net0-net5. Para fazer isso, estou tentando seguir as sugestões mencionadas aqui: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

No artigo acima, afirma-se que, para renomear minhas interfaces, preciso criar arquivos .link e colocá-los em /etc/systemd/network. Esta é a nova maneira pela qual é necessário renomear suas interfaces de rede em conformidade com o systemd-networkd.

No entanto, estou descobrindo que o serviço systemd-networkd não inicia e, sem esse serviço em execução, acho que não consigo nomear minhas interfaces.

Veja o seguinte:

systemctl --failed -l
  UNIT                     LOAD   ACTIVE SUB    DESCRIPTION
<E2><97><8F> systemd-networkd.service loaded failed failed Network Service
<E2><97><8F> systemd-networkd.socket  loaded failed failed networkd rtnetlink so

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


systemctl  status systemd-networkd -l
��● systemd-networkd.service - Network Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit) since Tue 2011-05-10 01:45:45 UTC; 32min ago
     Docs: man:systemd-networkd.service(8)
  Process: 317 ExecStart=/usr/lib/systemd/systemd-networkd (code=exited, status=226/NAMESPACE)
 Main PID: 317 (code=exited, status=226/NAMESPACE)

May 10 01:45:45 localhost systemd[1]: Unit systemd-networkd.service entered failed state.
May 10 01:45:45 localhost systemd[1]: systemd-networkd.service failed.
May 10 01:45:45 localhost systemd[1]: systemd-networkd.service has no holdoff time, scheduling restart.
May 10 01:45:45 localhost systemd[1]: start request repeated too quickly for systemd-networkd.service
May 10 01:45:45 localhost systemd[1]: Failed to start Network Service.
May 10 01:45:45 localhost systemd[1]: Unit systemd-networkd.service entered failed state.
May 10 01:45:45 localhost systemd[1]: systemd-networkd.service failed.
May 10 01:45:45 localhost systemd[1]: start request repeated too quickly for systemd-networkd.service
May 10 01:45:45 localhost systemd[1]: Failed to start Network Service.
May 10 01:45:45 localhost systemd[1]: systemd-networkd.service failed.

systemctl  status systemd-networkd.socket -l                                                             
��● systemd-networkd.socket - networkd rtnetlink socket
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.socket; enabled; vendor preset: disabled)
   Active: failed (Result: service-failed-permanent) since Tue 2011-05-10 01:45:45 UTC; 39min ago
     Docs: man:systemd-networkd.service(8)
           man:rtnetlink(7)
   Listen: route 273 (Netlink)

May 10 01:45:45 localhost systemd[1]: Unit systemd-networkd.socket entered failed state.
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Devo mencionar que o NetworkManager não está instalado nem o DHCPlient. Devido ao fato de ser uma instalação mínima, pensei em mostrar quais processos estão em execução:

ps -ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:09 /init
    2 ?        S      0:00 [kthreadd]
    3 ?        S      0:00 [ksoftirqd/0]
    5 ?        S<     0:00 [kworker/0:0H]
    7 ?        S      0:00 [migration/0]
    8 ?        S  /0]
   10 ?        S      0:00 [rcuob/1]
   11 ?        S      0:00 [rcuob/2]
   12 ?        S      0:00 [rcuob/3]
   13 ?        S      0:00 [rcu_sched]
   14 ?        S      0:00 [rcuos/0]
   15 ?        S      0:00 [rcuos/1]
   16 ?        S      0:00 [rcuos/2]
   17 ?        S      0:00 [rcuos/3]
   18 ?        S      0:00 [watchdog/0]
   19 ?        S      0:00 [watchdog/1]
   20 ?        S      0:00 [migration/1]
   21 ?        S      0:00 [ksoftirqd/1]
   23 ?        S<     0:00 [kworker/1:0H]
   24 ?        S<     0:00 [khelper]
   25 ?        S      0:00 [kdevtmpfs]
   26 ?        S<     0:00 [netns]
   27 ?        S<     0:00 [perf]
   28 ?        S<     0:00 [writeback]
   29 ?        S<     0:00 [kintegrityd]
   30 ?        S<     0:00 [bioset]
   31 ?        S<     0:00 [kblockd]
   32 ?        S<     0:00 [md]
   33 ?        S      0:00 [kworker/0:1]
   34 ?        S      0:00 [kworker/1:1]
   38 ?        S      0:00 [khungtaskd]
   39 ?        S      0:00 [kswapd0]
   40 ?        SN     0:00 [ksmd]
   41 ?        SN     0:00 [khugepaged]
   42 ?        S      0:00 [fsnotify_mark]
   43 ?        S<     0:00 [crypto]
   51 ?        S<     0:00 [kthrotld]
   54 ?        S<     0:00 [kmpath_rdacd]
   55 ?        S      0:00 [kworker/1:2]
   56 ?        S<     0:00 [kpsmoused]
   57 ?        S      0:00 [kworker/0:2]
   58 ?        S<     0:00 [ipv6_addrconf]
   77 ?        S<     0:00 [deferwq]
   89 ?        Ss     0:00 /usr/lib/systemd/systemd-journald
   96 ?        S<     0:00 [rpciod]
  109 ?        S      0:00 [kauditd]
  110 ?        Ss     0:00 /usr/sbin/lvmetad -f
  131 ?        Ss     0:00 /usr/lib/systemd/systemd-udevd
  160 ?        S<     0:00 [events_power_ef]
  164 ?        S<     0:00 [ata_sff]
  166 ?        S      0:17 [kworker/u8:3]
  167 ?        S      0:00 [scsi_eh_0]
  169 ?        S<     0:00 [scsi_tmf_0]
  172 ?        S      0:00 [scsi_eh_1]
  173 ?        S<     0:00 [scsi_tmf_1]
  174 ?        S      0:00 [kworker/u8:4]
  175 ?        S      0:00 [scsi_eh_2]
  176 ?        S<     0:00 [scsi_tmf_2]
  177 ?        S      0:00 [scsi_eh_3]
  178 ?        S<     0:00 [scsi_tmf_3]
  181 ?        S<     0:00 [kvm-irqfd-clean]
  208 ?        S<     0:00 [kworker/0:1H]
  209 ?        S<     0:00 [kworker/1:1H]
  213 ?        S      0:00 [jbd2/sda1-8]
  214 ?        S<     0:00 [ext4-rsv-conver]
  215 ?        S<     0:00 [ext4-unrsv-conv]
  235 ?        S<sl   0:00 /sbin/auditd -n
  260 ?        SNs    0:00 /usr/sbin/alsactl -s -n 19 -c -E ALSA_CONFIG_PATH=/et
  262 ?        SNsl   0:00 /usr/libexec/rtkit-daemon
  263 ?        Ss     0:00 /bin/dbus-daemon --system --address=systemd: --nofork
  268 ?        Ss     0:00 avahi-daemon: running [linux.local]
  269 ?        Ssl    0:00 /usr/bin/python -Es /usr/sbin/firewalld --nofork --no
  270 ?        Ss     0:00 /usr/lib/systemd/systemd-logind
  279 ?        Ss     0:00 /usr/sbin/gpm -m /dev/input/mice -t exps2
  280 ?        Ss     0:00 /usr/sbin/irqbalance --foreground
  281 ?        Ssl    0:00 /usr/sbin/rsyslogd -n
  282 ?        Ssl    0:00 /usr/sbin/gssproxy -D
  284 ?        S      0:00 avahi-daemon: chroot helper
  500 ?        Ss     0:00 /usr/sbin/sshd -D
  503 ?        Ssl    0:00 /usr/bin/python -Es /usr/sbin/tuned -l -P
  510 ?        Ssl    0:00 /usr/sbin/libvirtd
  512 ?        Ss     0:00 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.
  519 ?        Ss     0:00 /usr/sbin/crond -n
  546 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
  547 ?        Ss     0:00 login -- mini
  976 ?        Ssl    0:00 /usr/lib/polkit-1/polkitd --no-debug
 1022 ?        S      0:00 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/de
 1023 ?        S      0:00 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/de
 1025 ttyS0    Ss     0:00 -bash
 1057 ttyS0    S      0:00 su -
 1058 ttyS0    S      0:00 -bash
 1093 ?        Ss     0:00 /usr/sbin/anacron -s
15547 ttyS0    R+     0:00 ps -ax

Uma coisa que acho interessante é que /init está listado como PID 1, mas ps -p 1 -o comm= mostra que estou executando o systemd. Também:

[root@localhost tmp]# pstree

systemd-+-agetty
        |-alsactl
        |-anacron
        |-auditd---{auditd}
        |-avahi-daemon---avahi-daemon
        |-crond
        |-dbus-daemon
        |-dnsmasq---dnsmasq
        |-firewalld---{firewalld}
        |-gpm
        |-gssproxy---5*[{gssproxy}]
        |-irqbalance
        |-libvirtd---15*[{libvirtd}]
        |-login---bash---su---bash---pstree
        |-lvmetad
        |-polkitd---5*[{polkitd}]
        |-rsyslogd---2*[{rsyslogd}]
        |-rtkit-daemon---2*[{rtkit-daemon}]
        |-sshd
        |-systemd-journal
        |-systemd-logind
        |-systemd-udevd
        |-tuned---4*[{tuned}]
        `-xinetd

Qualquer idéia sobre o que devo fazer para obter systemd-networkd.service e systemd-networkd.socket para carregar com sucesso seria muito apreciada.

Eu tenho uma instalação mínima do CentOS 7.2 em um pequeno mini PC com 6 portas Ethernet. Optei por excluir o NetworkManager da instalação, pois prefiro usar o serviço de rede básico ou mudar para o systemd-networkd. No entanto, não consigo iniciar os serviços de rede ou systemd-networkd.

    systemctl status network.service -l
��● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: failed (Result: exit-code) since Tue 2011-05-10 00:01:22 UTC; 5min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 25591 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)

May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost network[25591]: RTNETLINK answers: File exists
May 10 00:01:22 localhost systemd[1]: network.service: control process exited, code=exited status=1
May 10 00:01:22 localhost systemd[1]: Failed to start LSB: Bring up/down networking.
May 10 00:01:22 localhost systemd[1]: Unit network.service entered failed state.
May 10 00:01:22 localhost systemd[1]: network.service failed.

journalctl -xe -u network.service
    -- Logs begin at Tue 2011-05-10 00:00:40 UTC, end at Tue 2011-05-10 00:02:35 UTC. --
May 10 00:00:44 localhost systemd[1]: Starting LSB: Bring up/down networking...
-- Subject: Unit network.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit network.service has begun starting up.
May 10 00:00:44 localhost network[334]: Bringing up loopback interface:  [  OK  ]
May 10 00:00:45 localhost network[334]: Bringing up interface eth0:  ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Device eth
0 does not seem to be present, delaying initialization.
May 10 00:00:45 localhost network[334]: [FAILED]
May 10 00:00:45 localhost network[334]: Bringing up interface eth1:  ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Device eth
1 does not seem to be present, delaying initialization.
May 10 00:00:45 localhost /etc/sysconfig/network-scripts/ifup-eth[702]: Device eth1 does not seem to be present, delaying initializa
tion.
May 10 00:00:45 localhost network[334]: [FAILED]
May 10 00:00:45 localhost systemd[1]: network.service: control process exited, code=exited status=1
May 10 00:00:45 localhost systemd[1]: Failed to start LSB: Bring up/down networking.
-- Subject: Unit network.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit network.service has failed.
-- 
-- The result is failed.
May 10 00:00:45 localhost systemd[1]: Unit network.service entered failed state.
May 10 00:00:45 localhost systemd[1]: network.service failed.
May 10 00:01:20 localhost systemd[1]: Starting LSB: Bring up/down networking...

Aqui está dmesg | grep e1000e

    [root@localhost ~]# dmesg | grep eth
[    9.194339] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:01:05:0f:2a:a0
[    9.202239] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    9.209127] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 8, PBA No: FFFFFF-0FF
[    9.320640] e1000e 0000:04:00.0 eth1: registered PHC clock
[    9.320643] e1000e 0000:04:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:30:59:08:18:53
[    9.320645] e1000e 0000:04:00.0 eth1: Intel(R) PRO/1000 Network Connection
[    9.320734] e1000e 0000:04:00.0 eth1: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[    9.453298] e1000e 0000:05:00.0 eth2: registered PHC clock
[    9.458777] e1000e 0000:05:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 00:30:59:08:18:54
[    9.466673] e1000e 0000:05:00.0 eth2: Intel(R) PRO/1000 Network Connection
[    9.473608] e1000e 0000:05:00.0 eth2: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[    9.609123] e1000e 0000:06:00.0 eth3: registered PHC clock
[    9.609126] e1000e 0000:06:00.0 eth3: (PCI Express:2.5GT/s:Width x1) 00:30:59:08:18:55
[    9.609128] e1000e 0000:06:00.0 eth3: Intel(R) PRO/1000 Network Connection
[    9.609203] e1000e 0000:06:00.0 eth3: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[    9.704211] e1000e 0000:07:00.0 eth4: registered PHC clock
[    9.704214] e1000e 0000:07:00.0 eth4: (PCI Express:2.5GT/s:Width x1) 00:30:59:08:18:56
[    9.704216] e1000e 0000:07:00.0 eth4: Intel(R) PRO/1000 Network Connection
[    9.704291] e1000e 0000:07:00.0 eth4: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[    9.816322] e1000e 0000:08:00.0 eth5: registered PHC clock
[    9.816324] e1000e 0000:08:00.0 eth5: (PCI Express:2.5GT/s:Width x1) 00:01:05:0f:2a:a1
[    9.816326] e1000e 0000:08:00.0 eth5: Intel(R) PRO/1000 Network Connection
[    9.816483] e1000e 0000:08:00.0 eth5: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
[root@localhost ~]# ip addr
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: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN 
    link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: enp0s25: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:01:05:0f:2a:a0 brd ff:ff:ff:ff:ff:ff
5: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:59:08:18:53 brd ff:ff:ff:ff:ff:ff
6: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:59:08:18:54 brd ff:ff:ff:ff:ff:ff
7: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:59:08:18:55 brd ff:ff:ff:ff:ff:ff
8: enp7s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:59:08:18:56 brd ff:ff:ff:ff:ff:ff
9: enp8s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:01:05:0f:2a:a1 brd ff:ff:ff:ff:ff:ff
10: eth_bri: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether ae:75:23:c7:e3:b6 brd ff:ff:ff:ff:ff:ff
    inet 129.193.148.1/24 brd 129.193.148.255 scope global eth_bri
       valid_lft forever preferred_lft forever
    inet6 fe80::ac75:23ff:fec7:e3b6/64 scope link 
       valid_lft forever preferred_lft forever

Journctl -u network.service parece implicar que não há eth0, mas a partir de dmesg mostra que há eth0 a eth5. Contudo; quando eu emito ip addr, você pode ver que todos eles foram renomeados para o novo estilo fornecido por systemd-udevd; enp0s25... etc.

Há outro tópico aqui Não é possível iniciar o serviço de "rede" do CentOS 7, o que implica que o serviço dhcpclient pode estar atrapalhando. A resposta a esse tópico sugere desabilitar o serviço dhcpclient. No meu caso, não tenho um dhcpclient rodando.

[root@localhost ~]# ps -ef | grep dhc
root      2506 23576  0 00:23 ttyS0    00:00:00 grep --color=auto dhc
[root@localhost ~]#