Re: cloud-set-guest-password script for CentOS 7 template

[Jeff Moody]

I have SystemD Unit files as well as scripts that work under EL7 located
in my template-building Ansible Playbook repository located at
https://github.com/fifthecho/CloudStack-Template

On 9/3/2015 3:20 AM, christian.kir...@zv.fraunhofer.de wrote:
> Hi,
> 
> I encountered a similar issues, although I'm still not quite as far as you 
> building a systemd script.
> I also changed the script to the right directory for the lease files.
> When the vm starts it takes approximately 15 minutes to be ready, that must 
> have something to do with the script, but I’m not quiet sure if it is the 
> password script or the ssh key script, which I also installed in the template.
> In the next couple days I’ll take some time for that script, maybe I get some 
> steps further.
> 
> If someone has already the solution, it would be great. 
> 
> Kind Regards
> Christian
> 
>> On 03 Sep 2015, at 08:59, Indra Pramana  wrote:
>>
>> Dear all,
>>
>> Anyone has tried creating CentOS 7 OS template in CloudStack and
>> experiencing similar problem?
>>
>> Thank you.
>>
>> -ip-
>>
>>
>> On Wed, Sep 2, 2015 at 1:25 PM, Indra Pramana  wrote:
>>
>>> Dear all,
>>>
>>> I am using ACS 4.2.0 with KVM hypervisor. I am trying to create a CentOS 7
>>> template and everything is running fine except the CloudStack password
>>> reset script template.
>>>
>>> CentOS 7 is using systemd so I have created the required
>>> /usr/lib/systemd/system/cloud-set-guest-password.service as follows:
>>>
>>> ===
>>> [Unit]
>>> Description=Cloudstack set guest password
>>> After=network.target
>>>
>>> [Service]
>>> Type=oneshot
>>> User=root
>>> Group=root
>>> ExecStart=/etc/init.d/cloud-set-guest-password start
>>> Type=forking
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>> ===
>>>
>>> I also modified the /etc/init.d/cloud-set-guest-password slightly since
>>> CentOS 7 is using NetworkManager by default:
>>>
>>> ===
>>> # Add your DHCP lease folders here
>>> DHCP_FOLDERS="/var/lib/NetworkManager/*"
>>> ===
>>>
>>> The script is running perfectly fine if I run it manually. However, it
>>> doesn't seem to be started automatically upon boot-up even though I have
>>> enable it via systemctl.
>>>
>>> ===
>>> [root@test-centos7-20150819 ~]# systemctl enable
>>> cloud-set-guest-password.service
>>> ln -s '/usr/lib/systemd/system/cloud-set-guest-password.service'
>>> '/etc/systemd/system/multi-user.target.wants/cloud-set-guest-password.service'
>>>
>>> [root@test-centos7-20150819 ~]# systemctl status
>>> cloud-set-guest-password.service
>>> cloud-set-guest-password.service - Cloudstack set guest password
>>>   Loaded: loaded
>>> (/usr/lib/systemd/system/cloud-set-guest-password.service; enabled)
>>>   Active: inactive (dead)
>>> ===
>>>
>>> Anyone has similar experience before? How to ensure that the script can be
>>> executed during boot-up so that the password will be changed?
>>>
>>> Thanks in advance.
>>>
>>> -ip-
>>>
> 

Re: Cloudstack Repackaging / Distro support

[Jeff Moody]

Also a good idea, but would be yet another package to be maintained...albeit a 
small one.
Might be easier to release a pair of Ansible playbooks/Chef cookbooks/Puppet 
manifests/etc.

On Tue, 2015-05-12 at 15:11 +0200, Erik Weber wrote:
> How about bundling the httpd/nginx configuration in a separate 
> optional
> package?
> I have no idea for a name, but it could depend on either httpd and 
> nginx,
> and include a site config that works out of the box.
> 
> Should work great for those who need an easy setup, and still allow 
> those
> who set up external loadbalancers to do as before.
> 

