Board index » kylix » Re: How to make Kylix application deployment much easier

Re: How to make Kylix application deployment much easier


2004-08-01 08:39:39 AM
kylix0
Quote
Because it is unreliable,
How is it unreliable?
Quote
insecure
Where exactly is the security issue?
Quote
and it is just completely
unnecessary...
Google for "kylix deploy". Or check the newsgroups archives.
Or simply try to write a CGI application in Kylix and get it to run
at your webhost.
Quote
I can see where you are coming from; nobody says that it cannot be
done, that the shared objects be loaded from the application directory
but what is the real benefits of doing this accept perhaps to satisfy
old windows habits?
You are able to run Kylix applications without any installation process.
You are able to run Kylix applications without manual work by a sysadmin.
Simon
 
 

Re:Re: How to make Kylix application deployment much easier

Quote
implemented some security precaution. That's why the system
administrator controls all the as you described “cluttered area?where
shared objects are located.
I can see three different situations here:
1.) Deploying your application on a system that is administered by a
different person. Say, a desktop application is deployed to a company
network running Linux desktops.
Yes, in this case my work-around isn't really needed.
2.) Deploying your application on a system that is administered by
yourself. Maybe a backend server at your customers place.
In this case, it doesn't matter. You know what you are doing.
3.) Deploying your application to a shared server. Web hosting and stuff.
Maybe a CGI, maybe a daemon.
Probably this happens most often, and that's where my solution is targetted
at. In reality you will be on a box in a datacenter with thousands of
other customers of the hosting center. There is no admin to ask. Even if you
could reach an admin through customer support, he probably would tell you
he'll never in his whole live install some customers shared objects to /usr/lib.
Or do any other kind of manual work for a single customer, for that matter.
Without my solution you are lost.
Quote
Another important element abut which we should not forget is that the
basic function of shared objects is to be *shared* among many
application which can benefits form them; the idea behind this is to
avoid duplicated code.
Yes. But we are talking about Kylix here. As Kylix developers, we have
to ship shared objects that aren't shared. Nobody else will use the
specific version of dbexpress we are using. Or borlands libqt version.
And we can't use whatever is available on the system, as in 99% of all
cases it will be incompatible with borlands code. Think about
libmysqlclient.
As Kylix (Delphi) users, we can not statically link the objects we need,
like the rest of the Linux world is able to. We are forced to deploy
unshared shared objects.
I now see that there a few people here that are quite fanatic about
the great and nice theoretic aspects of UNIX and linux system layout.
The reality is, most people using Linux boxes for business do not
care about this. They want to get the job done and/or earn money.
And I personally are very happy I'm now able to just tell me customers
to dump everything into a directory of their choice and run it. And
they like it.
Simon
 

Re:Re: How to make Kylix application deployment much easier

"Simon Kissel" < XXXX@XXXXX.COM >writes:
Quote
Security reasons? Bullshit. What's wrong with having your shared objects inside
your application directory? They are owned by you, and they are run by your
application.
Plenty.
Perhaps you should learn a bit about unix before writing applications for it.
 

{smallsort}

Re:Re: How to make Kylix application deployment much easier

"Simon Kissel" < XXXX@XXXXX.COM >writes:
Quote
Up until now in this thread, I was told:

"You've got to be kidding! It can be hardily called a solution.
This code will fail more often then not "

"it's pretty dire coding."

"The improvement is to remove the code. For security reasons and for reasons
of avoiding the same nonsense as on Windows called DLL-hell."

No facts, no real arguments, just lots of "it sucks because I say so" kind of
comments.
May I please add, " You are clueless and are unwilling to accept a
clue when it is offered to you on a silver platter"
 

Re:Re: How to make Kylix application deployment much easier

Quote
>No facts, no real arguments, just lots of "it sucks because I say so" kind of
>comments.

May I please add, " You are clueless and are unwilling to accept a
clue when it is offered to you on a silver platter"
Aaah, IRT - the troll collection is complete :)
Simon
 

Re:Re: How to make Kylix application deployment much easier

Quote
>Security reasons? Bullshit. What's wrong with having your shared objects inside
>your application directory? They are owned by you, and they are run by your
>application.

Plenty.

Perhaps you should learn a bit about unix before writing applications for it.
How appropriate. You fight like a cow.
Simon
 

Re:Re: How to make Kylix application deployment much easier

