Hi,
I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
tks.
On Wed, Nov 09, 2005 at 01:26:44PM -0600, Johnny Hughes enlightened us:
Hi, I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
tks.
Due to licensing issues, we can not distribute JRE rpms.
You can, however, get the nosrc.rpm from jpackage.org and by following the directions build your own RPMs.
Matt
On Wed, 2005-11-09 at 13:26, Johnny Hughes wrote:
On Wed, 2005-11-09 at 15:18 -0400, mbneto wrote:
Hi,
I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
tks.
Due to licensing issues, we can not distribute JRE rpms.
Could you include the yum or up2date config already set up go getting them via jpackage would "just work" with something like: yum install jre j2re-plugin
-- Les Mikesell lesmikesell@gmail.com
On Wed, Nov 09, 2005 at 01:37:44PM -0600, Les Mikesell enlightened us:
On Wed, 2005-11-09 at 15:18 -0400, mbneto wrote:
I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
tks.
Due to licensing issues, we can not distribute JRE rpms.
Could you include the yum or up2date config already set up go getting them via jpackage would "just work" with something like: yum install jre j2re-plugin
Ther are currently no third party yum/up2date configs distributed with CentOS. That aside, even if you did do so it wouldn't do any good. There are some free (as in speech) packages on jpackage.org, but the jre stuff is not so it must be rebuilt. See http://www.jpackage.org/rebuilding.php for how/why.
Matt
On Wed, 2005-11-09 at 13:45, Matt Hyclak wrote:
Due to licensing issues, we can not distribute JRE rpms.
Could you include the yum or up2date config already set up go getting them via jpackage would "just work" with something like: yum install jre j2re-plugin
Ther are currently no third party yum/up2date configs distributed with CentOS. That aside, even if you did do so it wouldn't do any good. There are some free (as in speech) packages on jpackage.org, but the jre stuff is not so it must be rebuilt. See http://www.jpackage.org/rebuilding.php for how/why.
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
because current java licensing prevents such useful things.
-- Jim Perrin System Administrator - UIT Ft Gordon & US Army Signal Center
Jim Perrin wrote:
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
because current java licensing prevents such useful things.
I've noticed some other distros (*cough* Debian *cough*) are including java packages in their repo. Any idea how they get away with it?
Maybe Sun just doesn't want to rock the boat...
On Wed, 2005-11-09 at 16:08 -0500, Ryan wrote:
Jim Perrin wrote:
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
because current java licensing prevents such useful things.
I've noticed some other distros (*cough* Debian *cough*) are including java packages in their repo. Any idea how they get away with it?
Maybe Sun just doesn't want to rock the boat...
They have the free jpackage.org stuff ... they do not have the Sun or IBM SDK / JRE stuff in the repos (that I can find).
Ryan ryanag@zoominternet.net wrote:
I've noticed some other distros (*cough* Debian *cough*) are including java packages in their repo. Any idea how
they
get away with it?
They don't. The official Debian repositories do not host it.
There are several 3rd party, Non-Free Debian repositories -- let alone Debian-based distros -- that aren't legal because they redistribute such in _violation_ of the licensing agreements on the software.
When I was consulting at a Fortune 20 company as one of the Linux architects, I maintained a "whitelist" of distros. A few people gave me the title of "The Linux Nazi" as a result. ;->
Maybe Sun just doesn't want to rock the boat...
Sun allows near-free redistribution of the JRE for MacOS X, Solaris and Windows, but _not_ Linux. I assume the Java Desktop subscription has much to do with that.
On Wed, Nov 09, 2005 at 02:04:27PM -0600, Les Mikesell enlightened us:
Due to licensing issues, we can not distribute JRE rpms.
Could you include the yum or up2date config already set up go getting them via jpackage would "just work" with something like: yum install jre j2re-plugin
Ther are currently no third party yum/up2date configs distributed with CentOS. That aside, even if you did do so it wouldn't do any good. There are some free (as in speech) packages on jpackage.org, but the jre stuff is not so it must be rebuilt. See http://www.jpackage.org/rebuilding.php for how/why.
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
Because it's a distribution agnostic process?
Directions for CentOS:
1. Create an RPM build tree as per ftp://people.redhat.com/mharris/hacks/rpmbuild-nonroot-1.0.tar.gz
2. Download java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm from http://jpackage.org/rpm.php?id=3033
3. rpm -i java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm
4. Download JDK 5.0 Update 5 from http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=...
5. Put jdk-1_5_0_05-linux-i586-rpm.bin in your SOURCES directory created in step 1.
6. rpmbuild -ba SPECS/java-1.5.0-sun.spec
7. Install the resulting RPMS, or put them in your local yum repository.
I'm not trying to be a jack@$$ here, but I'm really not sure what you want. I laid it out in 7 steps, and I'm not sure you could make it much shorter.
Matt
On Wed, 2005-11-09 at 14:18, Matt Hyclak wrote:
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
Because it's a distribution agnostic process?
So is every other application we have until someone bundles it for the distribution.
Directions for CentOS:
Create an RPM build tree as per ftp://people.redhat.com/mharris/hacks/rpmbuild-nonroot-1.0.tar.gz
Download java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm from http://jpackage.org/rpm.php?id=3033
rpm -i java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm
Download JDK 5.0 Update 5 from http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=...
Put jdk-1_5_0_05-linux-i586-rpm.bin in your SOURCES directory created in step 1.
rpmbuild -ba SPECS/java-1.5.0-sun.spec
Install the resulting RPMS, or put them in your local yum repository.
I'm not trying to be a jack@$$ here, but I'm really not sure what you want. I laid it out in 7 steps, and I'm not sure you could make it much shorter.
It could be one step if those instructions were slightly altered to become an executable shell script. Having the script run as part of an installation or system setup and something that checks for updates would make it even nicer. Does the jpackage rpm you mention take care of twiddling the symlinks of the alternatives system that I have never been able to find documentation about?
On Wed, Nov 09, 2005 at 02:39:06PM -0600, Les Mikesell enlightened us:
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
Because it's a distribution agnostic process?
So is every other application we have until someone bundles it for the distribution.
You have a point. This is definitely rpm-based-distro agnostic and provides an easy way to do things. Not *quite* as easy as "yum install java", but they did all the hard parts.
Directions for CentOS:
Create an RPM build tree as per ftp://people.redhat.com/mharris/hacks/rpmbuild-nonroot-1.0.tar.gz
Download java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm from http://jpackage.org/rpm.php?id=3033
rpm -i java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm
Download JDK 5.0 Update 5 from http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=...
Put jdk-1_5_0_05-linux-i586-rpm.bin in your SOURCES directory created in step 1.
rpmbuild -ba SPECS/java-1.5.0-sun.spec
Install the resulting RPMS, or put them in your local yum repository.
I'm not trying to be a jack@$$ here, but I'm really not sure what you want. I laid it out in 7 steps, and I'm not sure you could make it much shorter.
It could be one step if those instructions were slightly altered to become an executable shell script. Having the script run as part of an installation or system setup and something that checks for updates would make it even nicer. Does the jpackage rpm you mention take care of twiddling the symlinks of the alternatives system that I have never been able to find documentation about?
The problem with the shell script is that you have to agree to a license from sun when you download it. The links aren't active until you click yes for yes. But it's not a bad idea...
And yes, they take care of more alternatives stuff than I'd care to know about, so that's why I recommend putting in the effort.
Matt
On Wed, 2005-11-09 at 14:39 -0600, Les Mikesell wrote:
On Wed, 2005-11-09 at 14:18, Matt Hyclak wrote:
OK, so you need a .spec file and a couple of lines of script. The point is that the hard and unnecessary part is finding all the stuff yourself in the first place. Instead of directions that point to distribution agnostic and vague directions, why can't we have something that just installs it for us?
Because it's a distribution agnostic process?
So is every other application we have until someone bundles it for the distribution.
You are NOT ALLOWED to bundle it for distribution ... it DOES NOT HAVE a free license that allows that. If it WERE allowed to be distributed, then you would be able to install it via yum and it would be part of the distribution.
It is a SUN issue that we can't build an easily installable RPM and also meet their licensing requirement.
It isn't like it would be an earth shattering thing to create a SRPM to make it happen.
The CentOS project IS mindful of the licenses of the software we distribute ... it might be a pain in the ass sometimes, but we have to follow the rules.
Directions for CentOS:
Create an RPM build tree as per ftp://people.redhat.com/mharris/hacks/rpmbuild-nonroot-1.0.tar.gz
Download java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm from http://jpackage.org/rpm.php?id=3033
rpm -i java-1.5.0-sun-1.5.0.05-1jpp.nosrc.rpm
Download JDK 5.0 Update 5 from http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=...
Put jdk-1_5_0_05-linux-i586-rpm.bin in your SOURCES directory created in step 1.
rpmbuild -ba SPECS/java-1.5.0-sun.spec
Install the resulting RPMS, or put them in your local yum repository.
I'm not trying to be a jack@$$ here, but I'm really not sure what you want. I laid it out in 7 steps, and I'm not sure you could make it much shorter.
It could be one step if those instructions were slightly altered to become an executable shell script. Having the script run as part of an installation or system setup and something that checks for updates would make it even nicer. Does the jpackage rpm you mention take care of twiddling the symlinks of the alternatives system that I have never been able to find documentation about?
On Wed, 2005-11-09 at 15:09, Johnny Hughes wrote:
It is a SUN issue that we can't build an easily installable RPM and also meet their licensing requirement.
Does the license actually specify that a user has to click their download link instead of running a script that uses wget or something? Obviously you can't include their code, but there should be a way to reduce the many-step operation with instructions that are likely to be out of date with one step that is kept current.
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell wrote:
On Wed, 2005-11-09 at 15:09, Johnny Hughes wrote:
It is a SUN issue that we can't build an easily installable RPM and also meet their licensing requirement.
Does the license actually specify that a user has to click their download link instead of running a script that uses wget or something? Obviously you can't include their code, but there should be a way to reduce the many-step operation with instructions that are likely to be out of date with one step that is kept current.
-- Les Mikesell lesmikesell@gmail.com
It looks like you can distribute it now (this must have just changed)
http://java.com/en/download/license.jsp
"Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software."
On Wed, 2005-11-09 at 16:51 -0500, Ryan wrote:
Les Mikesell wrote:
On Wed, 2005-11-09 at 15:09, Johnny Hughes wrote:
It is a SUN issue that we can't build an easily installable RPM and also meet their licensing requirement.
Does the license actually specify that a user has to click their download link instead of running a script that uses wget or something? Obviously you can't include their code, but there should be a way to reduce the many-step operation with instructions that are likely to be out of date with one step that is kept current.
-- Les Mikesell lesmikesell@gmail.com
It looks like you can distribute it now (this must have just changed)
http://java.com/en/download/license.jsp
"Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software." _______________________________________________
We can't distribute it in an RPM format that would take the source RPM and install it in the normal way. Because:
we do not meet section (ii) at all .... we have not written any programs that add significant functionality to their product.
we would be altering the notices that are required reading prior to installing the software, which would be in violation of section (iv).
The jpackage.org projects meet section (ii) and they still can't redistribute the software via RPMS. ------------------------------------------------- In their their FAQ:
Can't we get around the hassle of no source RPMs using mechanism foo?
We have been discussing this quite a bit, and in the end it was determined that the "click-through" restrictions of things like the Sun JDK prevent anything but the no source RPM solution that is implemented. See the previous questions for a more detailed discussion.
For more info: http://www.jpackage.org/faq.php ---------------------------------------------------
I wish we could, but we can't distribute that software.
--- Johnny Hughes
Johnny Hughes wrote:
On Wed, 2005-11-09 at 16:51 -0500, Ryan wrote:
It looks like you can distribute it now (this must have just changed)
http://java.com/en/download/license.jsp
"Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software." _______________________________________________
We can't distribute it in an RPM format that would take the source RPM and install it in the normal way. Because:
we do not meet section (ii) at all .... we have not written any programs that add significant functionality to their product.
we would be altering the notices that are required reading prior to installing the software, which would be in violation of section (iv).
You also don't meet section (iii), since you distribute gcc-java (which obviously replaces some components of Sun's Java).
In short, unless Sun grants special license to CentOS project, they can't distribute Java as part of distribution. Interestingly, Red Hat is distributing IBM's Java packages...
On Saturday 12 November 2005 23:56, Aleksandar Milivojevic wrote:
In short, unless Sun grants special license to CentOS project, they can't distribute Java as part of distribution. Interestingly, Red Hat is distributing IBM's Java packages...
why not at least java-sun-compat package, that symlink in the install, like the java-gcj-compat actually do?
jpackage support java-sun-compat for 1.4 and 1.5 (although i can't install both one cleanly now)
when i download the sun rpm, whe download a .bin executable, that when is executed, put a text for agrement and after this put an rpm in your system to install.
we can install sun rpm, and after this a java-sun-compat wrapper that work with alternatives. just like jpackage.
Quoting Black Hand yonsy@blackhandchronicles.homeip.net:
we can install sun rpm, and after this a java-sun-compat wrapper that work with alternatives. just like jpackage.
Don't have Sun's RPM handy to check, but somehow I seem to remember that Sun's RPM installs itself in /usr/bin/..., removing the links that were already placed there by alternatives system.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic alex@milivojevic.org wrote:
Don't have Sun's RPM handy to check, but somehow I seem to remember that Sun's RPM installs itself in /usr/bin/..., removing the links that were already placed there by alternatives system.
Er, no. The Sun RPM doesn't solve many of the symlinks last time I checked. You want the jpackage sun-compat RPM to go with the JDK.
Aleksandar Milivojevic wrote:
Don't have Sun's RPM handy to check, but somehow I seem to remember that Sun's RPM installs itself in /usr/bin/..., removing the links that were already placed there by alternatives system.
Java5 installs to /usr/java/jdk1.5.0_05
Ryan ryanag@zoominternet.net wrote:
It looks like you can distribute it now (this must have just changed) http://java.com/en/download/license.jsp ... "(iii) you do not distribute additional software intended to replace any component(s) of the Software,
(iii) is a sticking point right there if GCJ/ClassPath is included in the distro.
(v) and (vi) might be additional sticking points as well.
(v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software."
Les Mikesell wrote:
On Wed, 2005-11-09 at 15:09, Johnny Hughes wrote:
It is a SUN issue that we can't build an easily installable RPM and also meet their licensing requirement.
Does the license actually specify that a user has to click their download link instead of running a script that uses wget or something? Obviously you can't include their code, but there should be a way to reduce the many-step operation with instructions that are likely to be out of date with one step that is kept current.
To download it, you must explicitly click "I agree with licensing terms" (or something like that) on download page. While it would be possible to write a script that would automatically download it (leaving server believe you clicked on "agree") and build a package, it would be illegal to use resulting package (since you haven't really agreed with licensing terms). To download Java legally, you *must* manually download it, going through all steps on Sun/IBM/Blackdown/Whatever web site. Otherwise you are breaking the law, and Sun can sue your ass.
Johnny Hughes wrote:
On Wed, 2005-11-09 at 15:18 -0400, mbneto wrote:
Hi,
I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
tks.
Due to licensing issues, we can not distribute JRE rpms.
DAG has them.
Hello,
I've been configuring the virtualhosts, and I've come out to a "stop point". I mean, I feel like the http request is being stop at the DNS server without being forwarded to the appropiate service.
In this case I'm working only with one machine 192.168.1.1 and this machine is hosting DNS, mailserver and web server.
The classic example of virtual host would be assigning http://webmail.dominio.com to /usr/share/squirrelmail being dominio.com my domain.
Let's see the results of the http petitions Quote:
http://webmail.dominio.com DNS error
http://www.dominio.com/webmail OK
http://mail.dominio.com Shows the page but squirrelmail is not working at all
mail.dominio.com and smtp.dominio.com are listed in the bind as MX. Looging into squirrelmail by http://mail.dominio.com let's you introduce user and password, but when it is supposed to show your messages gives the following error:
ERROR : Could not complete request.
Query: SELECT "INBOX"
Reason Given: Internal error occured. Refer to server log for more information. [2005-11-09 16:48:40]
In the log I only see :
Quote:
[Wed Nov 09 16:47:54 2005] [error] [here.the.proxy.ip] File does not exist: /usr/share/squirrelmail/favicon.ico
The error to not see the messages should be something more beside the favicon..... I give more data:
The relevant part of /etc/httpd/conf.d/vhosts.conf is:
# Definición del Sitio de Red principal NameVirtualHost 192.168.1.1
<VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /var/www/html/ ServerName www.dominio.com </VirtualHost>
<VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName webmail.dominio.com ErrorLog logs/webmail.dominio.com-error_log CustomLog logs/webmail.dominio.com-access_log combined
</VirtualHost>
<VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName mail.dominio.com ErrorLog logs/mail.dominio.com-error_log CustomLog logs/mail.dominio.com-access_log combined </VirtualHost>
I also tried this configuration, with identical results
# Definición del Sitio de Red principal NameVirtualHost *:80 NameVirtualHost *:443
<VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /var/www/html/ ServerName www.dominio.com </VirtualHost>
<VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName webmail.dominio.com ErrorLog logs/webmail.dominio.com-error_log CustomLog logs/webmail.dominio.com-access_log combined
</VirtualHost>
<VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName mail.dominio.com ErrorLog logs/mail.dominio.com-error_log CustomLog logs/mail.dominio.com-access_log combined </VirtualHost>
The apache configuration file is a fresh new one that was comming with httpd-2.0.52-19.ent.centos4
Any idea?
As far as I can see http://mail.domain.com is working because mail.domain.com is listed as MX in the bind zone file, but as far as I can imagine, I shouldn't list in bind every virtualhost I'm configuring in apache.
May I provide any other information to have this solved?
Regards Jujo
Julio Soto wrote on Thu, 10 Nov 2005 00:39:04 +0100:
As far as I can see http://mail.domain.com is working because mail.domain.com is listed as MX in the bind zone file, but as far as I can imagine, I shouldn't list in bind every virtualhost I'm configuring in apache.
Sure you have. You either have to create each and every hostname on DNS or use a wildcard A record for that domain. Actually, that's the only parapraph from your whole posting I understood since you are mixing several things together and it's not clear what you actually want to fix. First fix your dns problem, then if you still have a problem try to solve one at a time.
Kai
Mensaje citado por Kai Schaetzl maillists@conactive.com:
As far as I can see http://mail.domain.com is working because mail.domain.com is listed as MX in the bind zone file, but as far as I can imagine, I shouldn't list in bind every virtualhost I'm configuring in apache.
Sure you have. You either have to create each and every hostname on DNS or use a wildcard A record for that domain. Actually, that's the only parapraph from your whole posting I understood since you are mixing several things together and it's not clear what you actually want to fix. First fix your dns problem, then if you still have a problem try to solve one at a time.
So if I want to use a virtualhost like http://webmail.mydomain.com, do I need to list "webmail" in the DNS zone file of mydomain.com?
Regards
Julio
Jujo wrote on Thu, 10 Nov 2005 08:21:57 +0100:
So if I want to use a virtualhost like http://webmail.mydomain.com, do I need to list "webmail" in the DNS zone file of mydomain.com?
As I said, if you don't use a wildcard, yes.
Kai
Mensaje citado por Kai Schaetzl maillists@conactive.com:
Jujo wrote on Thu, 10 Nov 2005 08:21:57 +0100:
So if I want to use a virtualhost like http://webmail.mydomain.com, do I
need to
list "webmail" in the DNS zone file of mydomain.com?
As I said, if you don't use a wildcard, yes.
Thank you very much, now I think I know how to do it, because I wanted to host several stuff in the same machine. I mean
http://webmail.domain.com http://blog.domain.com http://pictures.domain.com
So now I know I have to make a DNS entry for webmail, blog and pictures.
On the other hand I have a little problem when logging in squirrelmail from address http://mail.domain.com and not from http://www.domain.com/webmail but I will post it from house when I have all information available.
Than you and regards
Jujo
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de & http://msie.winware.org
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Jujo wrote on Thu, 10 Nov 2005 13:18:33 +0100:
On the other hand I have a little problem when logging in squirrelmail from address http://mail.domain.com and not from http://www.domain.com/webmail but I will post it from house when I have all information available.
You have to use Squirrelmail from the root of its directory as with almost any other PHP application. There simply is a difference if you access an application via hostname, hostname/folder or hostname/folder/folder and so on. You should subscribe to a PHP group and read a while there without posting and only if your problem is still not answered ask about it. You can also use groups.google.com to search that group for similar problems. You can also subscribe to a Sqirrelmail mailing list if your problem is definitely Squirrelmail-related. I don't think that your problem is well suited for this mailing list, since it is not at all CentOS-specific.
Kai
centos-bounces@centos.org <> scribbled on Wednesday, November 09, 2005 5:39 PM:
Hello,
I've been configuring the virtualhosts, and I've come out to a "stop point". I mean, I feel like the http request is being stop at the DNS server without being forwarded to the appropiate service.
In this case I'm working only with one machine 192.168.1.1 and this machine is hosting DNS, mailserver and web server.
The classic example of virtual host would be assigning http://webmail.dominio.com to /usr/share/squirrelmail being dominio.com my domain.
Let's see the results of the http petitions Quote:
http://www.dominio.com OK http://dominio.com OK http://webmail.dominio.com DNS error http://www.dominio.com/webmail OK http://mail.dominio.com Shows the page but squirrelmail is not working at allmail.dominio.com and smtp.dominio.com are listed in the bind as MX. Looging into squirrelmail by http://mail.dominio.com let's you introduce user and password, but when it is supposed to show your messages gives the following error:
ERROR : Could not complete request.
Query: SELECT "INBOX"
Reason Given: Internal error occured. Refer to server log for more information. [2005-11-09 16:48:40]
In the log I only see :
Quote:
[Wed Nov 09 16:47:54 2005] [error][here.the.proxy.ip] File does not exist: /usr/share/squirrelmail/favicon.ico
The error to not see the messages should be something more beside the favicon..... I give more data:
The relevant part of /etc/httpd/conf.d/vhosts.conf is:
# Definición del Sitio de Red principal NameVirtualHost 192.168.1.1 <VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /var/www/html/ ServerName www.dominio.com </VirtualHost> <VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName webmail.dominio.com ErrorLog logs/webmail.dominio.com-error_log CustomLog logs/webmail.dominio.com-access_log combined </VirtualHost> <VirtualHost 192.168.1.1> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName mail.dominio.com ErrorLog logs/mail.dominio.com-error_log CustomLog logs/mail.dominio.com-access_log combined </VirtualHost>I also tried this configuration, with identical results
# Definición del Sitio de Red principal NameVirtualHost *:80 NameVirtualHost *:443
<VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /var/www/html/ ServerName www.dominio.com </VirtualHost> <VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName webmail.dominio.com ErrorLog logs/webmail.dominio.com-error_log CustomLog logs/webmail.dominio.com-access_log combined </VirtualHost> <VirtualHost *:80> ServerAdmin webmaster@dominio.com DocumentRoot /usr/share/squirrelmail/ ServerName mail.dominio.com ErrorLog logs/mail.dominio.com-error_log CustomLog logs/mail.dominio.com-access_log combined </VirtualHost>The apache configuration file is a fresh new one that was comming with httpd-2.0.52-19.ent.centos4
Any idea?
As far as I can see http://mail.domain.com is working because mail.domain.com is listed as MX in the bind zone file, but as far as I can imagine, I shouldn't list in bind every virtualhost I'm configuring in apache.
May I provide any other information to have this solved?
Regards Jujo
If you would make the squirrelmail vhost entry the very first one in your vhost.conf, ANY connection to httpd that is NOT defined by another vhost entry would hit the squirrelmail by default. This way, you don't have to make a vhost entry for 100 virtual domains.
Mike
On 11/9/05, mbneto mbneto@gmail.com wrote:
Hi,
I was wondering if there is a rpm package for java (jre) to centos 4.x or do I have to get from sun/ibm/blackdown ?
Most of the sun/ibm/blackdown packages aren't that user-friendly to set up. Dag has a jre in his repository that is quite nice and sets up the java environment for you. If his package will not work, I would recommend getting one of the jpackage nosrc java rpms and rebuilding it using the sources from sun/ibm/blackdown. It will make them MUCH nicer to deal with.
-- Jim Perrin System Administrator - UIT Ft Gordon & US Army Signal Center
-
Aleksandar Milivojevic -
Black Hand -
Bryan J. Smith -
Darryl L. Pierce -
Jim Perrin -
Johnny Hughes -
Jujo -
Julio Soto
-
Kai Schaetzl -
Les Mikesell -
Matt Hyclak -
mbneto -
Mike Kercher -
Ryan