Re: Cloudstack Repackaging / Distro support

[Jeff Moody]

I'd say a safe middle-ground might be providing a working proxy config
for Apache and for nginx in the docs or share directories and then
pointing to those in the documentation as references to get the API
proxied on 80/443.

I do agree with leaving the default on 8080 as that's the default for
Tomcat and a LOT of CloudStack drivers for different tools default to
that port.

On Tue, 2015-05-12 at 14:47 +0200, Rafael Fonseca wrote:
> I'll stay away from touching port 80 for now, but isn't saving work 
> to the
> admin one of cloudstack's main goals?
> 
> That is also the main reason to package this stuff and have rules for
> configuration :)
> 
> I do see a lot of people complaining that cloudstack is hard to 
> setup and
> has very long setup guides and a lot of stuff doesn't work on certain
> environments... i aim to put an end to that.. hopefully even the 
> dumbest
> sysadmin will be able to get it up and running without much effort 
> by the
> time i'm done :) . The effort reduction is also always valid for
> experienced sysadmins and developers ;)
> 
> 
> 
> 
> On Tue, May 12, 2015 at 1:16 PM, Wido den Hollander  
> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > 
> > 
> > On 05/12/2015 12:03 PM, Rafael Fonseca wrote:
> > > Wido,
> > > 
> > > If we were to recommend proxying with httpd, shouldn't cloudstack
> > > provide that as well out of the box?
> > 
> > I'd stay away from that. Providing that out of the box means doing
> > more stuff which an admin should do.
> > 
> > Wido
> > 
> > > Btw, there isn't really a big performance gain by proxying 
> > > through
> > > httpd nowadays, the new version of the packaging also includes
> > > using tomcat8, which has an improved http/nio connector, have a
> > > look here for some performance benchmarks :) ->
> > > http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one
> > > -should-a
> > lways-use-apache-httpd-front-apache-tomcat-improve-perform
> > > 
> > >  What i think is that if we are going to suggest configuring 
> > > httpd
> > > on the same box we should do it automatically, if not, tomcat can
> > > still run on port 80 by default and user can reverse proxy from 
> > > any
> > > other machine :)
> > > 
> > > Also, if we're sticking to tomcat, we should have scripts build
> > > the APR/native connector for improved performance :)
> > > http://tomcat.apache.org/native-doc/
> > > 
> > > This would be an improvement independent from using or not
> > > httpd/nginx in front of tomcat.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Tue, May 12, 2015 at 11:45 AM, Wido den Hollander
> > >  wrote:
> > > 
> > > 
> > > 
> > > On 05/12/2015 11:37 AM, Erik Weber wrote:
> > > > > > On Tue, May 12, 2015 at 10:59 AM, Rafael Fonseca
> > > > > >  wrote:
> > > > > > 
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I'm reworking the packaging system in cloudstack, and 
> > > > > > > would
> > > > > > > like to gather your opinion on the following:
> > > > > > > 
> > > > > > > - Fedora 2x runs systemd's cockpit on port 9090 by 
> > > > > > > default
> > > > > > > This is a deal breaker for the cluster servlet port on 
> > > > > > > this
> > > > > > > OS, the two possibilities would be to either pack changes
> > > > > > > to fedora's config on rpm install or simply change the
> > > > > > > servlet port to another one that does not clash on any
> > > > > > > distro.. any comments/suggestions?
> > > > > > > 
> > > > > > > - Tomcat is not listening on port 80 Tomcat is using port
> > > > > > > 8080, which makes the user have to specify that in the
> > > > > > > browser.. should we change it? In ubuntu it's already
> > > > > > > running under jsvc, so it shouldn't be a problem.. same 
> > > > > > > can
> > > > > > > be arranged for centos/other distros.
> > > > > > > 
> > > > > > 
> > > > > > Is it possible to ask the user for this during installation
> > > > > > and default to either 80 or 8080? I know Debian has a way 
> > > > > > to
> > > > > > interact with the user during install, not sure about
> > > > > > RedHat.
> > > > > > 
> > > > > > I don't know the rationale behind putting it on port 8080 
> > > > > > in
> > > > > > the first place, but personally I don't see a problem 
> > > > > > moving
> > > > > > it to port 80.
> > > > > > 
> > > 
> > > I'd say to stick to 8080 and recommend anybody to use Apache /
> > > Nginx to proxy towards Tomcat.
> > > 
> > > > > > 
> > > > > > > - No link on the tomcat root (http://management-server/
> > > > > > >  can
> > > > > > > link internally to http://management-server/client , this
> > > > > > > makes it easier for new users who don't know the URL for
> > > > > > > the UI :)
> > > > > > > 
> > > > > > > 
> > > > > > Sounds like a good idea to me, I always forget to add 
> > > > > > /client
> > > > > > when I browse to new installations.
> > > > > > 
> > > > 
> > > 
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> > 
> > iQIcBAEBAgAGBQJVUeEFAAoJEAGbWC3bPspCupwQAJjU6Akq18N9QcPYiOK60NR5
> > P9