Quote
Perhaps you should learn a bit about unix before writing applications for it.
<flamewar>
Thinking about it, probably I should take lessons from you.
groups.google.de/groups
Obviously you are highly skilled in trolling about java, scheme, ada,
smalltalk, lisp, c#, Eiffel, cppbuilder, delphi and even visual basic.
Wee. Up until this newsgroup search I thought the only thing you are
spending your time on is posting "$BORLANDPRODUCT is dead" kind of
messages. Actually you don't seem to limit this activity to Borland
products.
How about shutting the hell up, doing something PRODUCTIVE and/or
go get a life? :)
</flamewar>
 

Re:Re: How to make Kylix application deployment much easier

I R T wrote:
Quote
May I please add,
No, you may not.
--
Nick Hodges -- TeamB
Lemanix Corporation -- www.lemanix.com
Read my Blog -- www.lemanix.com/nick
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
[...]
Quote
And even if the sysadmin would like to find out which SOs I'm loading:
ldd exists. And there is no difference in reading my startup script or
just looking at the applications directory listing.
If you are dynamically loading SOs, then ldd will not show you which
ones are being loaded.
B
 

Re:Re: How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
Where exactly is the security issue?
Think virus.
--
Ruurd
 

Re:Re: How to make Kylix application deployment much easier

Willibald Krenn wrote:
Quote
That would be insecure. Better name your private shared object in a way
that you can be sure no other library will have the same name.

The whole thing is inherently insecure this way or another and yes
naming your shared object according to Linux shared object naming
convention is essential but the problem is that binaries produces by
Kylix refer with hard-coded names.
 

Re:Re: How to make Kylix application deployment much easier

Willibald Krenn wrote:
Quote
I've learned several things:
- It won't work out of the box. (even packages from the distributor tend
to fail)
- If it works, don't try to customize. (Except you have a day off)
- Never try to get a snapshot and compile/install it; It will cause
endless grief with the possible outsight of having to replace half the
system.
- Everything is half finished (IOW: half working)
- No innovation; Most of the time just a clone from several commercial
packages.

Well, I am sorry that you have a hard time with Linux; I hope that in
time all the “half working?application will reach version 1.0 and
perhaps you find something useful for you... so just hold on in there.. ;)
juliusz
--
InstallMade - Kylix-specific installer
www.superobject.com/installmade/
www.superobject.com/imoe/download.html
 

Re:Re: How to make Kylix application deployment much easier

R.F. Pels schrieb:
Quote
willi krenn wrote:


>Sorry, but as user I want to install non system programs by myself (for
>myself) and without the need to become superuser.


That is because you are single-user minded.
Yes I'm using my Linux box most of the time for me alone. However, I do
not want user B to be able to run programs I installed for personal
reasons.
Quote
In this case, experimenting with
a Linux machine at home or in a development environment is quite OK, but
once you go into production work, it is a totally different matter.
I'm talking about Linux as Desktop OS here.
Willi
 

Re:Re: How to make Kylix application deployment much easier

juliusz schrieb:
Quote
willi krenn wrote:

>
>I can not understand however, why the application directory is not even
>looked at when a search over all other paths fails to find the requested
>lib.
>

