Hello.
We've tested applying credits to registrars using FRED. Now, I want to
make a question of how the deductions are made.
Say, I decide to have 40 monetary units for domain creation and 10 for
domain update for renewing my domain, this way.
/fred-admin --price_add --operation_price 40.00 --zone_fqdn dom
--operation CreateDomain/
/fred-admin --price_add --operation_price 10.00 --zone_fqdn dom
--operation RenewDomain/
and assign 140 monetary units to their credit, this way
/fred-admin --invoice_credit --zone_id 1 --registrar_id 6 --price 140/
The zone numbered 1 is "dom" .
When I create a domain like this:
/create_domain testmg6.dom mf02 NULL NULL NULL (1 y)
/
What is deducted from the credit is 80 monetary units, not 70, so what
is left is 60.
Is that correct?. If it is, how to apply ONLY the renewal price when you
renew the domain, not when you create it?.
Best regards.
Mario Guerra
NIC-CR
On 27 Jun 2017 at 9:18, Ghislain wrote:
> Good Morning all,
>
> We (i.e. .RW registry – RICTA Ltd.) are not using FRED but I think the prepayment
model is more
> or less the same.
>
> #1. We don’t pre-invoice the registrars based on a “pre-established” list of
domain names.
> This is a lot of work, and it won’t scale if you have 100 of registrars, unless
the registry does that
> for them.
> But even if it is possible from the registry, it is a lot of work for “them” (i.e.
manual work).
>
> Therefore, they (registrars) just send money/amount, let say $500 or 30,000 RWF,
and that is
> what we issue the invoice for.
> With a simple description, i.e. “Advance payment”. BTW, the amount can vary
depending on
> what they want to register, renew, etc.
Thank you for the input, most of this is already the same on .mw registry.
> The law in Rwanda don’t allow to receive money without an invoice. (it being
advance or actual
> payment).
It appears there is no such law in Malawi and this is part of the reason I raised the
question - to learn what is the case with other ccTLD registries.
> #2. Once received, we credit their accounts in the Registry system. (still a
manual process).
> Then they can do whatever they want with it (i.e. do registration, renewal, pay
for transfer fees,
> etc.).
Same.
So, does your registry system have facilities for generating invoices such as these for
pre-payments?
Does it produce statements form registrars?
Regards,
Paulos
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
>
> I think this approach (above) is more flexible.
>
> A little additional info:
>
> The money received from registrars, is a liability until it is consumed.
> Until it is consumed, it cannot yet be called revenues from your side (registry).
> From financial “documents” perspective, an un-consumed advance payment is a
liability that
> needs to seat in the balance sheet.
> Once the revenue is realized (end of month), the money can be recognized in you
Income
> statement. (you debit the liability and credit your income accounts).
>
> Sorry if this is perhaps more than what you asked for.
>
> Thank you,
>
> Ghislain
> .RW registry
>
> From: fred-users <fred-users-bounces(a)lists.nic.cz> on behalf of Jaromir Talir
> <jaromir.talir(a)nic.cz>
> Reply-To: A mailing list for users and developers of FRED registry system
> <fred-users(a)lists.nic.cz>
> Date: Friday, 23 June 2017 at 17:18
> To: <paulos(a)sdnp.org.mw>, <fred-users(a)lists.nic.cz>
> Subject: Re: payments - invoices and statements on FRED registry system
>
> Hi Paulos,
>
> I guess this is more question for some Malawi lawyer. In Czech Republic
> we have a law that we should issue invoice when we receive advanced
> payment. However, this may be something specific for our legislation.
> Also every legislation specifies what should be the content of the
> invoice in that case (issuer, recipient, day of payment, effective day
> of service, etc..). This may differ country to country as well. FRED
> contains PDF templates for invoices according Czech legislation. I
> cannot say if they may be used for you as well.
>
> If you will be in Joburg, we can have a talk about it there.
>
> Regards,
> Jaromir
>
> On Fri, 2017-06-16 at 05:15 +0200, Dr P Nyirenda wrote:
> Hello,
> I would like to find out how your registry responds to a request like
> the one here below
> for invoices and statements on registrar payments to a registry that
> uses the FRED
> registry system.
> On our registry for the Malawi .mw ccTLD, registrar payments are
> credited to the
> registrar zone by zone according to what the registrar has paid for.
> Once the registrar
> has consumed the credit, then they need to make a new payment in
> advance which is then
> credited to the zones that they need.
> We do not need to issue them an invoice in advance, they make the
> payments based on what
> transactions they need to do on each zone.
> When we receive a request for their data payments, we have used
> Invoice on Daphne to
> generate the data and we have sent this to the registrar.
> However, as you can see here below, this registrar seems to be asking
> for more.
> I would therefore like to request information on how your registry
> using FRED handles
> requests for data, invoices and statements like these.
> Regards,
> Paulos
> ======================
> Dr Paulos B Nyirenda
> NIC.MW & .mw ccTLD
> http://www.registrar.mw
> ------- Forwarded message follows -------
> From: Jamil Kamaly <Jamil.Kamaly(a)NetNames.com >
> To: "paulos(a)sdnp.org.mw" <paulos(a)sdnp.org.mw>
> Copies to: Michal Czyz <Michal.Czyz(a)NetNames.com>, domains mw
> <domains(a)registrar.mw>,
> PB Nyirenda <pb.nyirenda(a)gmail.com>
> Subject: RE: Malawi payments.
> Date sent: Wed, 14 Jun 2017 11:56:39 +0000
> Hi Dr Paulos,
> I think you might have misunderstood, I wasn’t complaining. The
> details you provided me
> in April was excel spreadsheet with payment details and the zones
> that were topped. We
> need proper invoices and statements and therefore I was following up
> on our last
> conversation where you was saying that you are developing a system to
> make this possible.
> I was just checking if this is now possible and would we be getting
> proper statements
> and invoices.
> Thank you.
> Kind regards,
> Jamil
> ----------------------------------------------------------
> Malawi SDNP Webmail: http://www.sdnp.org.mw
> Access your Malawi SDNP e-mail from anywhere in the world.
> ----------------------------------------------------------
> --
> Jaromir Talir
> Technicky partner / Technical Fellow
> -------------------------------------------
> CZ.NIC, z.s.p.o. -- .cz domain registry
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:jaromir.talir@nic.cz http://nic.cz/
> sip: jaromir.talir(a)nic.cz tel:+420.222745107
> mob:+420.739632712 fax:+420.222745112
> -------------------------------------------
> _______________________________________________
> fred-users mailing list
> fred-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
>
----------------------------------------------------------
Malawi SDNP Webmail: http://www.sdnp.org.mw
Access your Malawi SDNP e-mail from anywhere in the world.
----------------------------------------------------------
Hello,
I would like to find out how your registry responds to a request like the one here below
for invoices and statements on registrar payments to a registry that uses the FRED
registry system.
On our registry for the Malawi .mw ccTLD, registrar payments are credited to the
registrar zone by zone according to what the registrar has paid for. Once the registrar
has consumed the credit, then they need to make a new payment in advance which is then
credited to the zones that they need.
We do not need to issue them an invoice in advance, they make the payments based on what
transactions they need to do on each zone.
When we receive a request for their data payments, we have used Invoice on Daphne to
generate the data and we have sent this to the registrar.
However, as you can see here below, this registrar seems to be asking for more.
I would therefore like to request information on how your registry using FRED handles
requests for data, invoices and statements like these.
Regards,
Paulos
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
------- Forwarded message follows -------
From: Jamil Kamaly <Jamil.Kamaly(a)NetNames.com>
To: "paulos(a)sdnp.org.mw" <paulos(a)sdnp.org.mw>
Copies to: Michal Czyz <Michal.Czyz(a)NetNames.com>, domains mw <domains(a)registrar.mw>,
PB Nyirenda <pb.nyirenda(a)gmail.com>
Subject: RE: Malawi payments.
Date sent: Wed, 14 Jun 2017 11:56:39 +0000
Hi Dr Paulos,
I think you might have misunderstood, I wasn’t complaining. The details you provided me
in April was excel spreadsheet with payment details and the zones that were topped. We
need proper invoices and statements and therefore I was following up on our last
conversation where you was saying that you are developing a system to make this possible.
I was just checking if this is now possible and would we be getting proper statements
and invoices.
Thank you.
Kind regards,
Jamil
----------------------------------------------------------
Malawi SDNP Webmail: http://www.sdnp.org.mw
Access your Malawi SDNP e-mail from anywhere in the world.
----------------------------------------------------------
Jaromir,
Just one or two more clarifications on FRED:
1. Is there a default maximum number of years (or months) for renewing a domain ?
I see that in .cz this is required to be 10 years - is this burned into FRED or can it be
modified?
See: https://www.nic.cz/files/nic/doc/Registration_rules_CZ.pdf
Regards,
Paulos
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
Vous avez reçu une invitation !
--------------------------------------
Rejoignez Ousmane Sanogo à Meetup#2 Présentation et Workshop Openstack
Quand :
samedi 29 avril 2017, 09:00
Où :
Ecole Agitel-Formation
132, Abidjan, Côte d'Ivoire, Abidjan
Ce Meetup est organisé par Openstack Côte d'Ivoire.
Après une première rencontre pour fêter les 6 ans de Openstack et le lancement du groupe d'utilisateur de Côte d'ivoire, nous organisons un second Meetup qui va vous permettre de mieux connaitre Open...
https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXN…
--------------------------------------
-------
Message envoyé par Meetup de la part de Ousmane Sanogo (https://www.meetup.com/fr-FR/Openstack-Cote-divoire/members/212092234/) depuis Openstack Côte d'Ivoire.
Une question? Vous pouvez contacter le support Meetup via support(a)meetup.com
Je ne souhaite plus recevoir ce type d'e-mail (https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJob29…)
Meetup Inc. (https://www.meetup.com/fr-FR/), POB 4668 #37895 New York NY USA 10163
Hi,
in addition to new FRED release, we have also released a new website at
https://fred.nic.cz and completely new documentation system.
Documentation url is https://fred.nic.cz/documentation. I feel
importance of this deserves to use separate email for announcement. New
documentation is searchable and it contains many new graphical schemas
important to understand FRED architecture and processes. Source code of
this documentation in reStructuredText format is available on github
https://github.com/CZ-NIC/fred-docs. This means that you are more then
welcomed to submit comments or preferably pull requests for things that
you think they are missing in documentation. Please, check
documentation and let us know what you think about this.
Regards,
Jaromir
Hi,
we have published FRED version 2.29. During several previous releases
we have rewritten almost all code responsible for EPP communication
with registrars. This refactoring was necessery for implementation of
new features in the future. Here is a compilation of some significant
changes.
- support for more operating systems. For the first time we provide
also packages for latest RHEL/Centos version 7. Since Ubuntu 12.04 will
lost its long term support in April, we will not provide packages for
this version anymore. Preffered version of Ubuntu is 16.04. We use
Ubuntu 16.04 in production for some time without any issues. This also
means that Ubuntu 16.04 is most tested platform. In other platforms we
only run limited set of automated tests so registries are required to
do more indepth tests themselves.
- configurable domain name format checking. Checking of validity of
domain name is configurable per zone via linking to set of
preconfigured checkers in database table
zone_domain_name_validation_checker_map.
- new idn support configuration. There used to be allow_idn option in
server configuration file that meant that regular registrars are able
to register domains in xn-- format (idn domains) in all zones. In
current version it is possible to configure idn support per zone via
mechanism mentioned earlier. Support for idn is just another
preconfigured checker.
- configurable dnssec algorithm checking. Until now, there was no
checking of dnssec algorithm number used in EPP create_keyset or
update_keyset EPP commands. If registries would like to limit this
check only for some algorithms, they can do that via modification of
database tables dnssec_algorithm and dnssec_algorithm_blacklist.
- configurable limit of minimal number of nameservers in nsset. Until
now, there was hardcoded requirement to have at least 2 nameservers and
maximum 10 nameservers in nsset. Since this was limitation for some
registries that wanted to use FRED, we moved this limit into
configuration option nsset_min_hosts and nsset_max_hosts in server
configuration file
- asynchronous notification about EPP events. Notifications for domain
state change has always been generated asynchronously via fred-admin
commands, but notifications about EPP events done by registrars were
created as part of EPP operation. To speed up system a little bit and
to be able to continue EPP operation even when notification system is
down, we made also notification about EPP events asynchronnous. So
don't forget to add into cron system command 'fred-admin --
notify_email_objects_events' in intervals of your preference if you
want to keep sending notifications.
Regards,
Jaromir
People:
A nagging problem we had when we migrated FRED to Ubuntu 14.04 (until a
couple of weeks ago we ran 2.22 on Ubuntu 12.04) was that, suddenly,
Apache connections gave us a CLOSE_WAIT, not a clean closing of the
connection. This gave us a real headache with both our whois server and
our EPP server.
The solution?. Well, simply uninstall the mpm_event Apache module and
install the mem_prefork one:
a2dismod mpm_event
a2enmod mem_prefork
service apache2 restart
I hope this helps the people using FRED under Ubuntu 14.04 experiencing
a similar problem.
------------
Mario Guerra
NIC-CR
While running
# apt-get update
on Ubunto-16 as warning is issued:
W: http://archive.nic.cz/ubuntu/dists/xenial/Release.gpg: Signature by key
55360425D50EB41DB9A21E67F20C079E020ADBB4 uses weak digest algorithm (SHA1)
It seems that Debian and friends do not like SHA1 any longer.
They provide more info on the removal of sha1 and how to fix a half-broken
repositories
https://wiki.debian.org/Teams/Apt/Sha1Removal
I suppose the fred repository for ubunto at archive.nic.cz could be updated
along those lines.
We are to try out having a few extra national characters
áýúíóæøåð
and in uppercase these are
ÁÝÚÍÓÆØÅÐ
in ccTLD names (.fo)
We found the 'allow_idn' in server.conf
and have it set as 'true' (allow_idn = true),
but this seems not to be enough, and does not really fullfill the requirements.
IDN is mentioned an option in fred, but where/how can we turn this on,
and what should we be aware of ?
...torkil...
Sorry for this lengthy message, but a bugfix is provided with a description
of the issue in the latest packages of fred for ubunto
Have a nice day
On Ubuntu 16.04.1 LTS - just updated and upgraded everything including
fred, broke fred
# systemctl status fred-logd
● fred-logd.service - FRED logging daemon
Loaded: loaded (/lib/systemd/system/fred-logd.service; enabled; vendor
preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2016-12-30
16:56:12 WET; 17min ago
Process: 3653 ExecStart=/usr/sbin/fred-logd -ORBendPoint giop:tcp::2226
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-logd.conf (code=exited,
status=1/FAILURE)
Main PID: 3653 (code=exited, status=1/FAILURE)
Dec 30 16:56:12 fred-ubunto-16 systemd[1]: fred-logd.service: Failed with
result 'exit-code'.
Dec 30 16:56:12 fred-ubunto-16 systemd[1]: fred-logd.service: Service
hold-off time over, scheduling restart.
Dec 30 16:56:12 fred-ubunto-16 systemd[1]: Stopped FRED logging daemon.
Dec 30 16:56:12 fred-ubunto-16 systemd[1]: fred-logd.service: Start request
repeated too quickly.
Dec 30 16:56:12 fred-ubunto-16 systemd[1]: Failed to start FRED logging
daemon.
Hmm where is fred-logd.conf ?
In /etc/init/fred-logd.conf !
BUGFIX
# cd /etc/fred
# ln -s ../init/fred-logd.conf
root@fred-ubunto-16:/etc/fred# systemctl start fred-logd
root@fred-ubunto-16:/etc/fred# systemctl status fred-logd
● fred-logd.service - FRED logging daemon
Loaded: loaded (/lib/systemd/system/fred-logd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-12-30 17:22:57 WET; 2s ago
Main PID: 4600 (fred-logd)
Tasks: 3
Memory: 2.5M
CPU: 25ms
CGroup: /system.slice/fred-logd.service
└─4600 /usr/sbin/fred-logd -ORBendPoint giop:tcp::2226
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-logd.conf
Dec 30 17:22:57 fred-ubunto-16 systemd[1]: Started FRED logging daemon.
So the bugfix worked :-)
Next issue:
# systemctl status fred-rifd
● fred-rifd.service - FRED registrar interface daemon
Loaded: loaded ( ; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2016-12-30
16:50:26 WET; 35min ago
Process: 3321 ExecStart=/usr/sbin/fred-rifd -ORBendPoint giop:tcp::2224
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-rifd.conf (code=exited,
status=1/FAILURE)
Main PID: 3321 (code=exited, status=1/FAILURE)
Dec 30 16:50:25 fred-ubunto-16 systemd[1]: fred-rifd.service: Main process
exited, code=exited, status=1/FAILURE
Dec 30 16:50:25 fred-ubunto-16 systemd[1]: fred-rifd.service: Unit entered
failed state.
Dec 30 16:50:25 fred-ubunto-16 systemd[1]: fred-rifd.service: Failed with
result 'exit-code'.
Dec 30 16:50:26 fred-ubunto-16 systemd[1]: fred-rifd.service: Service
hold-off time over, scheduling restart.
Dec 30 16:50:26 fred-ubunto-16 systemd[1]: Stopped FRED registrar interface
daemon.
Dec 30 16:50:26 fred-ubunto-16 systemd[1]: fred-rifd.service: Start request
repeated too quickly.
Dec 30 16:50:26 fred-ubunto-16 systemd[1]: Failed to start FRED registrar
interface daemon.
Again /lib/systemd/system/fred-rifd.service specifies fred-rifd.conf to be
in /etc/fred, were as it is in /etc/init :-/
BUGFIX
# cd /etc/fred
# ln -s ../init/fred-rifd.conf
# cd
# systemctl start fred-rifd
# systemctl status fred-rifd
● fred-rifd.service - FRED registrar interface daemon
Loaded: loaded (/lib/systemd/system/fred-rifd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-12-30 17:30:01 WET; 6s ago
Main PID: 4777 (fred-rifd)
Tasks: 3
Memory: 3.3M
CPU: 31ms
CGroup: /system.slice/fred-rifd.service
└─4777 /usr/sbin/fred-rifd -ORBendPoint giop:tcp::2224
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-rifd.conf
Dec 30 17:30:01 fred-ubunto-16 systemd[1]: Started FRED registrar interface
daemon.
So the bugfix worked :-)
Next issue:
# systemctl status fred-pifd
● fred-pifd.service - FRED public interface daemon
Loaded: loaded (/lib/systemd/system/fred-pifd.service; enabled; vendor
preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2016-12-30
16:28:07 WET; 1h 7min ago
Process: 1334 ExecStart=/usr/sbin/fred-pifd -ORBendPoint giop:tcp::2223
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-pifd.conf (code=exited,
status=1/FAILURE)
Main PID: 1334 (code=exited, status=1/FAILURE)
Tasks: 0
Memory: 0B
CPU: 0
CGroup: /system.slice/fred-pifd.service
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-pifd.service: Main process
exited, code=exited, status=1/FAILURE
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-pifd.service: Unit entered
failed state.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-pifd.service: Failed with
result 'exit-code'.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-pifd.service: Service
hold-off time over, scheduling restart.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: Stopped FRED public interface
daemon.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-pifd.service: Start request
repeated too quickly.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: Failed to start FRED public
interface daemon.
BUGFIX
# cd /etc/fred
# ln -s ../init/fred-pifd.conf
# cd
# systemctl start fred-pifd
# systemctl status fred-pifd
● fred-pifd.service - FRED public interface daemon
Loaded: loaded (/lib/systemd/system/fred-pifd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-12-30 17:36:47 WET; 10ms ago
Main PID: 4941 (fred-pifd)
Tasks: 1
Memory: 1.1M
CPU: 5ms
CGroup: /system.slice/fred-pifd.service
└─4941 /usr/sbin/fred-pifd -ORBendPoint giop:tcp::2223
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-pifd.conf
Dec 30 17:36:47 fred-ubunto-16 systemd[1]: Started FRED public interface
daemon.
So the bugfix worked :-)
Next issue:
# systemctl status fred-msgd
● fred-msgd.service - FRED messaging daemon
Loaded: loaded (/lib/systemd/system/fred-msgd.service; enabled; vendor
preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2016-12-30
16:28:06 WET; 1h 9min ago
Process: 1258 ExecStart=/usr/sbin/fred-msgd -ORBendPoint giop:tcp::2228
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-msgd.conf (code=exited,
status=1/FAILURE)
Main PID: 1258 (code=exited, status=1/FAILURE)
Dec 30 16:28:05 fred-ubunto-16 systemd[1]: fred-msgd.service: Unit entered
failed state.
Dec 30 16:28:05 fred-ubunto-16 systemd[1]: fred-msgd.service: Failed with
result 'exit-code'.
Dec 30 16:28:06 fred-ubunto-16 systemd[1]: fred-msgd.service: Service
hold-off time over, scheduling restart.
Dec 30 16:28:06 fred-ubunto-16 systemd[1]: Stopped FRED messaging daemon.
Dec 30 16:28:06 fred-ubunto-16 systemd[1]: fred-msgd.service: Start request
repeated too quickly.
Dec 30 16:28:06 fred-ubunto-16 systemd[1]: Failed to start FRED messaging
daemon.
Same thing
BUGFIX
# cd /etc/init
# ln -s ../init/fred-msgd.conf
# cd
# systemctl start fred-msgd
# systemctl status fred-msgd
● fred-msgd.service - FRED messaging daemon
Loaded: loaded (/lib/systemd/system/fred-msgd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-12-30 17:38:59 WET; 4s ago
Main PID: 5016 (fred-msgd)
Tasks: 3
Memory: 1.6M
CPU: 20ms
CGroup: /system.slice/fred-msgd.service
└─5016 /usr/sbin/fred-msgd -ORBendPoint giop:tcp::2228
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-msgd.conf
Dec 30 17:38:59 fred-ubunto-16 systemd[1]: Started FRED messaging daemon.
So the bugfix worked :-)
Next issue:
# systemctl status fred-adifd
● fred-adifd.service - FRED administration interface daemon
Loaded: loaded (/lib/systemd/system/fred-adifd.service; enabled; vendor
preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2016-12-30
16:28:08 WET; 1h 12min ago
Process: 1352 ExecStart=/usr/sbin/fred-adifd -ORBendPoint giop:tcp::2222
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-adifd.conf
(code=exited, status=1/FAILURE)
Main PID: 1352 (code=exited, status=1/FAILURE)
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-adifd.service: Unit entered
failed state.
Dec 30 16:28:07 fred-ubunto-16 systemd[1]: fred-adifd.service: Failed with
result 'exit-code'.
Dec 30 16:28:08 fred-ubunto-16 systemd[1]: fred-adifd.service: Service
hold-off time over, scheduling restart.
Dec 30 16:28:08 fred-ubunto-16 systemd[1]: Stopped FRED administration
interface daemon.
Dec 30 16:28:08 fred-ubunto-16 systemd[1]: fred-adifd.service: Start
request repeated too quickly.
Dec 30 16:28:08 fred-ubunto-16 systemd[1]: Failed to start FRED
administration interface daemon.
Again same thing
BUGFIX
# cd /etc/fred
# ln -s ../init/fred-adifd.conf
# cd
# root@fred-ubunto-16:~# systemctl start fred-adifd
# root@fred-ubunto-16:~# systemctl status fred-adifd
● fred-adifd.service - FRED administration interface daemon
Loaded: loaded (/lib/systemd/system/fred-adifd.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2016-12-30 17:41:42 WET; 4s ago
Main PID: 5128 (fred-adifd)
Tasks: 4
Memory: 3.3M
CPU: 29ms
CGroup: /system.slice/fred-adifd.service
└─5128 /usr/sbin/fred-adifd -ORBendPoint giop:tcp::2222
-ORBnativeCharCodeSet UTF-8 --config /etc/fred/fred-adifd.conf
Dec 30 17:41:42 fred-ubunto-16 systemd[1]: Started FRED administration
interface daemon.
Final check
# fred-status && echo ok
ok
DONE :-)
NOTE
fred-status is a local script which looks like this:
#######################################################################
#!/bin/sh
# File: fred-status.sh
# Purpose: Check that fred runs all the 7 required processes
# Author: Torkil Zachariassen
# Date: 20161209
CMD="ps -u fred --no-headers"
count=`$CMD|wc -l`
if [ $count -ne 7 ]; then
echo ERROR Wrong number of processes
$CMD
exit 1
fi
# return ok
return 0
NOTE
$ ps -u fred
should return the following processes
PID TTY TIME CMD
1096 ? 00:01:32 fred-webadmin
1181 ? 00:00:03 fred-logd
1182 ? 00:00:00 fred-rifd
1217 ? 00:00:00 fred-pifd
1218 ? 00:00:01 fred-adifd
3574 ? 00:00:00 fred-msgd
3685 ? 00:00:05 fred-pyfred
#######################################################################
It seems that the problem are the following lines in fred-* in
/lib/systemd/system:
# grep /fred/fred /lib/systemd/system/fred-*
/lib/systemd/system/fred-adifd.service:ExecStart=/usr/sbin/fred-adifd
-ORBendPoint giop:tcp::2222 -ORBnativeCharCodeSet UTF-8 --config
/etc/fred/fred-adifd.conf
/lib/systemd/system/fred-logd.service:ExecStart=/usr/sbin/fred-logd
-ORBendPoint giop:tcp::2226 -ORBnativeCharCodeSet UTF-8 --config
/etc/fred/fred-logd.conf
/lib/systemd/system/fred-msgd.service:ExecStart=/usr/sbin/fred-msgd
-ORBendPoint giop:tcp::2228 -ORBnativeCharCodeSet UTF-8 --config
/etc/fred/fred-msgd.conf
/lib/systemd/system/fred-pifd.service:ExecStart=/usr/sbin/fred-pifd
-ORBendPoint giop:tcp::2223 -ORBnativeCharCodeSet UTF-8 --config
/etc/fred/fred-pifd.conf
/lib/systemd/system/fred-rifd.service:ExecStart=/usr/sbin/fred-rifd
-ORBendPoint giop:tcp::2224 -ORBnativeCharCodeSet UTF-8 --config
/etc/fred/fred-rifd.conf
as these references configuration files in /etc/fred, whereas the actual
configuration
files are installed in /etc/init
As I am unsure of what the correct solution might be I will leave this
issue to the packager
Have a nice day :-)
Hi!
The better way for us was made a Django ApiRest for our front based in PHP Synfony2. You can import fred-client lib and use it into your ApiRest.
Best regards,
Agustin Sacramento
-----Original Message-----
From: fred-users [mailto:fred-users-bounces@lists.nic.cz] On Behalf Of Jaromir Talir
Sent: Friday, November 11, 2016 13:34
To: A mailing list for users and developers of FRED registry system
Subject: Re: PHP API
Hi,
there is nothing I'd know about for immediate use. It would be great if somebody from community of users would make it. We don't have PHP programmers in our company.
Regards,
Jaromir
On Sun, 2016-11-06 at 14:12 +0200, Mark Elkins wrote:
> Better still - open sourced, readable and commented code of an API
> written in PHP.
>
> On 06/11/2016 13:14, Thiago Farina wrote:
>> Is there a PHP API for the Python fred client?
>>
>> --
>> Thiago Farina
> _______________________________________________
> fred-users mailing list
> fred-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
--
Jaromir Talir
Technicky partner / Technical Fellow
-------------------------------------------
CZ.NIC, z.s.p.o. -- .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republicmailto:jaromir.talir@nic.cz http://nic.cz/ sip:jaromir.talir@nic.cz tel:+420.222745107
mob:+420.739632712 fax:+420.222745112
-------------------------------------------
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
I'm writing some words on my understanding of Premium Domain Names - and
am not sure about FRED....
Quick question:
Does FRED implement the code to specify that "these names" are premium
names and therefore cost more. The Registrar also needs a slight EPP
code modification in that they must provide the (expected) cost of the
domain to the Registry - in order to confirm its premium status - and I
guess - the correct cost.
In order for the Registry to implement this, one might need to perhaps
provide a file of "regular expressions" which if met - would imply the
Domain Name is Premium... could even add a second column as the cost?
eg
. (to match one character)
.. (to match two characters)
... (to match three characters)
green ( and other "generic" names)
blue
sexy
travel
hotel* (hotel, hotels, hotel-bookings - etc)
Perhaps - do people have a different understanding of "What is a Premium
Domain Name" ?
--
Mark James ELKINS - Posix Systems - (South) Africa
mje(a)posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
1. The update_domain source includes the keyset firld. which is correct:
-----
self.epp.update_domain(get_domain.id.id.name, add_admin=None,
rem_admin=None,
chg={'nsset' : None, 'keyset' : keyset_id, 'registrant' : None,
'auth_info' :
None}, val_ex_date=None, cltrid=None)
-----
But the documentation does not. Checking
https://fred.nic.cz/files/fred/fred.txt, we have this fragment
-----
update_domain(self, name, add_admin=None, rem_admin=None, chg=None,
val_ex_date=None,
cltrid=None)
DESCRIPTION:
The EPP 'update_domain' command is used to update values in the domain.
SYNTAX:
update_domain name [other_options]
OPTIONS:
name (required) Domain name
add_admin Administrative contact ID (unbounded list)
rem_admin Administrative contact ID (unbounded list)
chg Change values
nsset NSSET ID
registrant Registrant ID
auth_info Password required by server to authorize the transfer
val_ex_date Validation expires at
cltrid Client transaction ID
-----
2. The DS generated from the DNSKEY included in keysets, only includes
the algorithm 1 (SHA1) but not 2 (SHA256).
Best.
Mario
We are now prepapring to transfer multiple domains from our 2R registry to registrars now on
the 3R FRED registry for .mw domains.
Could you please tell me the best database command for collecting the auth info for a
domain
Since there appears to be no bulk domain transfer facility in FRED my guess is that we need
to run the database query repeatedly to collect domain & auth-info pairs that we can then
pass on to the registrar.
What is the current best practice for passing auth info details to a registrar?
Regards,
PC
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
We are now prepapring to transfer multiple domains from our 2R registry to registrars
now on the 3R FRED registry for .mw domains.
Could you please tell me the best database command for collecting the auth info for a domain
Since there appears to be no bulk domain transfer facility in FRED my guess is that we
need to run the database query repeatedly to collect domain & auth-info pairs that we
can then pass on to the registrar.
What is the current best practice for passing auth info details to a registrar?
Regards,
PC
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
----------------------------------------------------------
Malawi SDNP Webmail: http://www.sdnp.org.mw
Access your Malawi SDNP e-mail from anywhere in the world.
----------------------------------------------------------
Jaromir, all,
Our FRED registry 3R operation is going well enough that we can now move on to tackle
issues on domain transfers and I have one or two questions with the following understanding
that I have:.
1. My understanding is that: Once auth_info has been sent from current owner A to new
owner B for domain dA.mw then B can do the transfer, such as using fred-client command:
transfer_domain dA.mw auth_info_A [other_options]
Is this correct? what are the other options?
2. A WHOIS query for dA.mw will then list new registrar: B
3. System then generates new auth_info_B and assigns it under registrar B ... right ?
4. How can the registry charge for the transfer of the domain dA.mw?
5. What needs to be configured in FRED to charge for domain transfers like this one?
6. If this FRED config can be done using fred-admin then please show syntax for trhe
fred-admin command to configure charging for domain transfers.
7. If there a similar arrangement for transfering other objects like contacts and/or nssets?
Regards,
Paulos
======================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD
http://www.registrar.mw
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7752 / Virus Database: 4649/12929 - Release Date: 09/01/16
------- End of forwarded message -------
Hi,
I'm using https://github.com/metaregistrar/php-epp-client as the EPP client.
For being able to use it I need to feel some parameters in settings.ini:
interface=eppConnection
hostname=ssl://epp.demo.fred.nic.cz
port=xxxxxx
userid=xxxxxxxx
password=xxxxxxxxx
Which port, userid and password should I use to connect to Fred?
Is it possible to use certificates from https://letsencrypt.org/?
Thanks,
--
Thiago Farina
Hello Piotr,
LOL...
Just about everything. The gTLD is currently on CoCCA and want to move to
a different system.
On Fri, Sep 2, 2016 at 9:15 AM, Piotr Przybył <piotr(a)przybyl.org> wrote:
> On 02/09/16 15:07, Stanford Mings wrote:
> > Hello All,
> >
> > I am working with a gTLD and would like to get some assistance in using
> FRED. I have the system up
> > on a VM in my lab and can access it via the web-admin and the
> fred-client CLI.
> >
> > Any assistance would be greatly appreciated.
> >
> > - Stanford Mings
>
> Hello Standord
>
> "What can I do you for?" ;-)
>
> Are you interested in FRED's features, configuration, ...?
>
> Best regards
> Piotr
>
> _______________________________________________
> fred-users mailing list
> fred-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
>
Hello All,
I am working with a gTLD and would like to get some assistance in using
FRED. I have the system up on a VM in my lab and can access it via the
web-admin and the fred-client CLI.
Any assistance would be greatly appreciated.
- Stanford Mings
Spam detection software, running on the system "mail.nic.cz",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Help, We need to modify some SOA paramenters in zones that
are generated by genzone-client like reduce the TTL since we are now generating
the zone more frequently by cron job. fred-admin which we use to create zones
does not seem to have a feature to midify a zone like this [...]
Content analysis details: (5.5 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available.
[41.77.11.211 listed in bb.barracudacentral.org]
-0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.4839]
1.0 KAM_LAZY_DOMAIN_SECURITY Sending domain does not have any
anti-forgery methods
1.0 HK_NAME_DR No description available.
0.8 KAM_ASCII_DIVIDERS Spam that uses ascii formatting tricks
Hello cz.nic Team
I have a few questions related to database migration of FRED if you don't mind.
====
When trying to download the latest sources from https://fred.nic.cz/page/2904/download/#source I've
realised, that they're not available. E.g. the latest migration scripts are available in
fred-db*deb, but the tarball is not a corresponding one.
Could you please try to release latest sources in tarballs?
====
I've noticed, that upgrade to 2.19.0 creates a table object_state_backup. However, beside DDL from
2.18.0-2.19.0.sql I don't see this table being used anywhere else. Can it be deleted?
====
Could you briefly describe what's the purpose of tables:
contact_address
contact_address_history
As far I can tell after analysing the sources, these tables are populated by a functionality called
from MojeID ( =your special NIC registrar to keep domain contacts defined at central level, not each
registrar's level).
====
What are the following tables for? Or: How the checks of contacts are working? Is is something
related to checking if a contact's address fields are valid?
contact_check
contact_check_history
contact_check_message_map
contact_check_object_state_request_map
contact_check_poll_message_map
contact_test_result
contact_test_result_history
contact_testsuite_map
enum_contact_check_status
enum_contact_check_status_localization
enum_contact_test
enum_contact_test_localization
enum_contact_test_status
enum_contact_test_status_localization
enum_contact_testsuite
enum_contact_testsuite_localization
====
There's a table notification_queue. I can't find any usage of it (maybe because not all tarballs are
up to date). What is it for?
Do you replicate this table using Slony? (Because it has neither primary nor unique key.)
Best regards
Piotr