Re: RFC: Removing 1M lines of junk

[Jeff Moody]

Rohit,

I understand and have no issues with this, however, I can forsee parts
of our support organization wanting a binary package (from Citrix)
when this change hits.

I was just adding my $0.02 to the discussion of "does anyone use the
AWS API" and expressing that my employer has little to no concern over
this change (especially if removing the 1M lines of junk helps make a
faster, more reliable management server).

On Fri, 2015-05-01 at 13:23 +, Rohit Yadav wrote:
> Hi Jeff,
> 
> Thanks for sharing. ec2stack is available from pypi, so while we can 
> build debs/rpms it can be easily installed using “pip install 
> ec2stack”. The only migration path required by your users would be 
> to change the consumer URL and re-register apikey/secretkey.
> 
> > On 01-May-2015, at 3:11 pm, Jeff Moody  wrote:
> > 
> > As this change will likely affect Citrix CloudPlatform, I can say 
> > that
> > at Datapipe we offer the AWS API endpoint to customers because we 
> > had
> > a request for it in the past. It was used once by a customer who 
> > then
> > changed to using the native CloudStack API. When this change hits a
> > release of Citrix CloudPlatform, I'm sure we'll probably deploy
> > ec2stack, but I don't see that (and our support team doesn't see 
> > that)
> > as a real problem - especially if RPM/Debs of the ec2stack code 
> > can be
> > built and distributed.
> > 
> > On Fri, 2015-05-01 at 14:10 +0200, sebgoa wrote:
> > > On May 1, 2015, at 12:02 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com>
> > > wrote:
> > > 
> > > > OK, I do not want to push a formal point, just warning.
> > > > 
> > > 
> > > understood. let's see if other folks are worried about 
> > > ec2interface
> > > upgrade/change.
> > > 
> > > > Op vr 1 mei 2015 om 09:57 schreef Wido den Hollander <
> > > > w...@widodh.nl>:
> > > > 
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA1
> > > > > 
> > > > > 
> > > > > 
> > > > > On 01-05-15 09:17, sebgoa wrote:
> > > > > > 
> > > > > > On Apr 30, 2015, at 11:06 PM, Rohit Yadav
> > > > > >  wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > > On 30-Apr-2015, at 7:43 pm, Daan Hoogland
> > > > > > > >  wrote:
> > > > > > > > 
> > > > > > > > We will have to provide a migration path if anybody is
> > > > > > > > actually
> > > > > > > > using it.
> > > > > > > 
> > > > > > > The migration path would be documenting the change as 
> > > > > > > part
> > > > > > > of the
> > > > > > > release notes to simply switch from using the consumer 
> > > > > > > URL
> > > > > > > server_ip:7080/awsapi to setting up ec2stack and 
> > > > > > > consuming
> > > > > > > from
> > > > > > > URL server_ip:5000 (or any other configured port). 
> > > > > > > Normally
> > > > > > > service offerings are rather limited compared to other
> > > > > > > resources,
> > > > > > > when setting up ec2stack users can provide the mapping 
> > > > > > > to it
> > > > > > > or
> > > > > > > migrate it to ec2stack using something custom like
> > > > > > > cloudmonkey+bash.
> > > > > > > 
> > > > > > > The important issue to note here is that a lot of real
> > > > > > > -world
> > > > > > > awsapi integration with a user's own subsystems may not
> > > > > > > follow
> > > > > > > any convention or be rather customised other than
> > > > > > > consumption of
> > > > > > > service URL and associated apikey/secretkey, so migration
> > > > > > > path
> > > > > > > from our end would mostly consist of documenting the 
> > > > > > > changes.
> > > > > > > This upgrade path may also be implemented as a script or 
> > > > > > > a
> > > > > > > ec2stack tool that can re

