Fehler Fire auf CentOS 7

Question

ich den Code unter Verwendung von Port 80 auf meinem Sever zu öffnen:

sudo firewall-cmd --zone=public --add-port=80/tcp --permanent 

aber ich bekomme diese Fehlermeldung:

Traceback (most recent call last): 
    File "/bin/firewall-cmd", line 24, in <module> 
    from gi.repository import GObject 
    File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 37, in <module> 
    from . import _gi ImportError: /lib64/libgirepository-1.0.so.1: 
undefined symbol: g_type_class_adjust_private_offset 

Bitte helfen Sie mir es zu beheben. Vielen Dank!

Answer 1

Ich hatte das gleiche Problem auf einigen Centos 7, OpenVZ VMs, die ohne Firewall installiert wurden. Einfach das firewalld RPM-Paket installieren, weil beim Start nicht funktionierte, würde firewalld sagen:

# /usr/sbin/firewalld --nofork --nopid 
Traceback (most recent call last): 
    File "/usr/sbin/firewalld", line 132, in <module> 
    from firewall.server import server 
    File "/usr/lib/python2.7/site-packages/firewall/server/server.py", line 32, in <module> 
    from gi.repository import GObject, GLib 
    File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 37, in <module> 
    from . import _gi 
ImportError: /lib64/libgirepository-1.0.so.1: undefined symbol: g_type_class_adjust_private_offset 

Nach einem sehr viel über von faffing, habe ich festgestellt, dass (Stand Juni 2016) ein einfachen ‚yum update‘ ist genug, um alles funktionieren zu lassen. Ich bin nicht der Klügere, welche Pakete tatsächlich der Schuldige sind, aber es ist wahrscheinlich eine gute Sache, alles auf den neuesten Stand zu bringen.

Answer 2

Okay, die schnelle Lösung besteht darin, die Datei "/ bin/firewall-cmd" zu bearbeiten (oder eine Kopie dieser Datei zu erstellen, dann die Kopie zu bearbeiten) und dann die erste Zeile von "#!/Usr/bin/python - Es "zu" #!/Usr/bin/python2 -Es ". Auf meinem System scheint dieses Problem von jemandem verursacht worden zu sein, der python3 installiert hat und den symbolischen Link für "/ bin/python" so geändert hat, dass er auf python3 statt auf 2 zeigt. Achtung: viele interne Linux-Skripte erfordern python2. Jedes neue Skript, das python3 benötigt, sollte dies im shebang (sharp-bang hack) in Zeile 1 deklarieren. BTW, ich habe auch gesehen, dass Python3 einige yum-bezogene Operationen unterbricht.