Because it is unreliable, insecure and it is just completely
unnecessary...what's application directory anyway?
I know that an "application directory" per se doesn't exist on Linux
(which is a pity, because there we have various levels of /bin, then
there is /opt and you never know exactly where to find some program AND
you constantly have to become su when you have to tune/configure some
files in these directories that should have mappings somewhere in ~/
(tex comes to mind) ).
It's always cool on Linux when you do a rpm install, then type the
application name on prompt - and nothing happens. Bad luck - now you
have to search for the binary (cause you don't know where it has gone)
and modify some searchpath. (So much for Linux and standards..)
Furthermore I don't think it would be insecure, 'cause everyone may set
the LD_XY environment variable and gets the same result. Honestly I do
not know, why you are of the opinion that loading .sos from 'application
directory' is unreliable? If built into the loader?
Quote
I can see where you are coming from;
From DOS obviously. I prefer the 'copy it to a directory on harddisk
and start working' deployment. Simple, elegant and the best way for
single user installations. (Backup is even easier!)
This could even be done for multi-user installations..
Quote
nobody says that it cannot be done,
that the shared objects be loaded from the application directory but
what is the real benefits of doing this accept perhaps to satisfy old
windows habits?
Whats the benefit of grouping (application dependant) libraries in 10s
of lib subdirectories that have to be mentioned somewhere in ld.so.conf?
As you can see, kde, gnome ... all already have their own 'library
application directory':
/usr/X11R6/lib64/Xaw95
/usr/X11R6/lib64/Xaw3d
/usr/X11R6/lib
/usr/X11R6/lib/Xaw95
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib64
/usr/x86_64-suse-linux/lib64
/usr/x86_64-suse-linux/lib
/usr/local/lib
/usr/openwin/lib
/opt/kde/lib
/opt/kde2/lib
/opt/kde3/lib
/opt/gnome/lib
/opt/gnome2/lib
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/usr/openwin/lib64
/opt/kde/lib64
/opt/kde2/lib64
/opt/kde3/lib64
/opt/gnome/lib64
/opt/gnome2/lib64
The problem here is, if you add
/home/xy/lib
/home/zz/lib
both /home/??/lib directories are searched - regardeless which user is
asking for service..
Quote
I am aware of the fact that Borland could very easy
build in that capability as default behavior into Kylix but they didn't
do it. Why? Because this is not the Linux way, and it would create more
problems. Surely it would be more understandable for a window developer
to “deploy?Kylix application, but in the same time it will lead to
create bad habits, overall poor security of the system and effectively
to clutter the system with many redundant shared objects.
This is the only problem I can see (but I did not say that system libs
should be installed in private directories!). I do not see however, why
loading private shared objects from an application directory should
compromise security?? If a cracker has access to the user account, the
user has lost in any case.
Quote
This approach
of course could be used but only as an *option* for example for testing
or in controlled environment single-user application. But essentially
it does not give the developer any benefits whatsoever, because Linux
already has build in far superior means of doing this in much more
*reliable* and *safer* ways.
Tell me why this is so much safer! If a hacker has access to your user
account, the current way of application deployment won't save the user's
data.
Quote
The fact is that Linux system is designed
around the idea that the installed application location is predefined by
the developer/packager and has to correlate to the system security
requirements and other rules and standards and often the installed files
are spread all over the system in accordance to its respectful
functions...
Then tell me why every majour distributor has another view of these
requirements and standards. What's the purpose of globally installing
applications that are used by only one user. What about license issues?
Why do you think it's positive to store e.g. the program documentation
in a completely separate directory tree and not there where it belongs:
In the application directory?
Quote
by adding another variable (complexity) to the already
complex system will not simplify things, perhaps on the surface it will,
but because this method is inherently unreliable it can come back and
bite you hard in the moment when you are least expected.
You have absolutely no clue how many times Linux bit me in the past. My
first Linux was some SuSE 5.3 - since that time I spent significantly
more time in figuring out work arounds for Linux than for Windows.
I've learned several things:
- It won't work out of the box. (even packages from the distributor tend
to fail)
- If it works, don't try to customize. (Except you have a day off)
- Never try to get a snapshot and compile/install it; It will cause
endless grief with the possible outsight of having to replace half the
system.
- Everything is half finished (IOW: half working)
- No innovation; Most of the time just a clone from several commercial
packages.
Quote
Hey! Linux is all about freedom and flexibility and anyone can modify it
to its needs and redefine its basic behavior no problem there...
That's one of the basic problems :-)
At last, Mono will mostly fix the loading issues - so everyone will be
happy in future, I guess.
Willi
 

Re:Re: How to make Kylix application deployment much easier

juliusz schrieb:
Quote
Another problem as far I can tell is that your code attempts to load the
shared objects from the application directory last (when the Linux
loader is not able to find it in the system), right? OK you shouldn't
do this. I think it would be much better if you revers the process and
check the application directory first because otherwise you may load
inappropriate version of the library and the application will crash.
That would be insecure. Better name your private shared object in a way
that you can be sure no other library will have the same name.
Quote
Well, I am perfectly aware about the Kylix deployment issues and I have
personally dedicated a lot of time and effort to help a lot of people in
this respect and in attempt to increase the Kylix acceptance. It would
be prudent to say that from my observation all the deployment problems
related to Kylix 1 Kylix 2 and partially Kylix 3 originated from the
“conceptual mistake?of not following Linux shared objects naming
convention. The lesson to be learned is that it is extremely important
to follow the Linux way of doing things ;)
Simply name it: Chaos - pure chaos ;-)
Willi