Re: RFC: Removing 1M lines of junk

[Jeff Moody]

As this change will likely affect Citrix CloudPlatform, I can say that
at Datapipe we offer the AWS API endpoint to customers because we had 
a request for it in the past. It was used once by a customer who then
changed to using the native CloudStack API. When this change hits a
release of Citrix CloudPlatform, I'm sure we'll probably deploy
ec2stack, but I don't see that (and our support team doesn't see that)
as a real problem - especially if RPM/Debs of the ec2stack code can be
built and distributed.

On Fri, 2015-05-01 at 14:10 +0200, sebgoa wrote:
> On May 1, 2015, at 12:02 PM, Daan Hoogland  
> wrote:
> 
> > OK, I do not want to push a formal point, just warning.
> > 
> 
> understood. let's see if other folks are worried about ec2interface 
> upgrade/change.
> 
> > Op vr 1 mei 2015 om 09:57 schreef Wido den Hollander <
> > w...@widodh.nl>:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > > 
> > > 
> > > 
> > > On 01-05-15 09:17, sebgoa wrote:
> > > > 
> > > > On Apr 30, 2015, at 11:06 PM, Rohit Yadav
> > > >  wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > > On 30-Apr-2015, at 7:43 pm, Daan Hoogland
> > > > > >  wrote:
> > > > > > 
> > > > > > We will have to provide a migration path if anybody is 
> > > > > > actually
> > > > > > using it.
> > > > > 
> > > > > The migration path would be documenting the change as part 
> > > > > of the
> > > > > release notes to simply switch from using the consumer URL
> > > > > server_ip:7080/awsapi to setting up ec2stack and consuming 
> > > > > from
> > > > > URL server_ip:5000 (or any other configured port). Normally
> > > > > service offerings are rather limited compared to other 
> > > > > resources,
> > > > > when setting up ec2stack users can provide the mapping to it 
> > > > > or
> > > > > migrate it to ec2stack using something custom like
> > > > > cloudmonkey+bash.
> > > > > 
> > > > > The important issue to note here is that a lot of real-world
> > > > > awsapi integration with a user's own subsystems may not 
> > > > > follow
> > > > > any convention or be rather customised other than 
> > > > > consumption of
> > > > > service URL and associated apikey/secretkey, so migration 
> > > > > path
> > > > > from our end would mostly consist of documenting the changes.
> > > > > This upgrade path may also be implemented as a script or a
> > > > > ec2stack tool that can read cloudbridge database to get 
> > > > > useful
> > > > > configs and service offering mappings. And, there may be some
> > > > > changes that may not be migrated or supported due to the
> > > > > different AWS API versions both the services support and 
> > > > > one’s
> > > > > own custom usage/implementation.
> > > > > 
> > > > 
> > > > So honestly, I am not sure what there is to migrate/upgrade….
> > > > 
> > > > It's really a setup and folks hitting a different endpoint as 
> > > > Rohit
> > > > mentions.
> > > > 
> > > > Plus, I would not sweat this too much, we have talked several 
> > > > times
> > > > about it on the ML, and I am not convinced that *anyone* 
> > > > actually
> > > > uses awsapi, especially with 4.3 forward.
> > > > 
> > > > I would be rather drastic on this, but if someone is using a 
> > > > piece
> > > > of open source code that has not been touched in 2 years and 
> > > > that
> > > > does not work with latest cloudstack release…then tough luck. 
> > > > Get
> > > > on the ML to fix things or do the 'migration' on your own.
> > > > 
> > > > /me does not want to bother about awsapi upgrade.
> > > > 
> > > 
> > > /me doesn't want to touch that code either. In earlier threads I
> > > always voted for letting AWSAPI go en point people towards 
> > > libcloud,
> > > terraform, whatever.
> > > 
> > > Wido
> > > 
> > > > 
> > > > 
> > > > > Regards.
> > > > > 
> > > > > > Biligual auto correct use.  Read at your own risico On 30 
> > > > > > Apr
> > > > > > 2015 19:36, "David Nalley"  wrote:
> > > > > > 
> > > > > > > On Thu, Apr 30, 2015 at 1:23 PM, Rohit Yadav
> > > > > > >  wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > I was testing awsapi with 4.5 today and it just did not
> > > > > > > > work for me,
> > > > > > > after few hours I gave up and used ec2stack which worked 
> > > > > > > out
> > > > > > > of the box and certainly felt more friendly to work 
> > > > > > > with. I
> > > > > > > remembered we discussed removing awsapi but then the 
> > > > > > > momentum
> > > > > > > never precipitated into action, so I spent some time 
> > > > > > > today to
> > > > > > > cleanly remove awsapi and making sure it has a cleanup
> > > > > > > upgrade path and does not break the builds or the 
> > > > > > > packaging.
> > > > > > > (Also found and fixed a debian build issue that someone
> > > > > > > recently reported, noredist builds being broken)
> > > > > > > > 
> > > > > > > > Here is the PR:
> > > > > > > > https://github.com/apache/cloudstack/pull/216 Here is a
> > > > > > > > repo from the branch to prove that package works t

