I've got an HP 760n. It can not boot from CD, so I copied vmlinuz and initrd.img from isolinux into /boot and modified grub.conf. During the boot the mouse, card and display are correctly recognized.
The problem:
The mouse/keyboard/window freezes within the first couple of install setup screens. The furthest I got was entering in my ip address. The earliest freeze occurred when the mouse (as a pointer, after its an 'X') first appears.
Any hints as to whats up?
The fix!!!! use the text mode installer, not the X-gui.
No freezing, installed fedora 2. Rebooted machine after install.
First thing it does is puts you into a X-gui based set of windows requiring that you add a user, etc. There is NO way to do this in text-mode. It also starts you at run-level 5.
So now the system freezes having spent 1 hour installing it, thinking I was cleaver because I avoided using the X-gui based install setup screens only to find that the first boot puts one right back into the X-gui setup system and it freezes.
Curiously, if I then turn off the machine a try again (having no completed the initial boot setup), it starts but hangs after printing the message:
Enable Swap space
If the turn off the machine and try again, it puts me into the X-gui setup system, and so on; each reboot alternates between the X-gui setup that freezes and the system hanging after printing the swap message.
So, I can install fedora 2, I just can not get past the first reboot.
My solution, re-install redhat 9.
Richard
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development, not production use. I ended up grabbing the "php.ini-recommended" file from the official release of PHP-4.3.6 and made a couple Fedora-related changes to it (diff helped out here).
J.A.K.E. [ jake1138 AT yahoo DOT com ]
On Mon, 2004-06-28 at 18:07, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development, not production use. I ended up grabbing the "php.ini-recommended" file from the official release of PHP-4.3.6 and made a couple Fedora-related changes to it (diff helped out here).
J.A.K.E. [ jake1138 AT yahoo DOT com ]
lol, I must say you did a very good job of being as vague as possible and not illustrating your point in any way.
On Monday 28 June 2004 03:07 pm, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development, not production use. I ended up grabbing the "php.ini-recommended" file from the official release of PHP-4.3.6 and made a couple Fedora-related changes to it (diff helped out here).
J.A.K.E. [ jake1138 AT yahoo DOT com ]
Would you be interested in sharing your work ???
Thanks,
John
From: "Adam Voigt"
On Mon, 2004-06-28 at 18:07, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development,
not
production use. I ended up grabbing the "php.ini-recommended" file from
the
official release of PHP-4.3.6 and made a couple Fedora-related changes
to it
(diff helped out here).
J.A.K.E. [ jake1138 AT yahoo DOT com ]
lol, I must say you did a very good job of being as vague as possible and not illustrating your point in any way.
You're right, but I did get the discussion started. All one needs to do is read the comments in php.ini. When the comments say, "don't do this in a production environment" or "don't use this file in a production environment", then that in of itself makes the point. If you look at php.ini-recommended, you'll learn even more. Part of my reasoning for even mentioning this here is to make people aware. Here is the "diff php.ini php.ini-recommended". For those who haven't used diff before, the lines preceded by "<" are from php.ini, the lines preceded by ">" are from php.ini-recommended.
< output_buffering = Off
output_buffering = 4096
< allow_call_time_pass_reference = On
allow_call_time_pass_reference = Off
< error_reporting = E_ALL & ~E_NOTICE
error_reporting = E_ALL
< display_errors = On
display_errors = Off
< log_errors = Off
log_errors = On
< variables_order = "EGPCS"
variables_order = "GPCS"
< register_argc_argv = On
register_argc_argv = Off
< magic_quotes_gpc = On
magic_quotes_gpc = Off
< extension_dir = /usr/lib/php4
extension_dir = "./"
< sendmail_path = /usr/sbin/sendmail -t -i
;sendmail_path =
< dbx.colnames_case = "unchanged"
dbx.colnames_case = "lowercase"
< session.save_path = /tmp
;session.save_path = /tmp
< session.gc_divisor = 100
session.gc_divisor = 1000
< session.bug_compat_42 = 1
session.bug_compat_42 = 0
< url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
To make php.ini-recommended work for Fedora, I changed this line:
extension_dir = /usr/lib/php4
-- J.A.K.E. [ jake1138 AT yahoo DOT com ]
From: "Adam Voigt"
On Mon, 2004-06-28 at 18:07, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development,
not
production use. I ended up grabbing the "php.ini-recommended" file from
the
official release of PHP-4.3.6 and made a couple Fedora-related changes
to it
(diff helped out here).
J.A.K.E. [ jake1138 AT yahoo DOT com ]
lol, I must say you did a very good job of being as vague as possible and not illustrating your point in any way.
You're right, but I did get the discussion started. All one needs to do is read the comments in php.ini. When the comments say, "don't do this in a production environment" or "don't use this file in a production environment", then that in of itself makes the point. If you look at php.ini-recommended, you'll learn even more. Part of my reasoning for even mentioning this here is to make people aware. Here is the "diff php.ini php.ini-recommended". For those who haven't used diff before, the lines preceded by "<" are from php.ini, the lines preceded by ">" are from php.ini-recommended.
< output_buffering = Off
output_buffering = 4096
< allow_call_time_pass_reference = On
allow_call_time_pass_reference = Off
< error_reporting = E_ALL & ~E_NOTICE
error_reporting = E_ALL
< display_errors = On
display_errors = Off
< log_errors = Off
log_errors = On
< variables_order = "EGPCS"
variables_order = "GPCS"
< register_argc_argv = On
register_argc_argv = Off
< magic_quotes_gpc = On
magic_quotes_gpc = Off
< extension_dir = /usr/lib/php4
extension_dir = "./"
< sendmail_path = /usr/sbin/sendmail -t -i
;sendmail_path =
< dbx.colnames_case = "unchanged"
dbx.colnames_case = "lowercase"
< session.save_path = /tmp
;session.save_path = /tmp
< session.gc_divisor = 100
session.gc_divisor = 1000
< session.bug_compat_42 = 1
session.bug_compat_42 = 0
< url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
To make php.ini-recommended work for Fedora, I changed these lines:
extension_dir = /usr/lib/php4 sendmail_path = /usr/sbin/sendmail -t -i
-- J.A.K.E. [ jake1138 AT yahoo DOT com ]
Jason Aeschilman wrote:
mentioning this here is to make people aware. Here is the "diff php.ini php.ini-recommended". For those who haven't used diff before, the lines preceded by "<" are from php.ini, the lines preceded by ">" are from php.ini-recommended.
Is it just me, but I'm so used to diff -u patches that the origional format looks ugly and hard to read?
Am Di, den 29.06.2004 schrieb Jason Aeschilman um 0:51:
< output_buffering = Off
output_buffering = 4096
< allow_call_time_pass_reference = On
allow_call_time_pass_reference = Off
< error_reporting = E_ALL & ~E_NOTICE
error_reporting = E_ALL
< display_errors = On
display_errors = Off
< log_errors = Off
log_errors = On
< variables_order = "EGPCS"
variables_order = "GPCS"
< register_argc_argv = On
register_argc_argv = Off
< magic_quotes_gpc = On
magic_quotes_gpc = Off
< extension_dir = /usr/lib/php4
extension_dir = "./"
< sendmail_path = /usr/sbin/sendmail -t -i
;sendmail_path =
< dbx.colnames_case = "unchanged"
dbx.colnames_case = "lowercase"
< session.save_path = /tmp
;session.save_path = /tmp
< session.gc_divisor = 100
session.gc_divisor = 1000
< session.bug_compat_42 = 1
session.bug_compat_42 = 0
< url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
To make php.ini-recommended work for Fedora, I changed these lines:
extension_dir = /usr/lib/php4 sendmail_path = /usr/sbin/sendmail -t -i
J.A.K.E.
Besides "register_argc_argv" and "magic_quotes_gpc", which settings do you feel make PHP on Fedora insecure? About both named settings you could discuss, I do not take them as that bad default.
You opened a can with your topic/thread and I do not see it really filled.
Alexander
On Mon, Jun 28, 2004 at 04:07:30PM -0600, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development, not production use. I ended up grabbing the "php.ini-recommended" file from the official release of PHP-4.3.6 and made a couple Fedora-related changes to it (diff helped out here).
The php.ini in Fedora Core 2 is based on php.ini-recommended rather than the development defaults. The differences are not really that significant, and I don't see which changes matter to "security"; can you explain why you say "insecure by default"?
joe
On Tue, Jun 29, 2004 at 02:23:31PM +0100, Joe Orton wrote:
On Mon, Jun 28, 2004 at 04:07:30PM -0600, Jason Aeschilman wrote:
Why is PHP insecure by default on FC1? Is it because it's not for production use? It uses a php.ini that is only suited for development, not production use. I ended up grabbing the "php.ini-recommended" file from the official release of PHP-4.3.6 and made a couple Fedora-related changes to it (diff helped out here).
The php.ini in Fedora Core 2 is based on php.ini-recommended rather than the development defaults. The differences are not really that significant, and I don't see which changes matter to "security"; can you explain why you say "insecure by default"?
I have no idea what the initial poster intended but all scripting and programming languages are 'insecure' in that they can do stuff.
One important php problem is how it acts in a multi user context without additional support from the OS. (The most common situation for this is in Apache (httpd).)
Since the web server's use of php is little different than the use a user might put it to in the context of a scripting language there is an interesting trade off in how it should be configured.
Sadly there are a number of applications (squirrel mail comes to mind) that want to use php options that are not good choices on a web site where php is used for other purposes. If a web site has one and only one programmer this is not a problem. But if this same site permits multiple programmers on multiple virtual domains it can quickly become a problem that one user can look over the shoulder of another site and perhaps see or do things that are undesired.
Java by design has some tricks to help here and is a better programming language and ENVIRONMENT to this end. IMO, All of this will improve as people match the mechanisms that SELinux provides to parts of this problem, but defaults will not cover this topic.
The important point in the comments is that the php.ini file is designed for the development of php script. The developer must design security into the application. Well designed applications should be fine with the defaults (YMMV)
Summary: The defaults for php are not too bad for a single owner, simple host/server. More complex things need changes but no set of defaults will address this issue short of making things impossible for all (example: chmod -x /usr/bin/php ;-) ). RTFM cgi, exec().
Parser Warnings: warning good undefined warning bad undefined warning policy undefined
-
Adam Voigt -
Alexander Dalloz -
Jason Aeschilman -
Joe Orton -
John Wendel -
Mike Fedyk -
Richard Emberson -
Tom Mitchell