3 Zář
2026
3 Zář
'26
18:26
For the most part, our tests with FRED 2026.1 has been successful as follows:
*
We use a copy of a development DB and modify it so the log tables in the DB FRED are
eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our homemade EPP client,
too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification of the peer
certificate is disabled.
NIC-REG1(a)192.168.81.203 > info-contact --id=CN_1
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication with the server
failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification of the peer
certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication with the server
failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in _send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109, in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121, in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line 158, in
receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the server failed.
If only happens with this particular operation. The other info operations and the rest of
commands, including creation of a contact, work perfect.
And it seems that it happens on the backend, because the corresponding XML generated from
our page, which is a homemade XML, equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or eliminating the log tables,
now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
4 Zář
4 Zář
9:25
Hello Mario.
Thank you for your summary, we're glad to hear from you.
Regarding the "info-contact" case, could you please send us the
fred-rifd log for that period? We'll analyse it. Thank you.
Kind regards
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
For the most part, our tests with FRED 2026.1 has been
successful as
follows:
*
We use a copy of a development DB and modify it so the log tables
in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our
homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification of
the peer certificate is disabled.
NIC-REG1(a)192.168.81.203 > i*nfo-contact --id=CN_1*
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification of
the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
_send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109, in
send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121, in
_receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line 158,
in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
server failed.
If only happens with this particular operation. The other info
operations and the rest of commands, including creation of a contact,
work perfect.
And it seems that it happens on the backend, because the corresponding
XML generated from our page, which is a homemade XML, equivalent to
info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or
eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
10:16
To get complete overview, please send us logs from fred-rifd.log and
eppd.log. Probably those files are located in /var/log/fred-rifd.log and
/var/log/apache2/eppd.log.
Thanks
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 04. 09. 26 v 9:25 dop. Aleš Jarolímek napsal(a):
Hello Mario.
Thank you for your summary, we're glad to hear from you.
Regarding the "info-contact" case, could you please send us the
fred-rifd log for that period? We'll analyse it. Thank you.
Kind regards
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
For the most part, our tests with FRED 2026.1 has
been successful as
follows:
*
We use a copy of a development DB and modify it so the log tables
in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our
homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
NIC-REG1(a)192.168.81.203 > i*nfo-contact --id=CN_1*
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
_send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109,
in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121,
in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line
158, in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
server failed.
If only happens with this particular operation. The other info
operations and the rest of commands, including creation of a contact,
work perfect.
And it seems that it happens on the backend, because the
corresponding XML generated from our page, which is a homemade XML,
equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or
eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
16:52
This is an eppic example:
NIC-REG1(a)192.168.1.203 > info-contact CON0001
2026-09-04 08:49:59,398 WARNING epp:send_request:163 Communication with the server
failed. Retrying...
2026-09-04 08:49:59,398 WARNING epp:logout:71 Logout failed.
2026-09-04 08:49:59,435 WARNING transport:connect:105 Verification of the peer
certificate is disabled.
2026-09-04 08:49:59,788 ERROR epp:send_request:166 Communication with the server
failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in _send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109, in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121, in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line 158, in
receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-04 08:49:59,789 WARNING epp:logout:71 Logout failed.
2026-09-04 08:49:59,789 ERROR app:run:184 Communication with the server failed.
This is the rifd log (from the syslog file, only the fred-rifd fragments):
root@fred26-app:/var/log# grep rifd syslog
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-1-rifd} version -- get version 2.70.1
BUILD Jan 23 2026 13:05:39 -- {epp_impl.cc:751}
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-2-rifd} ClientLogin -- ClientLogin:
username-> [NIC-REG1] clTRID [1awmj3#2026-09-04T08:49:48.602726] passwd [.......]
newpass [] -- {epp_impl.cc:1506}
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-2-rifd} ClientLogin -- ClientLogin:
certID [B5:37:E2:35:67:87:B5:1F:A0:E3:13:57:38:DE:56:09] language [0] --
{epp_impl.cc:1512}
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-2-rifd} ClientLogin -- ClientLogin:
username NIC-REG1, regID 2, clTRID 1awmj3#2026-09-04T08:49:48.602726, lang 0 got clientID
4657860 -- {epp_impl.cc:1574}
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-2-rifd} ~DB -- delete svrTRID --
{dbsql.cc:99}
Sep 4 08:49:48 fred26-app fred-rifd[518]: {518-8-2-rifd} ~DB -- delete memHandle --
{dbsql.cc:109}
Sep 4 08:49:59 fred26-app fred-rifd[518]:
{518-8-3-rifd-clid-2-ReqID-0000000893-ContactInfo} close -- connection closed --
{connection.hh:75}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-4-rifd} version -- get version 2.70.1
BUILD Jan 23 2026 13:05:39 -- {epp_impl.cc:751}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-5-rifd} ClientLogin -- ClientLogin:
username-> [NIC-REG1] clTRID [htdmyg#2026-09-04T08:49:59.468571] passwd [.......]
newpass [] -- {epp_impl.cc:1506}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-5-rifd} ClientLogin -- ClientLogin:
certID [B5:37:E2:35:67:87:B5:1F:A0:E3:13:57:38:DE:56:09] language [0] --
{epp_impl.cc:1512}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-5-rifd} ClientLogin -- ClientLogin:
username NIC-REG1, regID 2, clTRID htdmyg#2026-09-04T08:49:59.468571, lang 0 got clientID
4657861 -- {epp_impl.cc:1574}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-5-rifd} ~DB -- delete svrTRID --
{dbsql.cc:99}
Sep 4 08:49:59 fred26-app fred-rifd[518]: {518-8-5-rifd} ~DB -- delete memHandle --
{dbsql.cc:109}
Sep 4 08:49:59 fred26-app fred-rifd[518]:
{518-8-6-rifd-clid-2-ReqID-0000000895-ContactInfo} close -- connection closed --
{connection.hh:75}
________________________________
De: Aleš Jarolímek
Enviado: Viernes, 4 de Septiembre de 2026 02:16
Para: A mailing list for users and developers of FRED registry system; Mario Guerra
CC: Andrey López; Ricardo Samper Jimenez; Michael Venegas
Asunto: Re: FRED 2026.1 report
To get complete overview, please send us logs from fred-rifd.log and
eppd.log. Probably those files are located in /var/log/fred-rifd.log and
/var/log/apache2/eppd.log.
Thanks
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 04. 09. 26 v 9:25 dop. Aleš Jarolímek napsal(a):
Hello Mario.
Thank you for your summary, we're glad to hear from you.
Regarding the "info-contact" case, could you please send us the
fred-rifd log for that period? We'll analyse it. Thank you.
Kind regards
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
For the most part, our tests with FRED 2026.1 has
been successful as
follows:
*
We use a copy of a development DB and modify it so the log tables
in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our
homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
NIC-REG1(a)192.168.81.203 > i*nfo-contact --id=CN_1*
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
_send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109,
in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121,
in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line
158, in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
server failed.
If only happens with this particular operation. The other info
operations and the rest of commands, including creation of a contact,
work perfect.
And it seems that it happens on the backend, because the
corresponding XML generated from our page, which is a homemade XML,
equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or
eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
17:21
And here is the Apache log (error.log):
root@fred26-epp:/var/log/apache2# tail -f error.log
[Fri Sep 04 08:18:04.796401 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 806
exit signal Segmentation fault (11)
[Fri Sep 04 08:18:04.797144 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 807
exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.967887 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 873
exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.968713 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 874
exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085034 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 932
exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085761 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 933
exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.782942 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 996
exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.783500 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 997
exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.935576 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1056
exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.936126 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1057
exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.461327 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1115
exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.462234 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1116
exit signal Segmentation fault (11)
These happen when I type info_contact or when an equivalent XML is issued .
Just talked with Ricardo (I'm forwarding this to him).
It happens that in our case, the dev DB includes database roles for the BSA module and I
tested a copy of that DB modified so the logs tables a re no more the the fred DB but NO
additional roles. Well, Ricardo did include those roles and info_contact works well.
Because these tests do not include the BSA part (the fred-bsapp module) which is not added
to this version, I considered they were not needed
We are following this next Monday or Tuesday.
Thanks in advance for your help.
Mario Guerra - NIC-CR
________________________________
De: Aleš Jarolímek
Enviado: Viernes, 4 de Septiembre de 2026 02:16
Para: A mailing list for users and developers of FRED registry system; Mario Guerra
CC: Andrey López; Ricardo Samper Jimenez; Michael Venegas
Asunto: Re: FRED 2026.1 report
To get complete overview, please send us logs from fred-rifd.log and
eppd.log. Probably those files are located in /var/log/fred-rifd.log and
/var/log/apache2/eppd.log.
Thanks
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 04. 09. 26 v 9:25 dop. Aleš Jarolímek napsal(a):
Hello Mario.
Thank you for your summary, we're glad to hear from you.
Regarding the "info-contact" case, could you please send us the
fred-rifd log for that period? We'll analyse it. Thank you.
Kind regards
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
For the most part, our tests with FRED 2026.1 has
been successful as
follows:
*
We use a copy of a development DB and modify it so the log tables
in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our
homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
NIC-REG1(a)192.168.81.203 > i*nfo-contact --id=CN_1*
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
_send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109,
in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121,
in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line
158, in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
server failed.
If only happens with this particular operation. The other info
operations and the rest of commands, including creation of a contact,
work perfect.
And it seems that it happens on the backend, because the
corresponding XML generated from our page, which is a homemade XML,
equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or
eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz 
7 Zář
7 Zář
10:17
Hi,
I tried reproducing the issue like this on fresh installation:
1) modified the epp schema so underscores are accepted by apache
|
fred@fred-demo:~$ diff
/usr/share/fred-mod-eppd/schemas/fredcom-1.2.1.xsd
/usr/share/fred-mod-eppd/schemas/fredcom-1.2.1_original.xsd
34c34
< <pattern value="[a-zA-Z0-9]([-_]?[a-zA-Z0-9])*"/>
---
<pattern
value="[a-zA-Z0-9](-?[a-zA-Z0-9])*"/>|
2) Updated the registry backend handle validation checker to accept the
underscored handles
|
fred=> UPDATE regex_handle_validation_checker SET
regex='[a-zA-Z0-9]([-_]?[a-zA-Z0-9])*' WHERE id=1;
UPDATE 1
fred=> SELECT * FROM regex_handle_validation_checker;
id | regex | description
----+--------------------------------+------------------------------------------------------------
2 | .{1,30} | handle length is at least 1 and
no more than 30 characters
1 | [a-zA-Z0-9]([-_]?[a-zA-Z0-9])* | valid characters according to CZ.NIC
(2 rows)|
3) Created the contact and tried informing about it
|REG-DEMO@localhost > create-contact --id=TEST_TEST
--postal-info.name=test --postal-info.addr.city=test
--postal-info.addr.pc=111111 --postal-info.addr.cc=CZ
--email=test(a)test.cz --postal-info.addr.street-1=test
Command completed successfully (1000)
REG-DEMO@localhost > info-contact TEST_TEST
Command completed successfully (1000)
|
It seems that at least we can confirm that it is not an issue of the
standard registrar workflow or the object handles themselves.
Taking a look at the database setup as you mentioned sounds like the way
to go. Registrar interface uses these configuration variables for the db
access:
|
|
|fred@fred-demo:~$ /usr/sbin/fred-rifd --help | grep database
--database.name arg (=fred) database name
--database.user arg (=fred) database user name
--database.password arg database password
--database.host arg (=localhost) database hostname
--database.port arg database port number
--database.timeout arg database timeout|
If your core registry database, logger and fred-bsapp share schema or
roles that might imply some namespace conflicts or access issues. On the
standard fred-bsapp setup, the roles created for the application should
be completely separate from the registry database. The application only
stores it's own data in the database and uses the registry
domain_blacklist api
<https://gitlab.nic.cz/fred/api/registry/-/blob/master/fred_api/registry/domain_blacklist/service_domain_blacklist_grpc.proto>
to update the registry instead. So no need for the role to have access
to the registry in any way.
As far as my limited knowledge about logger goes, I don't think it needs
any registry database acess as well as all the logged data are received
from application
<https://gitlab.nic.cz/fred/liblogger/-/blob/master/src/create_log_entry.cc?ref_type=heads#L100>
that performs the actual request.
Kind regards,
--
Jan Dobiášovský
SQA
CZ.NIC, z.s.p.o.
Milešovská 1136/5
130 00 Praha 3
_______________________________________________
fred-users mailing list --fred-users(a)lists.nic.cz
To unsubscribe send an email tofred-users-leave(a)lists.nic.cz
On 9/4/26 17:21, Mario Guerra wrote:
And here is the Apache log (error.log):
root@fred26-epp:/var/log/apache2# tail -f error.log
[Fri Sep 04 08:18:04.796401 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 806 exit signal Segmentation fault (11)
[Fri Sep 04 08:18:04.797144 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 807 exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.967887 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 873 exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.968713 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 874 exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085034 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 932 exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085761 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 933 exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.782942 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 996 exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.783500 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 997 exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.935576 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 1056 exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.936126 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 1057 exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.461327 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 1115 exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.462234 2026] [core:notice] [pid 519:tid 519]
AH00052: child pid 1116 exit signal Segmentation fault (11)
These happen when I type info_contact or when an equivalent XML is
issued .
Just talked with Ricardo (I'm forwarding this to him).
It happens that in our case, the dev DB includes database roles for
the BSA module and I tested a copy of that DB modified so the logs
tables a re no more the the fred DB but NO additional roles. Well,
Ricardo did include those roles and info_contact works well. Because
these tests do not include the BSA part (the fred-bsapp module) which
is not added to this version, I considered they were not needed
We are following this next Monday or Tuesday.
Thanks in advance for your help.
Mario Guerra - NIC-CR
------------------------------------------------------------------------
*De:* Aleš Jarolímek
*Enviado:* Viernes, 4 de Septiembre de 2026 02:16
*Para:* A mailing list for users and developers of FRED registry
system; Mario Guerra
*CC:* Andrey López; Ricardo Samper Jimenez; Michael Venegas
*Asunto:* Re: FRED 2026.1 report
To get complete overview, please send us logs from fred-rifd.log and
eppd.log. Probably those files are located in /var/log/fred-rifd.log and
/var/log/apache2/eppd.log.
Thanks
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 04. 09. 26 v 9:25 dop. Aleš Jarolímek napsal(a):
> Hello Mario.
>
> Thank you for your summary, we're glad to hear from you.
>
> Regarding the "info-contact" case, could you please send us the
> fred-rifd log for that period? We'll analyse it. Thank you.
>
> Kind regards
>
> Aleš Jarolímek
> L2 support
>
> CZ.NIC, z. s. p. o.
> Milešovská 1136/5
> 130 00 Praha 3
>
>
> Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
>> For the most part, our tests with FRED 2026.1 has been successful as
>> follows:
>>
>> *
>> We use a copy of a development DB and modify it so the log tables
>> in the DB FRED are eliminated
>> *
>> We configured the fred-app services properly
>> *
>> We have successfuly generated DNS tables (and signed them, BTW)
>> *
>> FERDA, whois, web whois and RDAP work as expected
>> *
>> Messenger, secretary and fileman are properly configured.
>>
>>
>> There is one curious problem with eppic (and it happens with our
>> homemade EPP client, too).
>>
>> eppic works mostly well, but there is one command that does not:
>>
>> root@fred26-app:~# eppic
>> 2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification
>> of the peer certificate is disabled.
>> NIC-REG1(a)192.168.81.203 > i*nfo-contact --id=CN_1*
>> 2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
>> with the server failed. Retrying...
>> 2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
>> 2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification
>> of the peer certificate is disabled.
>> 2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
>> with the server failed. Logging out and closing connection...
>> Traceback (most recent call last):
>> File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
>> send_request
>> return self._send_request(request, cltrid)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
>> _send_request
>> response = self._client.send(request, tr_id=cltrid)
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> File "/usr/lib/python3/dist-packages/epplib/client.py", line 109,
>> in send
>> response = cast(ResponseT, self._receive(request.response_class))
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> File "/usr/lib/python3/dist-packages/epplib/client.py", line 121,
>> in _receive
>> response_raw = self.transport.receive()
>> ^^^^^^^^^^^^^^^^^^^^^^^^
>> File "/usr/lib/python3/dist-packages/epplib/transport.py", line
>> 158, in receive
>> raise TransportError('Empty response recieved.')
>> epplib.exceptions.TransportError: Empty response recieved.
>> 2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
>> 2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
>> server failed.
>>
>> If only happens with this particular operation. The other info
>> operations and the rest of commands, including creation of a contact,
>> work perfect.
>>
>> And it seems that it happens on the backend, because the
>> corresponding XML generated from our page, which is a homemade XML,
>> equivalent to info-contact, fails too.
>>
>> As I said, info-nsset, etc. work well, too.
>>
>> What do you think?
>>
>> BTW, we have copied our dev DB and modified it (exporting or
>> eliminating the log tables, now in the fredlog DB). And that's it.
>>
>> Best regards.
>>
>> Mario Guerra - NIC-CR
>>
>>
>> _______________________________________________
>> fred-users mailing list -- fred-users(a)lists.nic.cz
>> To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
>
>
> _______________________________________________
> fred-users mailing list -- fred-users(a)lists.nic.cz
> To unsubscribe send an email to fred-users-leave(a)lists.nic.cz
14 Zář
14 Zář
21:06
An update.
This has solved, at least for now, this curious problem:
apt --reinstall install libapache2-mod-corba libapache2-mod-eppd=2.27.0-1~bookworm+1
Notice the EPP module downgrading. Both must be reinstalled, it seems.
After this, everything works: eppic (and the corresponding XML transactions), DNS table
generation (fred-hm), command-line whois, web whois and RDAP (fred-web) and FERDA
(fred-admin).
The only server not properly configured is fred-akm.
Note: apparently, if you don't specify the version when reinstalling de CORBA and eppd
modules, the last one seems to be reinstalled at the 2.27.0 version.
Best regards
________________________________
De: Jan Dobiášovský <jan.dobiasovsky(a)nic.cz>
Enviado: lunes, 7 de septiembre de 2026 02:17
Para: fred-users(a)lists.nic.cz <fred-users(a)lists.nic.cz>
Asunto: Re: FRED 2026.1 report
Hi,
I tried reproducing the issue like this on fresh installation:
1) modified the epp schema so underscores are accepted by apache
fred@fred-demo:~$ diff /usr/share/fred-mod-eppd/schemas/fredcom-1.2.1.xsd
/usr/share/fred-mod-eppd/schemas/fredcom-1.2.1_original.xsd
34c34
< <pattern value="[a-zA-Z0-9]([-_]?[a-zA-Z0-9])*"/>
---
<pattern
value="[a-zA-Z0-9](-?[a-zA-Z0-9])*"/>
2) Updated the registry backend handle validation checker to accept the underscored
handles
fred=> UPDATE regex_handle_validation_checker SET
regex='[a-zA-Z0-9]([-_]?[a-zA-Z0-9])*' WHERE id=1;
UPDATE 1
fred=> SELECT * FROM regex_handle_validation_checker;
id | regex | description
----+--------------------------------+------------------------------------------------------------
2 | .{1,30} | handle length is at least 1 and no more than 30
characters
1 | [a-zA-Z0-9]([-_]?[a-zA-Z0-9])* | valid characters according to CZ.NIC
(2 rows)
3) Created the contact and tried informing about it
REG-DEMO@localhost > create-contact --id=TEST_TEST --postal-info.name=test
--postal-info.addr.city=test --postal-info.addr.pc=111111 --postal-info.addr.cc=CZ
--email=test(a)test.cz --postal-info.addr.street-1=test
Command completed successfully (1000)
REG-DEMO@localhost > info-contact TEST_TEST
Command completed successfully (1000)
It seems that at least we can confirm that it is not an issue of the standard registrar
workflow or the object handles themselves.
Taking a look at the database setup as you mentioned sounds like the way to go. Registrar
interface uses these configuration variables for the db access:
fred@fred-demo:~$ /usr/sbin/fred-rifd --help | grep database
--database.name arg (=fred) database name
--database.user arg (=fred) database user name
--database.password arg database password
--database.host arg (=localhost) database hostname
--database.port arg database port number
--database.timeout arg database timeout
If your core registry database, logger and fred-bsapp share schema or roles that might
imply some namespace conflicts or access issues. On the standard fred-bsapp setup, the
roles created for the application should be completely separate from the registry
database. The application only stores it's own data in the database and uses the
registry domain_blacklist
api<https://gitlab.nic.cz/fred/api/registry/-/blob/master/fred_api/registry/domain_blacklist/service_domain_blacklist_grpc.proto>
to update the registry instead. So no need for the role to have access to the registry in
any way.
As far as my limited knowledge about logger goes, I don't think it needs any registry
database acess as well as all the logged data are received from
application<https://gitlab.nic.cz/fred/liblogger/-/blob/master/src/create_log_entry.cc?ref_type=heads#L100>
that performs the actual request.
Kind regards,
--
Jan Dobiášovský
SQA
CZ.NIC, z.s.p.o.
Milešovská 1136/5
130 00 Praha 3
_______________________________________________
fred-users mailing list -- fred-users@lists.nic.cz<mailto:fred-users@lists.nic.cz>
To unsubscribe send an email to
fred-users-leave@lists.nic.cz<mailto:fred-users-leave@lists.nic.cz>
On 9/4/26 17:21, Mario Guerra wrote:
And here is the Apache log (error.log):
root@fred26-epp:/var/log/apache2# tail -f error.log
[Fri Sep 04 08:18:04.796401 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 806
exit signal Segmentation fault (11)
[Fri Sep 04 08:18:04.797144 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 807
exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.967887 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 873
exit signal Segmentation fault (11)
[Fri Sep 04 08:20:41.968713 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 874
exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085034 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 932
exit signal Segmentation fault (11)
[Fri Sep 04 08:37:23.085761 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 933
exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.782942 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 996
exit signal Segmentation fault (11)
[Fri Sep 04 08:47:41.783500 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 997
exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.935576 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1056
exit signal Segmentation fault (11)
[Fri Sep 04 08:49:59.936126 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1057
exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.461327 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1115
exit signal Segmentation fault (11)
[Fri Sep 04 08:57:50.462234 2026] [core:notice] [pid 519:tid 519] AH00052: child pid 1116
exit signal Segmentation fault (11)
These happen when I type info_contact or when an equivalent XML is issued .
Just talked with Ricardo (I'm forwarding this to him).
It happens that in our case, the dev DB includes database roles for the BSA module and I
tested a copy of that DB modified so the logs tables a re no more the the fred DB but NO
additional roles. Well, Ricardo did include those roles and info_contact works well.
Because these tests do not include the BSA part (the fred-bsapp module) which is not added
to this version, I considered they were not needed
We are following this next Monday or Tuesday.
Thanks in advance for your help.
Mario Guerra - NIC-CR
________________________________
De: Aleš Jarolímek
Enviado: Viernes, 4 de Septiembre de 2026 02:16
Para: A mailing list for users and developers of FRED registry system; Mario Guerra
CC: Andrey López; Ricardo Samper Jimenez; Michael Venegas
Asunto: Re: FRED 2026.1 report
To get complete overview, please send us logs from fred-rifd.log and
eppd.log. Probably those files are located in /var/log/fred-rifd.log and
/var/log/apache2/eppd.log.
Thanks
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 04. 09. 26 v 9:25 dop. Aleš Jarolímek napsal(a):
Hello Mario.
Thank you for your summary, we're glad to hear from you.
Regarding the "info-contact" case, could you please send us the
fred-rifd log for that period? We'll analyse it. Thank you.
Kind regards
Aleš Jarolímek
L2 support
CZ.NIC, z. s. p. o.
Milešovská 1136/5
130 00 Praha 3
Dne 03. 09. 26 v 6:26 odp. Mario Guerra napsal(a):
For the most part, our tests with FRED 2026.1 has
been successful as
follows:
*
We use a copy of a development DB and modify it so the log tables
in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our
homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
NIC-REG1@192.168.81.203<mailto:NIC-REG1@192.168.81.203> > i*nfo-contact
--id=CN_1*
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication
with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification
of the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication
with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in
send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in
_send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109,
in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121,
in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line
158, in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the
server failed.
If only happens with this particular operation. The other info
operations and the rest of commands, including creation of a contact,
work perfect.
And it seems that it happens on the backend, because the
corresponding XML generated from our page, which is a homemade XML,
equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or
eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
_______________________________________________
fred-users mailing list -- fred-users@lists.nic.cz<mailto:fred-users@lists.nic.cz>
To unsubscribe send an email to
fred-users-leave@lists.nic.cz<mailto:fred-users-leave@lists.nic.cz>
_______________________________________________
fred-users mailing list -- fred-users@lists.nic.cz<mailto:fred-users@lists.nic.cz>
To unsubscribe send an email to
fred-users-leave@lists.nic.cz<mailto:fred-users-leave@lists.nic.cz>
39
days inactive
50
days old
6 comments
3 participants
participants (3)
-
Aleš Jarolímek -
Jan Dobiášovský -
Mario Guerra