Re: Thoughts on CloudStack while starting as new VP

[Jeff Moody]

I was having the same idea the other week. There are some serious 
shortcomings in the current UI (one example is the lack of being able to 
enable/disable SSH key management on templates when registering them).
I think it might be a good idea to radically simplifly the UI that ships 
with ACS and then start a new ACS subproject (like the AWS or GCE API 
proxies) for a new, full-featured UI which could run in a different 
language and have the possibility of running at a different cadence than 
the ACS management system. This would allow UI bugs and features to be 
handled faster (or slower) than the core management server functionality 
and APIs.
It might also be worthwhile to explore building the UI in a different 
language than Java to potentially attract other developers to the ACS 
project who might be more comfortable in Python, Ruby, or NodeJS.


On 03/24/2015 07:47 AM, Alex Hitchins wrote:

Has the idea of a 'light' UI been discussed? More aimed at end users who we 
could tailor dialog to and keep it fast and simple.

I could see this as a good starting point to redevelop the whole UI.





On 24 Mar 2015, at 10:53, Rohit Yadav  wrote:

Great proposals Sebastien! Let's AWSAPI, improve code, remove dead code, 
cleanup JIRA/RB cleanup and move to Github PR.

I hope we’ll have a better UIs for ACS users soon!

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended solely 
for the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those of 
Shape Blue Ltd or related companies. If you are not the intended recipient of this 
email, you must neither take any action based upon its contents, nor copy or show 
it to anyone. Please contact the sender if you believe you have received this email 
in error. Shape Blue Ltd is a company incorporated in England & Wales. 
ShapeBlue Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue 
SA Pty Ltd is a company registered by The Republic of South Africa and is traded 
under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Question about the userdata availability

