Hi all Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken. I assume that this step has been taken after some discussion that I myself have been too lazy to follow in this working group, but as I cant manage to find any reference of it in a brief search in the archives and my mailbox that holds mails from a few years, I hope someone in the group can enlighten me about why this step was taken. I have tried to use the webtool, but as it spams *every* person in the LIR contact list with several mails and all the output is jammed together in one long list, I am not really too happy about rewriting all my scripts to some how use the webtool to give me the nessercary output. So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace? /Nina TDC dk.teledanmark
Hi, On Tue, Jan 17, 2012 at 02:04:05PM +0100, Nina Hjorth Bargisen wrote:
So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace?
That would indeed be nice to have. (I'm only using this a few times a year, so I haven't even noticed that it broke down - but for a sanity check on our allocations, asused is indeed very useful) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
That would indeed be nice to have.
Agreed. We have been using this in our IPAM tool to track which subnets have been registered. ____________________________________ Tero Toikkanen Nebula Oy
On 17/01/2012 13:04, Nina Hjorth Bargisen wrote:
Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken.
The attached Really Ugly Hack may work. Or it may not, and it may eat all your data, depending on whether the ALLOC lines in the configuration file are specified correctly or not. It definitely does not taste like chicken. It looks like the semantics of the "-M" flag to the RIPE DB changed. This flag requests more-specific prefixes. Previously, it would accept an address range of the form 192.168.0.0 - 192.168.255.255, but now it insists on using netmask format. I.e. 192.168.0.0/16. This is probably a sensible move for the DB people, although it will cause some old scripts to break. Nick
On Jan 17, 2012, at 3:15 PM, Nick Hilliard wrote:
... It looks like the semantics of the "-M" flag to the RIPE DB changed. This flag requests more-specific prefixes. Previously, it would accept an address range of the form 192.168.0.0 - 192.168.255.255, but now it insists on using netmask format. I.e. 192.168.0.0/16. ...
Hello Nick, Thank you for the patch. Just wanted to clarify the issue over the '-M' query flag. The RIPE NCC would never make a change in functionality like this without getting community approval and proper communication. The syntax of '-M' has not changed at all. As we investigated further, the asused misbehavior is caused by the whois server acting weird with the '-k' flag. We are working to fix that as soon as possible and will have a fix in production very shortly. We will always do our best to keep all existing tools work with the RIPE Database, even when new features are introduced. We know many users have existing tools/processes tied to the current behavior and it is not always easy to migrate from an existing and working toolset to a new one. That's why we are committed to keeping the system backward compatible. All the best, Kaveh. --- Kaveh Ranjbar RIPE NCC Database Group Manager
On 18/01/2012 10:44, Kaveh Ranjbar wrote:
Thank you for the patch. Just wanted to clarify the issue over the '-M' query flag. The RIPE NCC would never make a change in functionality like this without getting community approval and proper communication. The syntax of '-M' has not changed at all. As we investigated further, the asused misbehavior is caused by the whois server acting weird with the '-k' flag. We are working to fix that as soon as possible and will have a fix in production very shortly.
ok, strange: "-M <range>" didn't work when I was testing, but "-M <prefix>/<netmask>" did. And as I mentioned previously, even if the semantics had changed, the hacky workaround I posted isn't a fix, and will break horribly in lots of situations (e.g. non-cidr aligned allocations, incorrectly specified allocations in asused.conf, etc). Anyway, good to hear that there are plans to fix this properly. Nick
Dear Colleagues, The RIPE NCC has fixed the issue that caused the whois server to act strangely in response to queries sent with the '-k' flag. This should also fix the asused functionality problems. I have installed a fresh Debian instance with Debian's asused package and it all works fine on my machine. Please check your installations and contact ripe-dbm@ripe.net if you find any issues or strange behaviors. Sorry for the inconvenience caused by this bug. Kind Regards, Kaveh. --- Kaveh Ranjbar RIPE NCC Database Group Manager On Jan 18, 2012, at 12:01 PM, Nick Hilliard wrote:
On 18/01/2012 10:44, Kaveh Ranjbar wrote:
Thank you for the patch. Just wanted to clarify the issue over the '-M' query flag. The RIPE NCC would never make a change in functionality like this without getting community approval and proper communication. The syntax of '-M' has not changed at all. As we investigated further, the asused misbehavior is caused by the whois server acting weird with the '-k' flag. We are working to fix that as soon as possible and will have a fix in production very shortly.
ok, strange: "-M <range>" didn't work when I was testing, but "-M <prefix>/<netmask>" did. And as I mentioned previously, even if the semantics had changed, the hacky workaround I posted isn't a fix, and will break horribly in lots of situations (e.g. non-cidr aligned allocations, incorrectly specified allocations in asused.conf, etc).
Anyway, good to hear that there are plans to fix this properly.
Nick
Hi Nina, Thanks for bringing up asused. It is a tool that was written and maintained by the RIPE NCC many years ago and later handed to the open source community, where it can be found in packages such as Debian: http://packages.qa.debian.org/a/asused.html This, along with the fact that is was written in a very platform specific manner, is the reason why the tool is no longer actively developed and supported by the RIPE NCC. On the other hand, we have always kept the existence of asused in mind, which means that we would never intentionally change anything to our (whois) configuration that would break asused. I want to assure you that we'll try to fix any issue that you may have on a best effort basis. We have recognised the wish from the Community for the functionality that asused provides. Currently we offer this in the shape of Web Asused: http://www.db.ripe.net/cgi-bin/webasused.pl.cgi The advantage of offering it like this is that we control the platform on which the tool runs, making it manageable and maintainable. However, it comes with obvious downsides that you have mentioned. This is why we are currently developing a new implementation of the asused functionality that resides in the LIR Portal. The advantage of this is that it allows for a much more comprehensive overview of the address space, because it can use internal Registry data and doesn't solely rely on the public RIPE Database. To make sure this integrates with your current workflow, we understand that you wouldn't want to be locked into (solely) using the LIR Portal web interface. This is why we will offer an API to make sure you can script against it. You can expect the first iteration of this functionality to appear in the LIR Portal within just a couple of weeks. We want to work with you and everybody else who is depending on this functionality to make it as useful and seamless as possible. As always, we appreciate and look forward to your input. Kind regards, Alex Band Product Manager RIPE NCC On 17 Jan 2012, at 14:04, Nina Hjorth Bargisen wrote:
Hi all
Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken.
I assume that this step has been taken after some discussion that I myself have been too lazy to follow in this working group, but as I cant manage to find any reference of it in a brief search in the archives and my mailbox that holds mails from a few years, I hope someone in the group can enlighten me about why this step was taken.
I have tried to use the webtool, but as it spams *every* person in the LIR contact list with several mails and all the output is jammed together in one long list, I am not really too happy about rewriting all my scripts to some how use the webtool to give me the nessercary output.
So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace?
/Nina
TDC dk.teledanmark
Hi Alex It is indeed good news that you are working on a version that we can script against. The webtool is not at all usefull to us. Please let us know when the scripting API can be available, for us that is much more urgent than another webbassed tool in the LIR portal. An additional feature to the old versions of asused would be a possibility to get an invalid list from the tool, which I supposed will be possible when you transfer the implementation to use the internatl registry data as well. /Nina On 17.01.2012 15:25:02 +0100, Alex Band wrote:
Hi Nina,
Thanks for bringing up asused. It is a tool that was written and maintained by the RIPE NCC many years ago and later handed to the open source community, where it can be found in packages such as Debian: http://packages.qa.debian.org/a/asused.html
This, along with the fact that is was written in a very platform specific manner, is the reason why the tool is no longer actively developed and supported by the RIPE NCC. On the other hand, we have always kept the existence of asused in mind, which means that we would never intentionally change anything to our (whois) configuration that would break asused. I want to assure you that we'll try to fix any issue that you may have on a best effort basis.
We have recognised the wish from the Community for the functionality that asused provides. Currently we offer this in the shape of Web Asused: http://www.db.ripe.net/cgi-bin/webasused.pl.cgi The advantage of offering it like this is that we control the platform on which the tool runs, making it manageable and maintainable. However, it comes with obvious downsides that you have mentioned.
This is why we are currently developing a new implementation of the asused functionality that resides in the LIR Portal. The advantage of this is that it allows for a much more comprehensive overview of the address space, because it can use internal Registry data and doesn't solely rely on the public RIPE Database. To make sure this integrates with your current workflow, we understand that you wouldn't want to be locked into (solely) using the LIR Portal web interface. This is why we will offer an API to make sure you can script against it. You can expect the first iteration of this functionality to appear in the LIR Portal within just a couple of weeks. We want to work with you and everybody else who is depending on this functionality to make it as useful and seamless as possible.
As always, we appreciate and look forward to your input.
Kind regards,
Alex Band Product Manager RIPE NCC
On 17 Jan 2012, at 14:04, Nina Hjorth Bargisen wrote:
Hi all
Last year I learned - by asking around - that the asused tool commandline script was no longer supported by RIPE - that was after not being able to find it on the usual ftp site. We have since managed to get by with an old copy but now it seems that this is no longer able to get output from the RIPE db and hence all our adress usage and other homemade scripts are now broken.
I assume that this step has been taken after some discussion that I myself have been too lazy to follow in this working group, but as I cant manage to find any reference of it in a brief search in the archives and my mailbox that holds mails from a few years, I hope someone in the group can enlighten me about why this step was taken.
I have tried to use the webtool, but as it spams *every* person in the LIR contact list with several mails and all the output is jammed together in one long list, I am not really too happy about rewriting all my scripts to some how use the webtool to give me the nessercary output.
So - Is there *ANY* chance of somehow get support of a similar tool to the old asused used, that one can install and run from our own box and with the support of the same options as before or does all tools now focus on small LIRs with very and hence very easily manually managed addressspace?
/Nina
TDC dk.teledanmark
Hi Alex, On 17/01/2012 14:25, Alex Band wrote:
Thanks for bringing up asused. It is a tool that was written and maintained by the RIPE NCC many years ago and later handed to the open source community, where it can be found in packages such as Debian: http://packages.qa.debian.org/a/asused.html
This, along with the fact that is was written in a very platform specific manner, is the reason why the tool is no longer actively developed and supported by the RIPE NCC. On the other hand, we have always kept the existence of asused in mind, which means that we would never intentionally change anything to our (whois) configuration that would break asused. I want to assure you that we'll try to fix any issue that you may have on a best effort basis.
Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation. This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time. This is not a criticism of changing the DB interface or anything, btw - progress needs to happen. In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications. There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them. OTOH, webasused can be very slow. E.g. I submitted a request for a LIR at 15:28 GMT today, and got a reply at 15:39. This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied). The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs. And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments. I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6. Nick
On 17/01/2012 16:21, Nick Hilliard wrote:
Hi Alex, Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation. This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time. This is not a criticism of changing the DB interface or anything, btw - progress needs to happen.
In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications. There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them.
OTOH, webasused can be very slow. E.g. I submitted a request for a LIR at 15:28 GMT today, and got a reply at 15:39. This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied).
The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs. And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments.
I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6.
Nick, Alex et al At the Board meeting on the 8th December the board gave Axel an action "to reinstate/redevelop the stand-alone version of the RIPE NCC ASused tool" I doubt that this action would be satisfied merely by the provision of an API into the webasused tool. Alex, you may like to check this with Axel. It is possible that it was misunderstood by him, but it is very clearly minuted. And I'd agree with Nick that lack of platform portability is one of the few brickbats that cannot be aimed atperl. Nigel
Nigel Thank you - a stand alone tool is much preferred over API. I look forward to get my scripts working again Rgds Nina On 17.01.2012 16:58:03 +0000, Nigel Titley wrote:
On 17/01/2012 16:21, Nick Hilliard wrote:
Hi Alex, Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation. This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time. This is not a criticism of changing the DB interface or anything, btw - progress needs to happen.
In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications. There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them.
OTOH, webasused can be very slow. E.g. I submitted a request for a LIR at 15:28 GMT today, and got a reply at 15:39. This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied).
The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs. And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments.
I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6.
Nick, Alex et al
At the Board meeting on the 8th December the board gave Axel an action "to reinstate/redevelop the stand-alone version of the RIPE NCC ASused tool"
I doubt that this action would be satisfied merely by the provision of an API into the webasused tool.
Alex, you may like to check this with Axel. It is possible that it was misunderstood by him, but it is very clearly minuted.
And I'd agree with Nick that lack of platform portability is one of the few brickbats that cannot be aimed atperl.
Nigel
participants (7)
-
Alex Band -
Gert Doering -
Kaveh Ranjbar -
Nick Hilliard -
Nigel Titley -
Nina Hjorth Bargisen -
Tero Toikkanen