The next speaker is Antonio Torres.
He watches as part of a creative project.
He's going to talk about DNS.
He's one of the services that we maintain
and automate in the creative system.
So Antonio, you're welcome.
Thank you.
So first of all, can you hear me in the back?
It's OK, it's perfect.
So yeah, I'm Antonio Torres.
As to when you said, I work for Red Hat,
the free IP project.
And this is basically what I've been working in the last few months.
So if you see this title, probably your first question,
if you're not familiar with the project,
is what is behind the end of the buildup
and what's up with this weird name.
So yeah, do we now understand
soon what's the ring of the name
because actually it's a pretty descriptive name?
It's a bit weird, but it works.
So first, before explaining what it is,
I need for people that are not familiar with the IPA.
I need to explain that to you.
So it's basically an identity management service.
So you can handle users, holes, groups, things like that.
So it obviously depends on LDAP and we also provide service
for DNS.
So there is a very basic FAAP server here, actually,
we provide a lot more services than those two.
But those are some of the main ones.
Yeah, so for DNS, where it is in Divine Server,
the DNS server that is going to bind
and we're also using LDAP.
So now you can see two of the three parts of the name.
It's bind, LDAP.
Now I'll explain DINDB.
So first of all, what it does is, it's a plugin
that manages this inclination between LDAP and DNS.
So this means that every time you use the IP server
to, for example, manage DNS zone or whatever,
this plugin makes sure that this information
that you're having or you're modifying,
it's synchronized between DNS and LDAP.
So you have this information on both servers.
Yeah, as I said, it's used mainly in FAAP,
but you can use it in a separate project.
In the end, it's just LDAP and DNS.
So if you have or the usage for it, you can use that.
And the main source for the main source of this presentation
and the problem that I explained later,
it's that since this is very low level on the DNS side,
we need access to internal bind API.
So we use exactly the same functions
that the bind developers use on the software.
So there are a few problems with that,
that I'll explain now.
Yeah.
So first, I need to introduce you to the last part of the name.
Finally, so it's the DINDB.
It's just an API that is part of bind.
That basically enables external plugins
to be part of the internal bind server.
So basically, it can be, it's a way to use blinds.
So they behave like if they were part of the blind source code.
So that's what we're using for having access to all those
internal bind features.
And you can see this plugin is really, really easy to use.
Thanks to the really, you only specify the your library
and then you pass your arguments for whatever things you need.
And you are done.
So finally, now we understand the DIN and your project is bind.
DINDB, LDAPS, so DINDB is the thing
when you're in between.
And then you have all the two servers.
Yeah.
So first of all, some is that's about the project.
This is actually a pretty old project.
It's from 18 years ago now.
So it has quite an history.
So we're 15 lines of SQL.
I'll show you some examples later.
And yeah, it's package in multiple distributions.
So as I said, it's a critical component for FAPA.
So that means in every base where you have FAPA,
or you will have bind and DINDB, that it's a critical piece.
So first, I want to introduce you to some of the releases
scheduled for bind because you will see why it's important.
So basically, they have stable ranges, branches,
and every two versions, there's a stable branch
that takes lives for approximately 40 years, more or less.
So the last one, the latest is 1920.
And the one before was 1918.
And that's the latest version that the plugin supports.
So what's the problem with this?
This version is about to become L.
So that means we can not rely on it,
and we need to adapt the plugin to this new server.
You may think, OK, 1918, 20 doesn't seem like a huge change.
It's just a minor version.
So it's not that easy.
So one day, we got a deep ticket.
You can see it's not a very long.
Basically, it's commenting that there was a change upstream,
that removed some headers.
So at first, you may think, OK, some headers.
No biggie.
But after you start looking into it,
you will see that it's not that easy,
because the five that they removed is all the headers
that they had for 100 multi-threading.
So basically, since this is a plugin that
is connecting to server, you obviously need
to need to handle multiple threads.
So this was a critical part of the plugin,
and it's completely removed.
It's all over the code, and it's removed.
It's not as simple header that you can.
Maybe avoid the included, whatever.
It's a very important change.
So that was the first issue.
You will see it's not the only one.
So as I said, it's a very important change.
So that's what the first problem, the second problem
is that we can not forever live on 9-8 thing,
not only because of it being out of support, soon,
but also because we are already good luck to use
some new features of bind 9-20.
So for example, recently, in VAPA,
we introduced a included in a support.
This is so be-read, related to,
obviously related to bind.
But the bad thing is that we would like to use
a file string DNS, included DNS for a wording,
that is available in bind 9-20, but not in 9-8 things.
So we had to do some work around for now.
Yeah, the second problem, the bind 9-10 developed,
as you showed, is a really old,
and it's very difficult to maintain.
So it's a C code that is, let's say,
it's not the best written code.
Yeah, there are some issues with it.
I'll show you some examples later.
There's maybe some of you may see already
a problem here, and it's that we can adapt the plugin now
for 9-4, version 9-20, but in the future,
maybe we have this in problem again.
With 9-22 or 24 or whatever.
So yeah, I will talk about later.
So whatever, the decision was to play widely completely.
So there was this change for the opportunity
to, since we have to completely replace all the,
all the synchronous interface.
There was this opportunity to actually
re-organize the project, and try to make it more maintainable,
more easy to understand.
So yeah, we did that, or we're doing that.
We're trying to adapt as much code,
so I'm talking about the synchronous interface,
but actually there were some multiple changes.
Since we had using the internal bind 8-8 bind developers,
changed the functions to whatever they need.
That's fine.
But that means that we also need to do those changes,
and after trying to build with this new version,
we found a lot of functions that were deprecated
and then removed, or arguments change it,
and whatever, and all those need fixes.
And last of all, we actually took the opportunity
to change the license of the project.
I'll explain later.
Okay, so I'm going to explain the new architecture,
and you will see it's actually really simple,
because we are looking for a really simple plugin
that just works.
So there will be one main thread that will run the plugin,
and then you have multiple threads,
only for reading or for writing, from and to elder,
from and to DNS.
So the main thread will run a logic,
just synchronize the information.
We do one thread on the other,
and those threads are only readers or writers.
So they only have one work,
and they only need to do that, nothing else.
And we are all doing this using this new interface.
I'm mentioning, so this is actually a really nice feature
from bind, so it's a good change, they did.
It's too bad they broke out, but yeah, that's how it is.
It's a really nice change, actually.
So you will see it's really,
the architecture is really simple, actually.
So this is a show in the reading from LDAP.
So you see, we are just reading,
send it to the worker,
do whatever we need, and then you have it in the main thread,
and you can do Jordan, okay?
And the other way around is exactly the same.
You have the notification, you write it to LDAP,
and you are done, it's really simple.
So I'm going to show you some examples of changes with it,
and where I'm talking about this,
plugin being difficult to maintain.
So for example, this is one example
that actually most of the code,
so I mentioned the code, it was about 15,000 lines long.
So, 5000 of those was in one single file,
so that's one third of the project in one file.
And that's commonly not very good.
So there was also the issue, this was a general issue
with all the files, the source files,
those were all in the same folder.
So no file structure at all.
So we actually managed to properly sort
and divide all these different files into files that make sense.
And other issue we had was the naming for the functions.
So since this is acting as a plugin for bind,
we need to be really careful with the naming for the functions
to avoid any kind of collision or whatever.
So there was this issue that really the naming
for the functions had no convention at all.
It was whatever the developer at the time
decided at the moment.
And you can see that is really no any.
And there is no prefix and the names themselves
are not really discrete.
So we did a complete renaming of all the functions.
We included this prefix BDL, so that's binding the VL app
to make sure that there are no conflicts.
And actually while doing this change,
we actually had a bug that there was one of the functions.
So first, we didn't use this BDL prefix.
So we were just doing, for example,
L app pool in it or L app new connection.
And this actually there was actually one collision
with the open L app library.
And there was this difficult to find bug.
So they were trying to avoid those kind of things.
So we'll just use this BDL prefix.
So other things we had in this old plugin
was that since it was within 18 years ago,
there's been a lot of different bind versions since then.
So there was a lot of checks all over the code
for obsolete versions that we are not going to support anymore.
I have not been supporting for a long time now.
So we can remove all that code,
and just have a more tidy code base.
Yeah, this is actually funny.
So there were a lot of two new messages left a long time ago.
And you can see some of them are not really difficult.
No, no difficult things to implement,
but they were just forgotten.
So for example, to do lock something,
to do verify this.
You know, it's things that you really should do
in a production environment, right?
So yeah, we did take care of this,
remove whatever was not needed,
and address whatever we needed to fix.
And lastly, I mentioned earlier the changes in the bind API.
So as I said, apart from this big change,
the synchronous interface,
there were a lot of minor changes
in the internal functions they used.
And obviously we needed to fix a dose.
So I'm going to give you some examples.
So sorry.
So since these are internal functions,
they are understood by bind developers only, basically.
So those are not to be supposed not supposed to be used
by people, people outside the project, really.
So in some cases, the only documentation
available was the actual commit lock.
So for I was just reading all the divs in the commits,
looking at the code itself and the stand in the changes
and then doing the changes in our applying.
So there wasn't really much documentation
about these changes.
So the only way to do it was to really
the code itself.
So yeah, some people may think, okay,
you're basically renaming functions, adapting code.
That sounds like I would go to stage of IA.
So yeah, why didn't you try it?
So we tried and I'm going to show you some of our findings.
I think you will have fun with this.
So we use, we're using this prompt
that is expanding the issue basically and just,
so try to ask the A what was changed
and how should we fix it, okay?
So we're going to try with three different clients.
One is chat, EPD.
Gemini, I am finally on the most promising one.
Cloth, so let's see.
First, chat, GPD.
It was actually somehow able to find
that their sync library was changed it
and we needed to adapt to that.
And it was actually able to understand
that it's not a trivial change.
So it was able to detect that it was a typical change.
But then what was the proposed solution?
The move, whatever it's not working.
Elab call back, Nul.
There is no call back, no problem.
Here there's the move, okay, remove the includes
and it's fixed.
So obviously this is not a proper solution.
Next, we went with Gemini
and this was funnier, I think,
because it actually was mentioned
in that where some commits in our plugin log messages
that already fixed the issue.
So basically we already fixed the issue
but we forgot about it and it was proposed
in some commit hashes for this change.
So please tell me, it came up with three commits
that obviously are completely fantasy.
They don't exist, the commit message is invented.
The hashes does not exist, it's completely fantasy.
So yeah, I wish they existed but they do not.
So yeah, finally Claude.
So we have been told that Claude is the best AI
for coding and for this kind of things.
So we should really try and let's see if it can do
whether that chatipity and Gemini.
So this was fun because the other two took maybe a minute
to reply so they were quick.
But in the case of Claude, it actually looked like it was
trying to understand the changes.
So it took like 30 minutes asking questions.
Hey, can I query this web page?
Hey, can I do this change?
Can I run this comment?
Can I install this package?
So it was like 30 minutes and it said, okay,
I will prepare an analysis document
without the things I found.
And then you can follow these steps,
so you can fix your issue.
Yeah.
So basically it had good news, apparently.
And that's that most of the 1920 changes
don't affect this code base.
Obviously it's a lie.
I wish that was the case but it says that the planning
is an usage using those byte libraries
and all the current IPA usage remains compatible.
It's obviously lie.
So it was actually found so misuse,
but those are really not major issues.
So there was an undefined autocomph macros,
obviously minted but not no big deal.
And also this one thing, it was actually able to identify
and that's the for future proofing,
the database transition to from air ready to keep it
so that's actually something that we need to do
in the future, but again, it's not the main issue.
It's yes, nice to have in the future.
So yeah, it's basically the same result of the other two,
but wait in 30 minutes.
We had actually, we had actually one team member
tried to, we've got tried to give it more context.
So it actually maybe understood better.
The context.
So and in the end, it did the same.
Remove the old decode that was not working.
So yeah, it's basically the same after the other two,
but taking two hours more.
Yeah.
So anyways, forgetting about AI,
we now have a version of the planning
that is compiling and is some working.
I mean, so how because we still need to do a lot of testing.
So the good thing is that we actually have a lot of tests
because of the IPA, so we have a lot of different scenarios
to test and things to check.
So that's what we're doing now.
Just running the test, see where it's failing,
where it's not, what it's working, and where it's not working,
and just trying to address those issues.
So this is something that is really helpful.
Having that suite of tests to actually try to code all the code.
In the future, we also want to make use of some performance testing.
We have a project in VIPA that is able to run tests
for almost everything in VIPA.
So we can, for example, add 1,000 DNS zones
and see how fast it is performing,
compiling to the last version.
I hope it's faster because of this new asynchronous interface.
With it.
So for the future, we have two options.
So I'm going to actually explain the reason
why we change the plugin license.
So the change was to match the upstream bind.
And the idea is that maybe in the future
this plugin can be part of the upstream bind
to the repository, I think this can be useful for both sides.
So for bind, they get an important feature
that a lot of customers are looking for.
For us, we can ensure that the compatibility remains safe
between every release.
So basically, the bind is taking into account for every change.
And there's actually this nice message
from the documentation that the DINDVAPI was contributed
by Redhat.
They were a person in the past and this is a little thank you.
So there's a share with that.
There was actually more contributions in the past.
So if for whatever reason, this is not possible,
we would like for bind to have a some kind of external API
so that that can remain stable.
And we can use that instead of using the internal API.
And there's actually a draft in upstream bind.
So we will try to talk with the developers
and try to make sure that this future API contains all the features
that we need for the plugin.
So yeah, thank you.
.
So we have the same for questions.
So any confused.
So, it's going to be a replace, oh yeah, the question. So, this person saw the discussion about this in the
December millilist and he's asking whether it will work with somebody in future versions.
So, the idea is for this to be a one-to-one replacement to the old plug-in. So, whatever
thing that worked in the old plug-in will work in this version. So, we are not removing
support for anything.
I was, I was, I was expecting the question.
So, the idea is still, the old G is still not located by anybody, it will be.
So, it's a different one. So, it's a different one.
Yeah.
So, what anyway, yeah, I mean the trends from mine we all have been all used to was in the five,
under the years, the number of people who support it.
Yeah, very fascinating based on their customers, and every time they release something new.
Yeah.
So, we were forced to write a word in terms of plug-in, or held up.
Oh, yes.
Yeah, we were forced to write the entire plug-in in order to support a new version of mine.
That is coming with new features like, for wording, I stuff like that.
For the reasons like features like, I've greeted you in as that Antonio mentioned at the very beginning.
But yeah, this is solving the problem for us for five years maybe.
And then at some point, there will be a new version of mine, and then we will need to check again the plug-in.
So, at least now, we have time to talk to mine and see if we can collaborate.
Either way, the option one that Antonio mentioned is to send the plug-in to them.
So, they can integrate in the proper way. So, every time they release something new, they make sure it works.
And the other way is perhaps they could improve or expose more stuff through an external API that somehow and free-pay we could use or rely on.
So, that we don't break every time they release a mine new version.
So, we can continue discussing because we, the time is up.
We have another talk now.
So, thank you. Thank you.
Thank you.