[Apt-Rpm] What is the best choice for RPM Update Tool

[Quan phongvan]

Dear Panu,
As jean-seb recommmede me to ask you a favour. If you don't mind, can you
help me about these aspects that I have to consider more about apt as a
update-tool.
1. About protocols are supported by apt-rpm, I care so much about http and
ftp because they both issue security threats: http using plan text to pass
through their passwords for communication and so easily for hacker to do
session hijack, in addition ftp passive mode also can be considered as a
security threat too. Can you give me more advices for that issue?
2. I have tried puppet as a update tool for my system beside apt (puppet is
a configuration management tool). If you tried puppet, do you think can I
use both apt and puppet as an update solution for a huge rpm embedded Linux
network system (apt as a front-end update tool on client, and
puppet-puppetmaster as administration host)?
Hope to see your reply soon,
Best regards,
Nguyen Anh Quan.

On Jan 10, 2008 7:07 PM, Quan phongvan <phongvan84 at gmail.com> wrote:

> Dear Panu,
> I really appriciate the information you provided, it helps me alot to make
> me clear about my problem.
> So here some other issues that I need your advice:
> Firstly, LUA has a very good documentation from website apt-rpm.org, it
> too well to help me get acquainted with LUA in hours.
> Seacondly, for my target embedded system, I care the most for two issue:
> automated system update by package and ful system update, and authentication
> mechanism for system retrieving updates. So could you show me how I can find
> more detailed information about apt-rpm that matched with these issues. If
> you don't mind, I still need to be more clear about RHN that you mentioned
> above (why apt and smart cannot talk to RHN).
> Thank you very much,
> Nguyen Anh Quan.
>
> On Jan 10, 2008 3:48 PM, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
>
> > On Thu, 10 Jan 2008, Quan phongvan wrote:
> >
> > > Dear Axel,
> > > Thank you for your advice, I appreciate it. While using simultaneously
> > three
> > > update tools: apt-rpm, yum,  smart, I tried to do non-update install
> > > packages and then do full update for CentOS 4.5 system also. Every
> > results
> > > show that apt-rpm and smart can beat yum almost easily both of time
> > and
> > > system resources consuming. But for long-term business POV, yum still
> > the
> > > biggest candidate for update tool.
> >
> > Yes, apt is easily the fastest of the lot, especially in terms of raw
> > depsolving speed. It's worth noting that latest upstream versions of yum
> > are much faster than the version shipped with CentOS 4.5 and smartpm has
> > seen some big improvements in latests versions too (based on changelogs,
> > haven't actually tried).
> >
> > > In addition, how about LUA, how does it get involve in apt-rpm to
> > provide
> > > more powerful advance tools that maybe you can't do with pure apt-*
> > command
> > > line.
> >
> > Apt is highly tailorable and scriptable with lua extensions. Yum does
> > have
> > plugin support too, and apparently smart has too (unsurprising as smart
> > is
> > being developed by the same person who implemented Lua support in apt :)
> > but it seems to be rather undocumented feature.
> >
> > The thing is, all the depsolvers have their own pros and cons. What
> > exactly would apt/yum/smart do on your embedded OS? Apply updates in
> > automated fashion and little else? Are you going to build the whole
> > distro
> > by yourself or use existing distro to create a minimal install tailored
> > for your needs? Will you require some sort of authentication mechanism
> > for
> > systems retrieving updates? What kind of hardware will the system be
> > running (Intel CPU or something more "embedded" such as ARM where
> > cross-compilation enters the picture)?  These kind of things have a huge
> >
> > impact on what makes sense or is even possible. Just as an example: if
> > you
> > were to base your product on RHEL (OEM deals and all) with updates
> > coming
> > from RHN, apt and smart are immediately out of the question because they
> >
> > cannot talk to the RHN server.
> >
> >        - Panu -
> > _______________________________________________
> > Apt-Rpm mailing list
> > Apt-Rpm at lists.laiskiainen.org
> > http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
> >
>
>
>
> --
> Never walk alone




-- 
Never walk alone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20080115/1e6f92b8/attachment-0003.htm>