Would the Q V NIC DET show any different results than the Q VSWITCH DET
on VM? When I take a look at another guest the output from both commands
is almost the same.
When on VM, the output from the Q VSWITCH DET doesn't show any
differences between the 3 guests.
Berry.
-Original Message-
On Mon, 2 Nov 2009 21:00:18 -0600
Marcy Cortes marcy.d.cor...@wellsfargo.com wrote:
You can restrict them up the wazoo but if someone has written a security law
that says remove unnecessary accounts, you'd like them to stay removed when
you remove them.
And it's pretty darn hard to convince
On Mon, 2 Nov 2009, Jack Woehr wrote:
Which is why I reflexively snarl I hear about fools
masquerading as computer security personnel handing down
such guidelines.
But they are NOT 'masquerading as computer security personnel'
-- From Marcy's sending email domain, I suspect that she is
Marcy Cortes wrote:
Thanks Scott. I started to answer that question earlier but apparently didn't
hit send.
Userdel is what I used to remove them from the golden image.
I suspect is was maintenance. Recently SP3 went on a bunch of servers.
rpm -qf /etc/passwd will tell you who owns
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On
Behalf Of Mark Post
Sent: Monday, November 02, 2009 11:25 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Where does games come from?
On 11/2/2009 at 11:53 PM, Jack Woehr j...@well.com wrote:
-snip-
I
On Tue, 3 Nov 2009 19:21:37 +1300
Rodger Donaldson rod...@diaspora.gen.nz wrote:
Marcy Cortes wrote:
Thanks Scott. I started to answer that question earlier but apparently
didn't hit send.
Userdel is what I used to remove them from the golden image.
I suspect is was maintenance.
R P Herrold wrote:
They are doing a job without any discretion to vary the rules;
There's a wonderful story from Roman imperial history about the Roman
official
in, I think it was Belgium, who rigidly interpreted a tax-in-kind of
hides as ox-hides,
a very expensive commodity, leading to the
On Tuesday, 11/03/2009 at 08:27 EST, McKown, John
john.mck...@healthmarkets.com wrote:
This sort of thing comes up on the z/OS RACF forum with distressing
regularity.
The smart money always responds that the auditor is not the maker of
the
rules / policies. The auditor is supposed to get a list
Very well said Alan ... Chuckie must be still be hung over from
Halloween
Jim Dodds
Systems Programmer
Kentucky State University
400 East Main Street
Frankfort, Ky 40601
502 597 6114
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Alan
Jack Woehr j...@well.com 11/3/2009 9:41 AM
There's a wonderful story from Roman imperial history about the
Roman official in, I think it was Belgium, who rigidly interpreted
a tax-in-kind of hides as ox-hides, a very expensive
commodity, leading to the impoverishment and subsequent
Alan Altmark wrote:
Marcy's question wasn't unreasonable and neither is the policy to remove
unnecessary account ...
But to implement the policy, *someone* has to be the
arbiter of necessary, and I don't think it should be the system that's
being audited!
In the specific instance, most
On Monday 02 November 2009 22:00, Marcy Cortes wrote:
It's not SuSEconfig. I tried that.
It must be maintenance to some particular package.
Right now, we just clean up. But it would be way better to not have to do
that.
Mark nailed it: the aaa_base RPM is adding the games user in its
Edmund R. MacKenty wrote:
. I don't think the UID/GID can be re-used, as
your vendor controls their assignments for system accounts and useradd(8)
will not assign UID/GID values below 500
That number-below-which is controlled by the contents of /etc/login.defs
I believe, which is an editable
When did Marcy indicate she didn't know the purpose of these accounts?
I think we all get (how could we not by now) that you think it's a bad idea
to remove 'system' ids. That's a valid approach -- but it's not helpful to
Marcy - who obviously disagrees (as do I).
I'm glad you wouldn't be
PAUL WILLIAMSON wrote:
how about imparting some of that vast
knowledge you seem to be harboring in that horse of yours?
I already gave her the best technical advice she's gotten yet.
I said, Don't do that , it doesn't add to your system security and it's
dangerous.
Why does the user
Scott Rohling wrote:
I'm glad you wouldn't be disturbed by user/accounts that you, the sysprog,
deleted and finding them magically restored.
User accounts, yes. System accounts, no ... one is curious, but the
answer is pretty obvious,
One of the first posters in the discussoon nailed it,
Thank you Ed and Mark for the technical info and education. Look for a request.
Thanks Alan for the well written, as usual, perspective. I am on the review
committee for next time around (not becaues of this but another different from
Intel feature :)
And I have had to document all those VM
On Tuesday 03 November 2009 11:16, Jack Woehr wrote:
Edmund R. MacKenty wrote:
. I don't think the UID/GID can be re-used, as
your vendor controls their assignments for system accounts and useradd(8)
will not assign UID/GID values below 500
That number-below-which is controlled by the
On 11/3/2009 at 11:33 AM, Jack Woehr j...@well.com wrote:
-snip-
I'm more disturbed that this kind of snipe hunt, the deleting of
well-known no-login system accounts
that date back in Unix history to the 1980's, is viewed by the Linux 390
community as a useful or
rational activity that
No one has actually answered Paul's question about why it has to exist. I'm
curious about that too for my own edification. Just because its always been
there and things *might* expect it isn't a very good reason in my opinion.
Historically so that games could run as their own user so they
Mark Post wrote:
No one has said it's rational or useful (at least I haven't), but it is
necessary, for the numerous reasons everyone has been relating. Technicians
don't get to ignore executive management mandates. They can, and do, criticize
them and complain about them, but for
On Tuesday 03 November 2009 11:48, Marcy Cortes wrote:
No one has actually answered Paul's question about why it has to exist. I'm
curious about that too for my own edification. Just because its always
been there and things *might* expect it isn't a very good reason in my
opinion.
I'll take
Edmund R. MacKenty wrote:
removes a headache for you. I don't think the UID/GID can be re-used, as
your vendor controls their assignments for system accounts and useradd(8)
will not assign UID/GID values below 500 unless you explicity ask for it with
the -r option, which you're not going to
Alan Altmark wrote:
In a Unix system, having a process to ensure that you *don't* orphan files
when deleting an account would seem to be de riguer. If any file exists
to which said uid has privileges, then why would you delete the account
until you clean up the files? I'm not a Unix
Jack wrote:
I'm more disturbed that this kind of snipe hunt, the deleting of
well-known no-login system accounts
that date back in Unix history to the 1980's, is viewed by the Linux 390
community as a useful or
rational activity that can be mandated by management without your
laughing in
Jack Woehr wrote:
Edmund R. MacKenty wrote:
. I don't think the UID/GID can be re-used, as your vendor controls
their assignments for system accounts and useradd(8) will not assign
UID/GID values below 500
That number-below-which is controlled by the contents of /etc/login.defs
I believe,
On Tuesday 03 November 2009 12:26, Jack Woehr wrote:
The length of your post is itself indicative of how much effort is
required to perform this unnecessary task :)
Actually, the length is only indicative of my tendency to type more than is
necessary. I reduced your six tasks for Marcy to just
The questioner didn't know to look in the control files for the
numerical limits on uid's.
Are you talking about me? I do too know how to do that. :-P
Let's not get carried away with assumptions here.
Marcy
--
For LINUX-390
I've been hesitant to throw additional fuel on an already robust fire,
but... Having been through the proverbial mill on this topic in a
previous life, allow me to pose a question:
- Can anybody cite an URL for any specification of predefined system
accounts (games or otherwise) beyond root
Edmund R. MacKenty wrote:
It's actually a lot simplier than this, Jack.
The length of your post is itself indicative of how much effort is
required to perform this unnecessary task :)
How is PAM involved in this? PAM doesn't assign accounts, it is just an
authentication layer. There's
Edmund R. MacKenty wrote:
, this task is necessary simply because it
was ordered by those with the authority to assign tasks.
Yo ree oh, ree oh rum! (The song of the Winkies at the castle of the
Wicked Witch of the West)
It's /etc/login.defs where those values are defined. We don't
Alan Altmark wrote:
the best Bad Things can and do masquerade as Good Things.
Hey, I thought we were going to avoid politics! :)
In a Unix system, having a process to ensure that you *don't* orphan files
when deleting an account would seem to be de riguer.
Empirically:
* 733T Unix
On Tuesday 03 November 2009 11:55, Jack Woehr wrote:
Well, in any case, now Marcy is committed to:
It's actually a lot simplier than this, Jack.
* removing the accounts
Run userdel games groupdel games.
* validating that pam.conf disallows the reassignment of these accounts
How is
On Tuesday, 11/03/2009 at 10:52 EST, Jack Woehr j...@well.com wrote:
Alan Altmark wrote:
But to implement the policy, *someone* has to be the
arbiter of necessary, and I don't think it should be the system
that's
being audited!
In the specific instance, most estimable Alan, your general
There has been quite a bit of work in the slub allocator to mitigate
inode and dentry memory usage. Late 2007, early last year from memory.
Badly designed code can eat memory this way as per the link from Brad -
updatedb is the typical flogging horse.
I'd be inclined to run slabtop sorted on
Jerry Whitteridge wrote:
I'd agree with Marcy here. I'd have a hard time justifying an ID or
Group on a business server that called itself games,
Believe me, I understand. My granddaughter still separates the mushrooms
out of her spaghetti sauce one by one. :)
Thanks for the chat, all!
--
Jack wrote:
Well, you're a very dutiful employee and they're lucky to have you. You
still should kick 'em in the butt once in a while
so they don't start to think that the reason you obey them is that
they're smarter than the average fifth grader!
Well, I do that when it is worth it.
A
Dominic Coulombe wrote:
Thank you, Dominic. This is consistent with what I could find for
system specifications at the time -- and puts games into the exact
same *convention* category as the other userids the auditor was casting
stinkeye on at at the time.
Auditors like rules. They're funny
Ron Wells wrote:
Not recv'ing / seeing packets being sent from Linux box..only see them
coming inbound??
Where can I start looking
Going through VSWITCH where OSA-Gig card is set
z/VM5.4
SLES 10 SP2
Linux agfzxt02 2.6.16.60-0.42.4-default #1 SMP Fri Aug 14 14:33:26 UTC
2009 s390x s390x s390x
Edmund R. MacKenty wrote:
On Tuesday 03 November 2009 11:48, Marcy Cortes wrote:
No one has actually answered Paul's question about why it has to exist. I'm
curious about that too for my own edification. Just because its always
been there and things *might* expect it isn't a very good reason
Edmund R. MacKenty wrote:
On Tuesday 03 November 2009 11:16, Jack Woehr wrote:
Edmund R. MacKenty wrote:
. I don't think the UID/GID can be re-used, as
your vendor controls their assignments for system accounts and useradd(8)
will not assign UID/GID values below 500
That number-below-which
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On
Behalf Of Marcy Cortes
A userid called games on a server is so not worth it!
And I agree with what Dan is on to here. If it's not part
of the specification, then Novell (and probably Redhat) can
Leslie Turriff wrote:
On Tuesday 03 November 2009 19:42:12 John Summerfield wrote:
I think removal of accounts, as opposed to disabling them, is not
something to undertake lightly. It might be that data there could be
required for legal purposes - recently in a public company in Australia
Marcy Cortes wrote:
Jack, this Linux 390 community consists of folks running Linux on very
expensive hardware purchased by companies that view security as a very top
priority.
And the nologin 'games' account on those very expensive machines is
still not a security exposure :)
I
Hi Rick,
dentunusd shows how many unused directory entries (dentries) you have in
the kernel's memory cache. Dentries are stored on disk, and contain
information about a specific directory. They're cached in memory for
faster access as you change directories. For a rough example, try
'mkidr
On 11/3/2009 at 3:56 PM, Rick Truett retru...@verizon.net wrote:
Hello, I am looking for an explanation of the value returned in the
dentunusd field from the sar -v command. I have values in teh millions
and would like to understand why the value is so high.
According to man sar
dentunusd
On Tuesday 03 November 2009 19:42:12 John Summerfield wrote:
Alan Altmark wrote:
In a Unix system, having a process to ensure that you *don't* orphan
files when deleting an account would seem to be de riguer. If any file
exists to which said uid has privileges, then why would you delete
May have deleted any replies...thought I'd try again..
- Forwarded by Ron Wells/AGFS/AGFin on 11/03/2009 03:55 PM -
From:
Ron Wells/AGFS/AGFin
To:
Linux on 390 Port LINUX-390@VM.MARIST.EDU
Date:
11/03/2009 01:27 PM
Subject:
Re:TCPDUMP
Not recv'ing / seeing packets being sent from Linux
Would the Q V NIC DET show any different results than the Q VSWITCH DET
on VM? When I take a look at another guest the output from both commands
is almost the same.
One of the things that show up on the q v nic det that does not appear to
show up on the q vswitch det is the actual MAC given by
49 matches
Mail list logo
