Почему socket.getfqdn () Python возвращает длинную строку, которая выглядит как хост IPv6, а не как `hostname -f`? - PullRequest
2 голосов
/ 24 декабря 2011

Почему Python socket.getfqdn() возвращает '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa' вместо matt-mmf-macbook.local?

mlm@matt-mmf-macbook.local:~
$ python
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn()
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa'
>>> 

mlm@matt-mmf-macbook.local:~
$ hostname
matt-mmf-macbook.local

mlm@matt-mmf-macbook.local:~
$ hostname -f
matt-mmf-macbook.local

Неожиданный вывод socket.getfqdn() приводит к сбою моих резервных копий Duplicity с выводом ниже. Мое последнее успешное резервное копирование Duplicity было 12/19.

mlm@matt-mmf-macbook.local:~
$ ~/config/bash/backup.sh
Reading globbing filelist /Users/mlm/config/bash/backup-include-matt-mmf-macbook.txt
Reading globbing filelist /Users/mlm/config/bash/backup-exclude-matt-mmf-macbook.txt
Local and Remote metadata are synchronized, no sync needed.
Warning, found the following remote orphaned signature files:
duplicity-new-signatures.20110929T140604Z.to.20110929T143209Z.sigtar.gpg
duplicity-new-signatures.20110929T143209Z.to.20110929T150055Z.sigtar.gpg
duplicity-new-signatures.20110929T150055Z.to.20110929T161503Z.sigtar.gpg
duplicity-new-signatures.20110929T161503Z.to.20110930T161505Z.sigtar.gpg
duplicity-new-signatures.20110930T161505Z.to.20111005T024235Z.sigtar.gpg
duplicity-new-signatures.20111005T024235Z.to.20111005T024907Z.sigtar.gpg
duplicity-new-signatures.20111005T024907Z.to.20111005T161508Z.sigtar.gpg
duplicity-new-signatures.20111005T161508Z.to.20111006T161509Z.sigtar.gpg
duplicity-new-signatures.20111006T161509Z.to.20111007T161507Z.sigtar.gpg
duplicity-new-signatures.20111007T161507Z.to.20111010T161511Z.sigtar.gpg
duplicity-new-signatures.20111010T161511Z.to.20111011T161507Z.sigtar.gpg
duplicity-new-signatures.20111011T161507Z.to.20111012T161510Z.sigtar.gpg
duplicity-new-signatures.20111012T161510Z.to.20111013T161505Z.sigtar.gpg
duplicity-new-signatures.20111013T161505Z.to.20111017T161506Z.sigtar.gpg
duplicity-new-signatures.20111017T161506Z.to.20111018T161505Z.sigtar.gpg
duplicity-new-signatures.20111018T161505Z.to.20111019T161506Z.sigtar.gpg
duplicity-new-signatures.20111019T161506Z.to.20111020T161506Z.sigtar.gpg
duplicity-new-signatures.20111020T161506Z.to.20111021T161511Z.sigtar.gpg
duplicity-new-signatures.20111021T161511Z.to.20111025T161507Z.sigtar.gpg
duplicity-new-signatures.20111025T161507Z.to.20111026T161510Z.sigtar.gpg
duplicity-new-signatures.20111026T161510Z.to.20111027T161506Z.sigtar.gpg
duplicity-new-signatures.20111027T161506Z.to.20111028T161511Z.sigtar.gpg
duplicity-new-signatures.20111028T161511Z.to.20111104T161506Z.sigtar.gpg
duplicity-new-signatures.20111104T161506Z.to.20111115T222417Z.sigtar.gpg
Last full backup date: Wed Nov 16 12:16:14 2011
Fatal Error: Backup source host has changed.
Current hostname: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
Previous hostname: matt-mmf-macbook.local

Aborting because you may have accidentally tried to backup two different data sets to the same remote location, or using the same archive directory.  If this is not a mistake, use the --allow-source-mismatch switch to avoid seeing this message

mlm@matt-mmf-macbook.local:~
$ 

Мой backup.sh содержит:

#! /bin/bash

PATH=/usr/local/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:$PATH

. ~/config/bash/awskeys.sh

. $(type -p virtualenvwrapper.sh)
workon duplicity

ulimit -n 1024

duplicity \
    --encrypt-key DEADBEEF \
    --include-globbing-filelist ~/config/bash/backup-include-$(hostname -s).txt \
    --exclude-globbing-filelist ~/config/bash/backup-exclude-$(hostname -s).txt \
    / \
    s3://s3.amazonaws.com/backup-$(hostname -s)/

Ответы [ 3 ]

3 голосов
/ 06 июня 2013

Я столкнулся с подобной проблемой.getfqfn () возвращал local.localdomain вместо значения host.mydomain.com, возвращаемого hostname.Проверка getfqfn () docs показывает:

Возвращает полное доменное имя для имени.Если имя опущено или пусто, оно интерпретируется как локальный хост. Чтобы найти полное имя, имя хоста, возвращаемое gethostbyaddr (), проверяется , за которым следуют псевдонимы для хоста, если они доступны.Имя, которое включает точку, выбирается.Если полное доменное имя не доступно, возвращается имя хоста, возвращаемое gethostname ().

В моем случае, getfqdn () фактически просматривал мой / etc / hosts, который перечислил

127.0.0.1 local.localdomain localhost host.mydomain.com

Так как «настоящее» имя хоста было в конце, а «local.localdomain» - это «первое имя, которое включает точку», именно оно использовалось.Изменение моего / etc / hosts на:

127.0.0.1 host.mydomain.com local.localdomain localhost

привело к возвращению правильного имени хоста.

Я думаю, что аналогичная проблема возникает для вас.

0 голосов
/ 26 декабря 2011

Я перешел в «Системные настройки»> «Сеть»> «Wi-Fi»> «Дополнительно»> «TCP / IP» и изменил «Настроить IPv6» с:

Off

до:

Automatically

И теперь я получаю то, что ожидаю:

mlm@matt-mmf-macbook.local:~
$ python -c 'import socket ; print socket.getfqdn()'
matt-mmf-macbook.local

mlm@matt-mmf-macbook.local:~
$ 

Я также заметил, что «Выкл.» Больше не доступен после изменения на «Автоматически».

0 голосов
/ 24 декабря 2011

Я бы предположил, что он просто пропускает локальное разрешение DNS и переходит к запросу в Интернете имени хоста.

Единственное правильное имя хоста для адреса IPv6 ::1 - это 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa, плюсимя определено локально - но интернет не знает этого.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...