Pages

Wednesday, May 6, 2015

EPP Status Codes (Extensible Provisioning Protocol)

When managing domain names, you’ll often encounter various EPP (Extensible Provisioning Protocol) status codes. These codes indicate the current state of a domain and what actions are allowed or restricted. Here’s a clear breakdown of the most common EPP status codes and what they mean for your domain management.

These codes are set by your Registrar (the company where you registered your domain):


  • Prevents deletion of the domain except if it expires. The domain remains active in the DNS and can be updated, transferred, or renewed.


  • Usually set for non-payment. The domain is removed from the DNS (not resolving), but can still be updated, transferred, deleted, or renewed.


  • The domain cannot be explicitly renewed. It remains in the DNS and can be updated, transferred, or deleted.


  • Blocks transfers to another Registrar. The domain is still active and can be updated, deleted, or renewed.


  • Functions like ClientTransferProhibited, preventing Registrar transfers while allowing updates, deletions, and renewals.


  • Prevents updates to name servers, auth codes, or domain syncs. The domain is still active and can be transferred, deleted, and renewed once this status is removed.


  • Locks the domain against updates, transfers, and deletions until the Registrar removes this status.

These codes are set by the Registry (the organization responsible for the TLD, like .com or .org):


  • Domain is removed from the DNS for financial, legal, or operational reasons. Not included in the zone files.


  • Prevents the domain from being deleted. The domain remains active and can be updated, transferred, or renewed.


  • The domain cannot be renewed. Still active and can be updated, transferred, or deleted.


  • Prevents transfer to another Registrar. The domain can still be updated, deleted, or renewed.


  • Blocks updates to name servers, auth codes, or syncs. The domain can be transferred, deleted, or renewed after status removal.


  • Prevents transfer, renewal, or deletion of the domain. Often used during disputes or special registry processes.


  • The domain is active, included in the DNS, and can be updated, transferred, or renewed.


  • Assigned when the domain has no name servers, or a host/contact is not associated with any domains.


  • The domain registration has been submitted but is not yet complete.


  • The domain is in the process of being transferred to another Registrar.


  • The domain is being updated, but the process is not yet complete.


  • The Registry has automatically renewed the domain at expiration. The Registrar can delete it within 45 days for a renewal fee credit.


  • The domain is scheduled for deletion after being in RedemptionPeriod for 30 days. Not restorable and not in the DNS.


  • The domain was deleted and is in a 30-day grace period where it can be restored by the Registrar. Otherwise, it proceeds to PendingDelete.


  • The domain is being restored from RedemptionPeriod. The Registrar must submit a restore report within 7 days, or the domain returns to RedemptionPeriod.

Tuesday, April 28, 2015

Libvirtd Error after Package Update

We were getting following error after package for libvirtd got updated to 1.2.8


Apr 28 12:18:04 compute1 libvirtd[12294]: failed to load module /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so: symbol dm_task_get_info_with_deferred_remove, version Base not defined in file libdevmapper.so.1.02 with link time reference
Apr 28 12:18:04 compute1 libvirtd[12294]: failed to load module /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so: undefined symbol: virStorageFileCreate
Apr 28 12:18:04 compute1 libvirtd[12294]: Module /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so not accessible
Apr 28 12:18:04 compute1 systemd[1]: Started Virtualization daemon.
Apr 28 12:19:01 compute1 libvirtd[12294]: no connection driver available for qemu:///system
Apr 28 12:19:01 compute1 libvirtd[12294]: End of file while reading data: Input/output error
Apr 28 12:23:42 compute1 libvirtd[12294]: no connection driver available for qemu:///system
Apr 28 12:23:42 compute1 libvirtd[12294]: End of file while reading data: Input/output error
Apr 28 12:23:42 compute1 libvirtd[12294]: no connection driver available for qemu:///system
Apr 28 12:23:42 compute1 libvirtd[12294]: End of file while reading data: Input/output error


Solution for this was to update the device-mapper diver and restart the services.

yum update device-mapper

Similar issue : https://bugzilla.redhat.com/show_bug.cgi?id=1164773

Friday, April 24, 2015

Updating CA certificates in Fedora/Centos/RHEL

On Fedora since 19, RHEL / CentOS 7, and RHEL / CentOS 6  the correct method is to place the certificate to be trusted (in PEM format) in /etc/pki/ca-trust/source/anchors/ and run sudo update-ca-trust.
 (If the certificate is in OpenSSL’s extended BEGIN TRUSTED CERTIFICATE format, place it in /etc/pki/ca-trust/source). On RHEL 6, you have to activate the system with update-ca-trust enable after installing the update.