[Jeff Moody]

Go for it. Also in that repo are systemd unit files and Upstart jobs for 
the same.


The entire repo is an Ansible Playbook for setting up templates from a 
basic OS install. Feel free to use the whole playbook (that's what it's 
on GitHub for ;) ).


On 12/22/2014 04:27 PM, Nux! wrote:

Jeff,

Awesome, I'll steal your script. :)

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -----

From: "Jeff Moody" 
To: dev@cloudstack.apache.org
Sent: Monday, 22 December, 2014 15:07:29
Subject: Re: Question about the userdata availability
I have UserData init scripts that touch a file in the filesystem for the
VM to show that the UD has run and won't re-run on reboot.

https://github.com/fifthecho/CloudStack-Template/blob/master/templates/cloud-run-userdata-rhel.j2
for RHEL and
https://github.com/fifthecho/CloudStack-Template/blob/master/templates/cloud-run-userdata-debian.j2
for Debian/Ubuntu.

On 12/22/2014 07:33 AM, Nux! wrote:

Antoine,

Ok, thanks for clarifying. So it's a feature, not a bug. I'll have to deal with
it client-side then.

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Coetsier, Antoine" 
To: dev@cloudstack.apache.org, "sebgoa" , "Lambiel, Loic"

Sent: Monday, 22 December, 2014 11:55:47
Subject: Re: Question about the userdata availability
Hello,

The user data should stay there until the VM is destroyed, this is the
expected behavior for cloud-init for CloudStack but all other stacks too.

--

Antoine COETSIER


Le 22.12.14 11:04, « sebgoa »  a écrit :


Pinging Loic on this, he most likely has first hand experience with thisŠ


On Dec 20, 2014, at 11:58 AM, Nux!  wrote:


Hello,

I notice that when a VM is deployed with userdata, this userdata is
then available at http://VR/latest/user-data indefinitely, subsequent
reboots of the VM will get the userdata again and again.

When the userdata is retrieved is there a way to let the VR know it has
been retrieved and can be deleted/deactivated?
Like there is the case with the root password script which send a
"DomU_Request: saved_password" header to confirm it.

Lucian



--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Question about the userdata availability

[Jeff Moody]

I have UserData init scripts that touch a file in the filesystem for the 
VM to show that the UD has run and won't re-run on reboot.


https://github.com/fifthecho/CloudStack-Template/blob/master/templates/cloud-run-userdata-rhel.j2 
for RHEL and 
https://github.com/fifthecho/CloudStack-Template/blob/master/templates/cloud-run-userdata-debian.j2 
for Debian/Ubuntu.


On 12/22/2014 07:33 AM, Nux! wrote:

Antoine,

Ok, thanks for clarifying. So it's a feature, not a bug. I'll have to deal with 
it client-side then.

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Coetsier, Antoine" 
To: dev@cloudstack.apache.org, "sebgoa" , "Lambiel, Loic" 

Sent: Monday, 22 December, 2014 11:55:47
Subject: Re: Question about the userdata availability
Hello,

The user data should stay there until the VM is destroyed, this is the
expected behavior for cloud-init for CloudStack but all other stacks too.

--

Antoine COETSIER


Le 22.12.14 11:04, « sebgoa »  a écrit :


Pinging Loic on this, he most likely has first hand experience with thisŠ


On Dec 20, 2014, at 11:58 AM, Nux!  wrote:


Hello,

I notice that when a VM is deployed with userdata, this userdata is
then available at http://VR/latest/user-data indefinitely, subsequent
reboots of the VM will get the userdata again and again.

When the userdata is retrieved is there a way to let the VR know it has
been retrieved and can be deleted/deactivated?
Like there is the case with the root password script which send a
"DomU_Request: saved_password" header to confirm it.

Lucian



--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro