Re: Regina on SLES 11 SP 1
On Wed, 31 Aug 2011 16:40:58 -0500 Tom Duerbusch wrote: > Thanks Mark > > That was it. > I would have thought that my current directory would be searched prior to > searching the path. Nope - it's called "security" The old Unixes did use to put . at the start of the path by default, and people used to leave executables with names like "ls" in /tmp [1]. If you put it at the end as people then did then folks put binaries like "sl" in /tmp and wait. Nowdays most people I know have a ~/bin on their path where they can drop binaries. Alan [1] Something like this was popular back in my student days. #!/bin/sh cp ./ls ~/ls 2>/dev/null echo "sleep 1" >>~/.profile /bin/ls $* So you really don't want "." in your path. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Regina on SLES 11 SP 1
On Thu, Sep 01, 2011 at 12:11:02PM +1200, Andrej wrote:
> On 1 September 2011 10:39, Philipp Kern wrote:
> >> That might be worth considering for Linux
> > You shouldn't do that there's the slightest possibility that you end up in
> > an
> > untrusted path (where somebody can drop executable files) with cd and
> > execute
> > something there (think of "ls").
> > That's why "." isn't in the PATH by default and normally shouldn't be.
> It's actually not so problematic for non-privileged users, specially if
> you tack the dot at the END of your PATH; system executables for e.g.,
> 'ls' will be found before the maliciously placed file in /tmp
> export PATH=${PATH}:.
You'd be surprised how much you can screw up even while not being a privileged
user. You can continously try to escalate your privileges through sudo in the
background, which gets more and more popular (it even has a "-n" for
non-interactive mode). If X is running you can sniff all keystokes including
passwords. (Even if Xauthority is in some random path with gdm3 nowadays, you
can still sniff the environment of the user's binaries to find it.)
As Alan said you can also use typo'ed binary names. Some shells also try to be
helpful and might propose the rogue command as the run you actually wanted to
run. (As you can assume that everything that's proposed exists as a runnable
binary on the system.)
So no, I beg to differ on the "not so problematic".
Kind regards,
Philipp Kern
--
.''`. Philipp KernDebian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp:p...@0x539.de Wanna-Build Admin
`-finger pkern/k...@db.debian.org
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
signature.asc
Description: Digital signature
Re: Enabling core dumps for RHEL 6
Turns out this can be a 2 step process and so far I don't understand when the
second step is needed but we needed it.
First set 'ulimit -c unlimited' or /etc/security/limits to "soft core
unlimited" like has been advised. This will get cores for some process such as
a new SSH session but not for most process.
Second you need something like:
DAEMON_COREFILE_LIMIT=unlimited
export DAEMON_COREFILE_LIMIT
this will set the core size to unlimited for all new process. In
/etc/init.d/functions there is this line that is the reason this is needed:
corelimit="ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0}"
To survive a reboot, you can add DAEMON_COREFILE_LIMIT='unlimited' to
/etc/sysconfig/init for global changes or for the specific daemon to
/etc/init.d/ or /etc/sysconfig/daemons.
And in case you don't know (I didn't) you can control the location and names of
the cores files in /etc/syscyl.conf with something like 'kernel.core_pattern =
/tmp/core-%p' where %p is the PID number.
I imagine there are others methods to accomplish this but this is what we had
to do. You mileage may vary.
Bobby Bauer
Center for Information Technology
National Institutes of Health
Bethesda, MD 20892-5628
301-594-7474
-Original Message-
From: Brad Hinson [mailto:bhin...@redhat.com]
Sent: Tuesday, August 30, 2011 2:32 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Enabling core dumps for RHEL 6
On Aug 25, 2011, at 11:33 PM, Mark Post wrote:
On 8/25/2011 at 01:10 PM, "Bauer, Bobby (NIH/CIT) [E]"
> wrote:
>> Anybody know how to enable core dumps for RHEL 6. Working with a vendor who
>> has asked for a dump but we can't seem to get one. Haven't found anything in
>> the manuals yet.
>
> Did you read the "Using the Dump Tools on Red Hat Enterprise Linux 6.1 -
> SC34-2607-01" manual on IBM's developerWorks page?
>
>
> Mark Post
If it's an application crash, run 'ulimit -c' to check that core dumps are
enabled for processes. 'ulimit -c unlimited' sets this on the fly (won't
survive a reboot), or you can set it permanently in /etc/security/limits.conf
(better approach).
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: Regina on SLES 11 SP 1
> -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Lionel Dyck > I haven't done it on Linux (yet) but on Windows I always put ;. in the PATH so > that it would always search the current path when I issued a command - > perhaps if I wasn't so fixated on the command line that wouldn't have been > an issue. > That might be worth considering for Linux DANGER WILL ROBINSON! DANGER WILL ROBINSON! DANGER WILL ROBINSON! If . (dot) is in your path at all, make sure it is LAST, and don't EVER do this for root. You don't want to accidentally pick up a "user-created" script in place a real utility. Imagine what happens if the user has a "rm" script in the current dir, and "rm" contains "rm -rf /*" and you happen to be root at the time. Don't do it. Wouldn't be prudent. --d b -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Migrating UNIX application to z/Linux
> If migrating UNIX application to z/Linux, are there incompatabilities? In > other > word, what are general considerations for this kind of migration? I think we need a little more context. Which Unix? Do you have source? What is the customer expecting? Not enough info to give a good answer. -- db -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Regina on SLES 11 SP 1
I'm glad I haven't added the 'dot' to my path for linux yet as I've learned a lot from y'all. Lionel B. Dyck <>< z Client Architect IBM Corporation - West IMT Mobile Phone: 1-925-207-4518 E-mail: lionel.d...@us.ibm.com System z: www-03.ibm.com/systems/z/ Linux on z: http://www-03.ibm.com/systems/z/os/linux/ Destination z: http://www-03.ibm.com/systems/z/destinationz/index.html/ "Think Inside the z Box" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Regina on SLES 11 SP 1
And it's not just looking out for an rm script in a directory either. We all make typos so the sneaky ones create scripts like "cta" or "gerp" that will sit there waiting for the keyboard challenged. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
HugePage support with RHEL
I am currently looking at the HugePage support feature and whether it can help us at our site. But I hit a roadblock that someone out there may be able to help me with. In the doc I have found (both from RH and a collection of other presentations on the web), I have found how to set the /proc/sys/vm/nr_hugepages value with sysctl with no problem. But my concern is with the next bit of information concerning whether the hardware has large page support and if not, how do I enable that support. When I issue cat /proc/cpuinfo, we do not have the "edat" value set in features (page 26 in http://zjournal.tcipubs.com/issues/zJ.DEC-JAN09.pdf). We have two z196s with zVM 6.1 running zLinux guests using RHEL 5.6 (2.6.18-238.9.1.el5). Can anyone point me to how to get the feature "edat" turned on and where documentation on this may be located? James Chaplin Systems Programmer, MVS, zVM & zLinux -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HugePage support with RHEL
Hi James, It appears that in order to use hardware large page support, Linux must be running in LPAR mode. I can't find anything that says this is supported in z/VM. Hopefully someone can correct me if I'm wrong. I can confirm that on a z10 under z/VM 6.1 I also do not see 'edat' in /proc/cpuinfo, so hugepage support is emulated in software. See here: http://linuxvm.org/present/SHARE111/S9262ms.pdf (see slide 11) -- Brad Hinson Worldwide System z Sales, Strategy, Marketing Red Hat, Inc. +1 (919) 360-0443 http://www.redhat.com/z On Sep 1, 2011, at 11:31 AM, CHAPLIN, JAMES (CTR) wrote: > I am currently looking at the HugePage support feature and whether it > can help us at our site. But I hit a roadblock that someone out there > may be able to help me with. > > > > In the doc I have found (both from RH and a collection of other > presentations on the web), I have found how to set the > /proc/sys/vm/nr_hugepages value with sysctl with no problem. But my > concern is with the next bit of information concerning whether the > hardware has large page support and if not, how do I enable that > support. When I issue cat /proc/cpuinfo, we do not have the "edat" value > set in features (page 26 in > http://zjournal.tcipubs.com/issues/zJ.DEC-JAN09.pdf). We have two z196s > with zVM 6.1 running zLinux guests using RHEL 5.6 (2.6.18-238.9.1.el5). > > > > Can anyone point me to how to get the feature "edat" turned on and where > documentation on this may be located? > > > > James Chaplin > > Systems Programmer, MVS, zVM & zLinux > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HugePage support with RHEL
On Thu, Sep 01, 2011 at 03:01:52PM -0400, Brad Hinson wrote: > It appears that in order to use hardware large page support, Linux must be > running in LPAR mode. I can't find anything that says this is supported in > z/VM. Hopefully someone can correct me if I'm wrong. I can confirm that on > a z10 under z/VM 6.1 I also do not see 'edat' in /proc/cpuinfo, so hugepage > support is emulated in software. And I can confirm that it's there on a z10 in LPAR mode. :) Kind regards, Philipp Kern -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Migrating UNIX application to z/Linux
We have some clients who have plan to migrate there applications running on UNIX to z/Linux. We have not communicate with those clients yet, so I don't have detail info. Before that, I just seek if there are some general considerations about migration, so that I can have good preparation for our first met with clients. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Migrating UNIX application to z/Linux
Well, some general considerations I know of are: 1. J2EE apps are usually ok. Unless they exploit something in Sun Java that is different in IBM Java. We've not had issues, but some college I know has not been that lucky. If they've written the java program themselves, changes may not be that difficult. If it's a large package from some open source thing or something, it may be more challenging. We've had vendors bring their J2EE banking packages to z with no issues. 2. The platform isn't binary compatible with Intel. You will have to recompile. Hopefully they have source. If so, no big deal. 3. There are endian (little big) considerations. You can go google that for more info. Hope that is semi useful. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Lu GL Gao Sent: Thursday, September 01, 2011 6:52 PM To: LINUX-390@vm.marist.edu Subject: Re: [LINUX-390] Migrating UNIX application to z/Linux We have some clients who have plan to migrate there applications running on UNIX to z/Linux. We have not communicate with those clients yet, so I don't have detail info. Before that, I just seek if there are some general considerations about migration, so that I can have good preparation for our first met with clients. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Migrating UNIX application to z/Linux
If they are moving from Solaris then IBM used to have (and probably still has) a tool which you run against the customer's source code to identify areas that need attention when porting (e.g. use of Solaris threads v POSIX threads). It produces a nice report that makes the porting effort easier. If you are looking at moving databases then it's a matter of unload/load. If they are different database managers then there's going to be more work (schema differences, different implementation of standards, procedural languages etc.). If they have executables but no source and there's no version of that package available for Linux on z then you will have to go through a process of determining functional equivalences and will probably have to compromise on features. In some instances, there may be no equivalent and your customer will have to make the decision about finding an alternative or leaving that package behind. Then there's the files the data used by those apps. are stored in. Is it a little endian system where you need to write a conversion or unload/load utility. Neale On 9/1/11 9:51 PM, "Lu GL Gao" wrote: > We have some clients who have plan to migrate there applications running on > UNIX to z/Linux. We have not communicate with those clients yet, so I don't > have detail info. > Before that, I just seek if there are some general considerations about > migration, so that I can have good preparation for our first met with > clients. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
