Re: Re: How to install latest VLC 2.1.0 in debian

[Anubhav Yadav]

Actually, I just changed the subject of another thread and it came up as
a different thread on mailing list!

I will try out the deb-multimedia repository. Thanks! 
-- 
Regards, 
Anubhav Yadav,
Computer Engineering Final Year Student,
Imperial College of Engineering and Research,
Pune.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1380951905.6098.2.camel@Innovator

ddrescue and windowsxp

[steef]

hi folks,

my eldest daughter has an old laptop with windowsxp loaded on it. the 
machine crashed yesterday.


my question: can i use debian and the ddrescue-procedure to save the 
data of this laptop like i did about 7 years ago with a crashed 
slackware_hd??


google confused me.

thank you,

steef


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/524fc84c.1000...@home.nl

Re: Debian-LAN: installing a complete network environment

[Nico Kadel-Garcia]

I've been working with both Kerberos and Samba for 20 years. Writing "Yet
Another Authentication Management Tool(tm)" sounds unappealing, since there
are so many well established and tested ones. I'm actually curious what you
found inadequate about Samba, especially if you used the 4.0.x releases
which have stabilized the LDAP/Kerberos interactions in effective
cross-platform ways.

Now, if our friends over in Debian wanted to improve an underlying Kerberos
tool that's used for both Debian and Scientific Linux and other red Hat
based systems, I'd look at the "authconfig" tool and its /etc/pam.d
interactions, which are very flexible and not well managed. *Try* using
"authconfig" to delete the default enabled "example.com" Kerberos domain
from /etc/krb5.conf, or to manage integraiton with upstream Kerberos
domains, I dare you, Or try preventing "authconfig" from resetting values
which you didn't put in the command line, or getting it to load from an
actual configuration file, or to enable local password expiration. It gets
crazy out there!

But that's not a Kerberos problem, that's an authconfig and pam.d managemnt
problem.


On Fri, Oct 4, 2013 at 11:13 PM, Darko Gavrilovic wrote:


> To each his own. I actually like the post and his project idea. Also,
> claiming that Samba is the be all and end all to all enterprise client
> scenarios out there is a little over stating it. On more a few times
> have we have to drop Samba as it proved to be inadequate for the
> situation.
>

Re: Re (2): Multiplicity of accounts.

[Joel Rees]

On Sat, Oct 5, 2013 at 10:56 AM, Jerry Stuckle  wrote:
> On 10/4/2013 9:25 PM, Joel Rees wrote:
>>
>> Not top posting, just prefacing my comments:
>>
>> Are we trying to educate the list in cracking techniques or in ways to
>> manage and mitigate the vulnerabilities?
>>
>> On Fri, Oct 4, 2013 at 10:36 PM, Jerry Stuckle 
>> wrote:
>>>
>>>
>>> On 10/4/2013 5:10 AM, Joel Rees wrote:

 Should I add to the confusion?

 On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle 
 wrote:
>
> On 10/3/2013 8:45 AM, Joel Rees wrote:
>>
>>
>> On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle 
>> wrote:
>>>
>>>
>>> On 10/2/2013 12:24 PM, peasth...@shaw.ca wrote:



 From:   Joel Rees 
 Date:   Wed, 2 Oct 2013 15:30:26 +0900
>
>
>
> [...]
>>>
>>>
>>>
> And accessing your bank logged in as the same user that you use to
> surf random sites is one of the primary causes of leaked bank
> account
> numbers and passwords.




 The banking information is stored in a cookie.  Subsequently a site
 other
 than the bank is allowed to read the cookie?  A failure of the
 browser.
 Correct?  Prior to studying this thoroughly, I might stick to
 personal
 banking.

>>>
>>> Not if your browser is working properly.  Cookies can only be sent to
>>> the
>>> domain which originated them (and, depending on the cookie options,
>>> subdomains of the main domain).
>>
>>
>>
>> subdomains.
>>
>> And too many places, bank sites included, outsource parts of their
>> sites. Particularly ad-related stuff.
>>
>
> It doesn't matter if they outsource parts of their sites.  Those
> outsourced
> sites will have different domains, and the cookies cannot be sent to
> them.


 You must be looking at the page source code of different banks than I
 am.

>>> What banks do you know outsource subdomains to someone else?
>>
>>
>> Exposure here would only motivate the banks if they were reading this
>> mailing list.
>>
>> Exposure here would only warn their customers if their customers, or
>> even their customers' friends, were reading this mailing list.
>>
>> I don't think it would be responsible to name names here, do you?
>>
>> However, for users of this list, trying to manage the vulnerabilities
>> they expose themselves to, the odds that your bank is using known
>> vulnerable techniques are high enough that you need to take some
>> effort to limit your own exposure.
>>
>
> If there were ANY bank which had to read this list to find out they were
> exposed, they need a new IT department.
>
> I don't know about where you are - but here in the United States, they
> wouldn't get very far.  There are many layers of regulations and protections
> regarding banking security.  And any bank which had such security exposures
> as you claim would not be allowed to continue operations.
>
> And no, I am VERY confident ANY bank I have dealt with knows how to manage
> vulnerabilities.  What makes you think otherwise?

Hmm. How does one answer such a riff?

https://www.google.co.jp/#q=us+bank+vulnerability

and

https://www.google.co.jp/#q=bank+information+technology+incompetent

The results of that second search would be quite amusing in some sort
of slapstick comedy, although some do include language that would not
be approved here. And I am sure the individuals blogging their
experiences were not amused.

And then I had a "flash" of insight:

>>> [...]

> HTML is a scripting language.  Nothing more, nothing less.  [...]
>>> [...]

I've had managers who couldn't tell the difference between a markup
language and a scripting language, but I'm sure you can.

You're just playing with me. Thanks anyway, Jerry, but I really do
have homework to do today.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAr43iO3RyzAX-V3AvqPnhN+J0mARrqSAGpmhDsDbUoVwQq=k...@mail.gmail.com

[OT] List software, duplicate mail, or not. (was ... Re: Building computer)

[Chris Bannister]

On Fri, Oct 04, 2013 at 05:44:44AM -0400, Paul Cartwright wrote:
> On 10/03/2013 05:11 PM, Stan Hoeppner wrote:
> > No apology necessary.  I'm on many open lists (LKML) where hitting
> > reply-to-list only goes to the sender.  So I've been guilty myself a few
> > times.
> >  
> so that is list specific... I wondered, because sometimes I hit reply &
> it goes to the person, other times it goes to the list.. Thunderbird..

I think it has been discussed before, but depending on the list software
used and the settings, if someone CC's you then you get a private mail
but not a list mail - it still goes to the list, it's just that *you*
don't get a copy!

It seems as though this started because people who are from Windows
might get confused with getting two copies of a mail!!!

A couple of times I recd a private email which was also addressed to a
list and deleted it (because it makes more sense to reply to the list,
obviously) but when I opened that list's mailbox -- it wasn't there!!

None of the Debian lists I am subscribed to have this serious problem.

There is a personal setting which you can change from your subscription
page, (you're given a password and reminded monthly what is is) which
you can toggle: (unfortunately, on some lists default is yes.)

(*) No
( ) Yes

Avoid duplicate copies of messages?

When you are listed explicitly in the To: or Cc: headers of a list
message, you can opt to not receive another copy from the mailing list.
Select Yes to avoid receiving copies from the mailing list; select No to
receive copies.
-

Sorry to labour the point, but what is happening to logic in the world
today? 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131005040546.GC740@tal

Re: Debian-LAN: installing a complete network environment

[Darko Gavrilovic]

On Fri, Oct 4, 2013 at 9:28 PM, Nico Kadel-Garcia  wrote:

> Sorry to rain on the parade, but Samba's been pretty good at this since
> Samba was invented in the early 1990's, and it's pretty stable. It also
> plays nicely with other well known network clients and protocols, such as
> Windows based and Mac based clients, so there's really no need to re-invent
> that wheel specifically in Debian. The Debian ports of Samba re up to date
> and quite stable.
>


To each his own. I actually like the post and his project idea. Also,
claiming that Samba is the be all and end all to all enterprise client
scenarios out there is a little over stating it. On more a few times
have we have to drop Samba as it proved to be inadequate for the
situation.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAGYSLOcZc13uGL5BTUAMb+qj=qxglwsdda+gnthbfjbcahg...@mail.gmail.com

Re: Re (2): Multiplicity of accounts.

[Jerry Stuckle]

On 10/4/2013 9:25 PM, Joel Rees wrote:

Not top posting, just prefacing my comments:

Are we trying to educate the list in cracking techniques or in ways to
manage and mitigate the vulnerabilities?

On Fri, Oct 4, 2013 at 10:36 PM, Jerry Stuckle  wrote:


On 10/4/2013 5:10 AM, Joel Rees wrote:

Should I add to the confusion?

On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle 
wrote:

On 10/3/2013 8:45 AM, Joel Rees wrote:


On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle 
wrote:


On 10/2/2013 12:24 PM, peasth...@shaw.ca wrote:



From:   Joel Rees 
Date:   Wed, 2 Oct 2013 15:30:26 +0900



[...]




And accessing your bank logged in as the same user that you use to
surf random sites is one of the primary causes of leaked bank account
numbers and passwords.




The banking information is stored in a cookie.  Subsequently a site
other
than the bank is allowed to read the cookie?  A failure of the
browser.
Correct?  Prior to studying this thoroughly, I might stick to personal
banking.



Not if your browser is working properly.  Cookies can only be sent to
the
domain which originated them (and, depending on the cookie options,
subdomains of the main domain).



subdomains.

And too many places, bank sites included, outsource parts of their
sites. Particularly ad-related stuff.



It doesn't matter if they outsource parts of their sites.  Those
outsourced
sites will have different domains, and the cookies cannot be sent to
them.


You must be looking at the page source code of different banks than I am.


What banks do you know outsource subdomains to someone else?


Exposure here would only motivate the banks if they were reading this
mailing list.

Exposure here would only warn their customers if their customers, or
even their customers' friends, were reading this mailing list.

I don't think it would be responsible to name names here, do you?

However, for users of this list, trying to manage the vulnerabilities
they expose themselves to, the odds that your bank is using known
vulnerable techniques are high enough that you need to take some
effort to limit your own exposure.



If there were ANY bank which had to read this list to find out they were 
exposed, they need a new IT department.


I don't know about where you are - but here in the United States, they 
wouldn't get very far.  There are many layers of regulations and 
protections regarding banking security.  And any bank which had such 
security exposures as you claim would not be allowed to continue operations.


And no, I am VERY confident ANY bank I have dealt with knows how to 
manage vulnerabilities.  What makes you think otherwise?



And no bank would be stupid enough to create a subdomain and hand it over
to
some unknown entity.  They wouldn't be in business for long if they did.


Banks should be smart enough to not use flash on any part of any page
where they have people logging in. Maybe there are some that are, but
there sure are many that aren't.


So what?  If they wrote the flash code, they know whether it is safe or not.


Do you know all the places the flash code you've written can break?



Yes, I do.  I wrote it.

The problem is not the flash code breaking; it is hackers who make use 
of vulnerabilities in the flash base.


How much flash code have YOU written?


And Flash isn't the only place code fed to the browser can break the
browser, of course. Javascript, even Google's implementation, still
has vulnerabilities. Every plugin could break the browser, and
specific discussion of where browsers could break should be
unnecessary here. Unless you want me to teach the list cracking
techniques, which I'm inclined to try to avoid.



Banks don't use plugins, and javascript is pretty secure.  But again, 
the problem is not javascript - but it is the hacker's use of javascript 
to exploit vulnerabilities.  Those vulnerabilities are not cross-browser.


As for plugins - it's the same as any other program.  Only install 
plugins from sources you trust.



Calling the stuff HTML 5 did not fix all those, it just laid out a
framework within which a properly written HTML 5 compliant web page
can avoid the worst problems.



HTML is a scripting language.  Nothing more, nothing less.  It has 
nothing to do with security - as anyone who really understood it can 
tell you.



Just because it is flash does not in itself say whether the code is safe or
not.


I'll go with that the day the last vulnerability gets published. :-/



Once again, you don't understand the vulnerabilities.


And once again, even if it flash from an advertiser on another domain, it
will not be able to harvest your userid/password.


In the ideal world. All it takes is a successful code injection to
break that, even when the domains are done right.



And how are you going to get that code injection?


And the domains are too often done wrong. Describing how is not
appropriate here.



No, banking domains are not "done wrong".  And you won't describe how 
because you don't u

Re: Debian-LAN: installing a complete network environment

[Nico Kadel-Garcia]

Wait, I know? L:et's have it do dynamic DNS, host authentication, and LDAP
based account management, too! And in 20 years, maybe it'll have 1/1000th
the number of users that the Samba suite has right now, for all of that,
especially including robust and tested Kerberos management with already
tested tools!

Sorry to rain on the parade, but Samba's been pretty good at this since
Samba was invented in the early 1990's, and it's pretty stable. It also
plays nicely with other well known network clients and protocols, such as
Windows based and Mac based clients, so there's really no need to re-invent
that wheel specifically in Debian. The Debian ports of Samba re up to date
and quite stable.




On Fri, Oct 4, 2013 at 5:18 AM, Andreas B. Mundt  wrote:

> Hi all,
>
> I would like to point your attention to the Debian-LAN project [1].
>
> Debian-LAN is an approach to simplify installing a complete kerberized
> network environment made of Debian machines.  It might be used for
> schools, small enterprises, associations, (university) work groups or
> to install complex test environments.
>
> Debian-LAN provides a way to install a server and various workstation
> profiles [2] by providing a FAI [3] config space for the setup.
>
> The system has been presented on DebConf13, slides and recordings are
> available [4].  The code is in wheezy-backports [5] or on alioth [6].
>
> If you run systems as described above, give Debian-LAN a try!
> Comments and contributions are of course welcome.
>
> Best regards,
>
>  Andi
>
>
> [1] https://wiki.debian.org/DebianLAN>
> [2] https://wiki.debian.org/DebianLAN/Setup_A#Machine_Types>
> [3] http://fai-project.org/>
> [4] http://penta.debconf.org/dc13_schedule/events/962.en.html>
> [5]  http://packages.debian.org/source/stable-backports/debian-lan-config>
> The system's target is always the latest stable Debian release.
> [6] http://anonscm.debian.org/gitweb/?p=collab-maint/debian-lan.git>
>
>
> --
> To UNSUBSCRIBE, email to debian-enterprise-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20131004091807.GA4374@flashgordon
>
>

Re: Re (2): Multiplicity of accounts.

[Joel Rees]

Not top posting, just prefacing my comments:

Are we trying to educate the list in cracking techniques or in ways to
manage and mitigate the vulnerabilities?

On Fri, Oct 4, 2013 at 10:36 PM, Jerry Stuckle  wrote:
>
> On 10/4/2013 5:10 AM, Joel Rees wrote:
>> Should I add to the confusion?
>>
>> On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle 
>> wrote:
>>> On 10/3/2013 8:45 AM, Joel Rees wrote:

 On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle 
 wrote:
>
> On 10/2/2013 12:24 PM, peasth...@shaw.ca wrote:
>>
>>
>> From:   Joel Rees 
>> Date:   Wed, 2 Oct 2013 15:30:26 +0900
>>>
>>>
>>> [...]
>
>
>>> And accessing your bank logged in as the same user that you use to
>>> surf random sites is one of the primary causes of leaked bank account
>>> numbers and passwords.
>>
>>
>>
>> The banking information is stored in a cookie.  Subsequently a site
>> other
>> than the bank is allowed to read the cookie?  A failure of the
>> browser.
>> Correct?  Prior to studying this thoroughly, I might stick to personal
>> banking.
>>
>
> Not if your browser is working properly.  Cookies can only be sent to
> the
> domain which originated them (and, depending on the cookie options,
> subdomains of the main domain).


 subdomains.

 And too many places, bank sites included, outsource parts of their
 sites. Particularly ad-related stuff.

>>>
>>> It doesn't matter if they outsource parts of their sites.  Those
>>> outsourced
>>> sites will have different domains, and the cookies cannot be sent to
>>> them.
>>
>> You must be looking at the page source code of different banks than I am.
>>
> What banks do you know outsource subdomains to someone else?

Exposure here would only motivate the banks if they were reading this
mailing list.

Exposure here would only warn their customers if their customers, or
even their customers' friends, were reading this mailing list.

I don't think it would be responsible to name names here, do you?

However, for users of this list, trying to manage the vulnerabilities
they expose themselves to, the odds that your bank is using known
vulnerable techniques are high enough that you need to take some
effort to limit your own exposure.

>>> And no bank would be stupid enough to create a subdomain and hand it over
>>> to
>>> some unknown entity.  They wouldn't be in business for long if they did.
>>
>> Banks should be smart enough to not use flash on any part of any page
>> where they have people logging in. Maybe there are some that are, but
>> there sure are many that aren't.
>
> So what?  If they wrote the flash code, they know whether it is safe or not.

Do you know all the places the flash code you've written can break?

And Flash isn't the only place code fed to the browser can break the
browser, of course. Javascript, even Google's implementation, still
has vulnerabilities. Every plugin could break the browser, and
specific discussion of where browsers could break should be
unnecessary here. Unless you want me to teach the list cracking
techniques, which I'm inclined to try to avoid.

Calling the stuff HTML 5 did not fix all those, it just laid out a
framework within which a properly written HTML 5 compliant web page
can avoid the worst problems.

> Just because it is flash does not in itself say whether the code is safe or
> not.

I'll go with that the day the last vulnerability gets published. :-/

> And once again, even if it flash from an advertiser on another domain, it
> will not be able to harvest your userid/password.

In the ideal world. All it takes is a successful code injection to
break that, even when the domains are done right.

And the domains are too often done wrong. Describing how is not
appropriate here.

 I play it safe and limit logging in to my bank to a user that does
 nothing but logging into that bank. Hey, it's my computer, I can add
 users all I like.
>>>
>>> Which doesn't make any difference because that's not where the leaks
>>> occur.
>>
>> Huh?
>>
>> I mean a user on my computer. Dedicated to one bank. Reduces the odds
>> that a drive-by from, say, a song lyrics site, will still be sitting
>> in my browser when I visit the bank. If a drive-by does get root,
>> there's no help for that, but at least I can protect myself from the
>> drive-bys that only get local access.
>>
>
> Which still makes no difference, because the lyrics site will not be able to
> read information from your banking site.

So, you want to explain Google's universal login to us?

Sure, it requires a certain level of incompetence to expose cookies,
but the incompetence is still (after about fifteen years) there,
because people want to share information, and they don't want to do it
the right way.

Which actually brings us back to the topic of this thread, the reason
for multiple user ids and group ids. You manage data by limiting its
us

Re: gksudo -u user2 /usr/bin/links2 -g

[Bob Proulx]

Marko Randjelovic wrote:
> > > gksudo -u user2 /usr/bin/links2 -g # does not work
> > 
> > Needs a terminal.  How can it work without one?  It can't.  Right at
> > this point is where thing went wrong for you.  links2 reads stdin and
> > writes stdout and expects TERM to tell it what type of terminal escape
> > sequences to use.  But you have asked gksudo to launch it into the
> > background.  That can't work.  You will end up with both your shell
> > and the links2 program reading from your keyboard at the same time.
> 
> Contrary to sudo behavior, gksudo understood -g option as itself option
> and not, as I expected, as option for links2 to enable graphics mode.

links2 has a -g option?  I did not know that.  I just assumed that the
-g was for gksudo -g,--disable-grab which disabled locking of the
keyboard, mouse, and focus by the program asking for the password.
Which is why in my example I moved it earlier in the command.

But with your comment I am looking at links2 and now see that links2
does have a -g option to run in graphics mode.  Sorry I didn't realize
that previously.  I thought links2 was like lynx, elinks, and w3m.
Meaning a pure text mode browser.

> This works:
> 
> gksudo -u user2 "/usr/bin/links2 -g"

Yay!

With my misunderstanding of the intent cleared up the following works too:

  gksudo -u user2 -- links2 -g

The "--" causes programs to stop parsing options.  Therefore gksudo
won't parse the -g as an option.  It will stop at the "--" and then
the following will be the command verbatim.

Mostly I am chafing at having the full path "/usr/bin/links2" in there
hard coded.  Hard coded paths like that are almost always bad.  Try it
without.  Even with the quoted form I think that is better.

  gksudo -u user2 "links2 -g"

> > The above all suffer from the problem of running the text browser as
> > root.  Why are you trying to do this?  I don't understand any benefit
> > from doing so.  And I see some problems with doing so.  Please say a
> > few words about what led you to doing it that way.  Since it is a web
> > browser it doesn't benefit you by running it as root.
> 
> I am not running it as root, user2 != root.

Darn on me.  I was pretty sure I had a reason for the original problem
and wanted to get a reply out and didn't spend the time to really read
the rest of the message in detail.  My bad.  You had said user2 which
obviously isn't root and it was my mistake that I didn't grok that
plain-to-see point.  Sorry.

> There are many advantages of running every task with separate user
> account. In general, you have better control, because you can
> differentiate various tasks based on running user.

Sure.  My comment had been purely about running commands as root.  But
you were not running as root.  My mistake.  Sorry.

> For example, you can tell iptables to allow port 80 from
> web browser and not from other apps:
> 
> iptables -P OUTPUT DROP
> iptables -A OUTPUT -p tcp --dport 80 -m owner --uid-owner web -j ACCEPT

Sure.  I don't prefer that type of restriction.  For me it isn't
practical.  For example I have an endless number of things that I want
to access the web.  I would be playing wack-a-mole with all of them
for a long time.  Such as apt's sources.list file.  Such as updating
spamassassin rules.  Such as many things.  But if that works for you
then that is great.  I am not trying to talk you out of it.

> Another example, if an attacker gets your web user account, he won't be
> able to read your emails.

If an attacker gets your web mail user account then they will probably
access that web account from a different system.

> So you will force him to get root privileges :) .

??  (He certainly doesn't need root.  He just needs to use a different
system.)  I read that three times and don't get the joke.  But that is
okay!  I don't need to understand it! :-)

> In fact, your question sounds like you asked: "Why we have all those
> user accounts in /etc/passwd since only root and normal user are
> necessary" :) 

Nope.  Nothing of that sort at all.  It was simply my misunderstanding
of the "-u user2" part which was plainly written and certainly isn't
root.  Just too much in a hurry sometimes.

Bob


signature.asc
Description: Digital signature

Re: Building computer

[Stan Hoeppner]

On 10/4/2013 4:44 AM, Paul Cartwright wrote:
> On 10/03/2013 05:11 PM, Stan Hoeppner wrote:
>> No apology necessary.  I'm on many open lists (LKML) where hitting
>> reply-to-list only goes to the sender.  So I've been guilty myself a few
>> times.
>>  
> so that is list specific... I wondered, because sometimes I hit reply &
> it goes to the person, other times it goes to the list.. Thunderbird..

This isn't an issue with TBird, or any MUA.  The clients simply
obey/honor the list headers.  For example:

X-Mailing-List:  archive/latest/657649
List-Id: 
List-Post: 
Precedence: list

The "List-Post:" header contains the list posting address.  When you hit
"reply-to-list" in TBird this is the address it selects for populating
the To: field in the reply.

If you reply to a message sent from a listserver that does not provide a
"List-Post:" header, then the address in the "Reply-To:" header is
inserted into the To: field of the reply.

Ergo, "reply-to-list" only works if a "List-Post" header is present.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524f42b7.3050...@hardwarefreak.com

Re: gksudo -u user2 /usr/bin/links2 -g

[Marko Randjelovic]

> > gksudo -u user2 /usr/bin/links2 -g # does not work
> 
> Needs a terminal.  How can it work without one?  It can't.  Right at
> this point is where thing went wrong for you.  links2 reads stdin and
> writes stdout and expects TERM to tell it what type of terminal escape
> sequences to use.  But you have asked gksudo to launch it into the
> background.  That can't work.  You will end up with both your shell
> and the links2 program reading from your keyboard at the same time.

Contrary to sudo behavior, gksudo understood -g option as itself option
and not, as I expected, as option for links2 to enable graphics mode.

This works:

gksudo -u user2 "/usr/bin/links2 -g"

> The above all suffer from the problem of running the text browser as
> root.  Why are you trying to do this?  I don't understand any benefit
> from doing so.  And I see some problems with doing so.  Please say a
> few words about what led you to doing it that way.  Since it is a web
> browser it doesn't benefit you by running it as root.

I am not running it as root, user2 != root. There are many advantages
of running every task with separate user account. In general, you have
better control, because you can differentiate various tasks based on
running user. For example, you can tell iptables to allow port 80 from
web browser and not from other apps:

iptables -P OUTPUT DROP
iptables -A OUTPUT -p tcp --dport 80 -m owner --uid-owner web -j ACCEPT

Another example, if an attacker gets your web user account, he won't be
able to read your emails.

So you will force him to get root privileges :) .

In fact, your question sounds like you asked: "Why we have all those
user accounts in /etc/passwd since only root and normal user are
necessary" :) 

> 
> Bob

Thanks


signature.asc
Description: PGP signature

Re: gksudo -u user2 /usr/bin/links2 -g

[Bob Proulx]

Marko Randjelovic wrote:
> gksudo -u user2 /usr/bin/epiphany-browser -g # works

Epiphany opens its own graphics window.  gksudo is designed for
applications like epiphany that open its own window.

> sudo -u user2 /usr/bin/links2 -g # works

Sure.  That just runs in the same terminal you started the command.
Nothing interesting there.

> gksudo -u user2 /usr/bin/links2 -g # does not work

Needs a terminal.  How can it work without one?  It can't.  Right at
this point is where thing went wrong for you.  links2 reads stdin and
writes stdout and expects TERM to tell it what type of terminal escape
sequences to use.  But you have asked gksudo to launch it into the
background.  That can't work.  You will end up with both your shell
and the links2 program reading from your keyboard at the same time.

> In terminal, when I run those commands with links, elinks, links2
> (with or without -g), prompt disappears and as i press keys
> characters appear in the terminal. At first run, Welcome screen
> shows, but again no keys have no effect. After CTRL+C, only gksudo
> process disappears, and other 2 remain.
> 
> Does someone have an idea why could this work like this?

It is very similar to running:

  $ lynx &

Except that bash has job control and therefore will stop the process
upon SIGTTOU (Terminal output for background process) and prevent that
from happening.  Because it isn't something you would normally want as
you can see by your problems.  But if you can start a shell without
job control then you would find yourself in the same situation.

The answer is do not use gksu or gksudo on text programs.  For text
programs use su or sudo and run them in the current terminal window.

If you really want to run a text program but want it to launch in a
different terminal *and* want it to use the gksu/gksudo to have it run
as root then you must launch a terminal.  Have the terminal launch
your text application.

  gksudo -u user2 -g -- xterm -e links2

Feel free to use the terminal of your choice.  But specifying the
terminal and the command to run on that terminal makes the most sense
to me.  (Note in Debian the presense of x-terminal-emulator as a
system configured preferred default terminal.  See "update-alternatives
--display x-terminal-emulator" for more.)

The above all suffer from the problem of running the text browser as
root.  Why are you trying to do this?  I don't understand any benefit
from doing so.  And I see some problems with doing so.  Please say a
few words about what led you to doing it that way.  Since it is a web
browser it doesn't benefit you by running it as root.

Bob


signature.asc
Description: Digital signature

Re: Debian installer and raid0

[Bob Proulx]

Francesco Pietra wrote:
> Bob Proulx wrote:
> > After installing simply run the grub install script against both
> > disks manually and then you will be assured that it has been
> > installed on both disks.
> 
> I had problems with that methodology and was unable to detect my error.
> >From a thread on debian dated Mar 2, 2013:
> ...
> > grub-install /dev/sdb
> >  was reported by complete installation. No error, no warning.
> > On rebooting, GRUB was no more found. Then entering in
> > grub rescue >
> > prefix/root/ were now wrong.

If the command does not work on the command line then it won't work
from the installer either.  The installer is doing the same things
that you can do from the command line.  Therefore asking if it is in
the installer won't help.  Because if it doesn't work then it doesn't
work either place.  If it does work then it will work either place.
That is my conjecture at least.  And since I have been using this
feature I believe it does work.  Works for me anyway.

I have been using RAID1 for a long time and have not encountered the
problem you describe.  That doesn't mean that such an error doesn't
occur.  Just that I can't recreate it.  Or rather after much user have
never recreated it.  This applies to both the good grub version 1 as
well as the newer and IMNHO buggier grub version 2 rewrite.  They are
completely different from each other.  Statements made about one do
not apply to the other because it was a complete rewrite.  But it is
certainly possible that in your configuration that you have a case
that does not work.

I have a workbench with a variety of hardware.  When I want to test
something like this I construct a victim system in which to try the
action.  If you could do the same I think it would help to get to the
root cause of the problem.  I would create a victim machine with two
drives for installation testing.  Then test the installation.  After
install and reboot then shutdown, unplug one disk, test boot.  Do not
boot all of the way to the system.  Simply boot to the grub menu and
stop there.  Then power off, switch disks, and test boot again.  Do
not boot all of the way to the system.  Simply boot to the grub menu
and again stop there.  If you can get to the grub menu from either
disk then grub has been installed on both disks.  If not then plug
both disks in and boot the system and test the grub-install script on
the non-booting disk and then repeat the single disk boot.

The reason to only boot to the grub menu is of course so that the
RAID1 doesn't get split.  If booting with one disk and then the other
one disk it will get a split brain of course.  No real problem on a
victim machine.  But it is faster to keep them in sync.  So I only
boot to the grub menu when testing the grub boot code.  Avoiding
booting the system avoids splitting the raid unnecessarily and speeds
up the debugging.

By testing this way you can verify that you can boot either disk in
isolation after the other disk has failed.  By using a victim machine
you can experiment.  Then if you find a bug you will have a recipe to
recreate it and can file a bug report on it.  Being able to recreate
the problem is the most valuable part.

And here is the challenge.  I think if you do this you will find that
it does actually work.  But feel free to write back here and tell me
that I am wrong and that there is a problem with it. :-) As the great
Mark Twain wrote "There is nothing so annoying as a good example."  If
you can get to a repeatable test case that fails that would be awesome.

> Now I am in the same situation, two servers with mirroring raid, grub on
> /dev/sda only. Identical data on both servers to cope with grub on one disk
> only. Not smart from my side.

Two servers so that you can switch your services from one server to
the other in case one of the servers cannot boot?

If you have two servers and one is the hot spare for the other then
perhaps after doing your own victim machine testing then you can
perform the fix on the spare and test there.  Then apply the fix to
the running server.  I think that should be a safe way to "sneak up"
on the solution.

Bob


signature.asc
Description: Digital signature

gksudo -u user2 /usr/bin/links2 -g

[Marko Randjelovic]

I have a strange problem. The command is not working. If use ordinary sudo or 
epiphany, then it does work. 

gksudo -u user2 /usr/bin/links2 -g # does not work
gksudo -u user2 /usr/bin/epiphany-browser -g # works
sudo -u user2 /usr/bin/links2 -g # works

In terminal, when I run those commands with links, elinks, links2 (with or 
without -g), prompt disappears and as i press keys characters appear in the 
terminal. At first run, Welcome screen shows, but again no keys have no effect. 
After CTRL+C, only gksudo process disappears, and other 2 remain.

Does someone have an idea why could this work like this?

Distribution is Squeeze. In Wheezy it's the same, but CTRL+C kills all 
processes.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131004205919.68ba4...@eunet.rs

Re: Re: Re: VLC freezes system

[Anubhav Yadav]

I am using Nvidia GeForce GT 630 MB 2 gb graphics card, and I have
installed the drivers of the same from
https://wiki.debian.org/NvidiaGraphicsDrivers#Debian_7_.22Wheezy.22

It is optimus enabled so I installed bumblebee for the driver. 

The video is mp4 format. 
-- 
Regards, 
Anubhav Yadav,
Computer Engineering Final Year Student,
Imperial College of Engineering and Research,
Pune.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1380910483.11096.1.camel@Innovator

Re: bind9

[pch0317]

I found in /var/log/daemon.log that not all zone are in view brackets. I 
solve the problem.

Thanks

On 10/03/2013 08:41 PM, Karl E. Jorgensen wrote:

Hi

On Thu, Oct 03, 2013 at 07:28:46PM +0200, Pawe?? Ch. wrote:

Hi list

I install bind9 server on debian (https://wiki.debian.org/Bind9). When I add
named.conf.log entries bind9 can't start. Before adding log entries bind work
correctly.

Without more information, diagnostics is guesswork at best

What error message do you get in /var/log/daemon.log?

Regards



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/524ede82.3050...@gmal.com

Re: Re (2): Multiplicity of accounts.

[Jerry Stuckle]

On 10/4/2013 5:10 AM, Joel Rees wrote:
> Should I add to the confusion?
>
> On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle 
 wrote:

>> On 10/3/2013 8:45 AM, Joel Rees wrote:
>>>
>>> On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle 
>>> wrote:

 On 10/2/2013 12:24 PM, peasth...@shaw.ca wrote:
>
>
> From:   Joel Rees 
> Date:   Wed, 2 Oct 2013 15:30:26 +0900
>>
>>
>> [...]


>> And accessing your bank logged in as the same user that you use to
>> surf random sites is one of the primary causes of leaked bank 
account

>> numbers and passwords.
>
>
>
> The banking information is stored in a cookie.  Subsequently a site
> other
> than the bank is allowed to read the cookie?  A failure of the 
browser.
> Correct?  Prior to studying this thoroughly, I might stick to 
personal

> banking.
>

 Not if your browser is working properly.  Cookies can only be sent 
to the

 domain which originated them (and, depending on the cookie options,
 subdomains of the main domain).
>>>
>>>
>>> subdomains.
>>>
>>> And too many places, bank sites included, outsource parts of their
>>> sites. Particularly ad-related stuff.
>>>
>>
>> It doesn't matter if they outsource parts of their sites.  Those 
outsourced
>> sites will have different domains, and the cookies cannot be sent to 
them.

>
> You must be looking at the page source code of different banks than I am.
>

What banks do you know outsource subdomains to someone else?

>> And no bank would be stupid enough to create a subdomain and hand it 
over to

>> some unknown entity.  They wouldn't be in business for long if they did.
>
> Banks should be smart enough to not use flash on any part of any page
> where they have people logging in. Maybe there are some that are, but
> there sure are many that aren't.
>

So what?  If they wrote the flash code, they know whether it is safe or not.

Just because it is flash does not in itself say whether the code is safe 
or not.


And once again, even if it flash from an advertiser on another domain, 
it will not be able to harvest your userid/password.


>>> I play it safe and limit logging in to my bank to a user that does
>>> nothing but logging into that bank. Hey, it's my computer, I can add
>>> users all I like.
>>
>> Which doesn't make any difference because that's not where the leaks 
occur.

>
> Huh?
>
> I mean a user on my computer. Dedicated to one bank. Reduces the odds
> that a drive-by from, say, a song lyrics site, will still be sitting
> in my browser when I visit the bank. If a drive-by does get root,
> there's no help for that, but at least I can protect myself from the
> drive-bys that only get local access.
>

Which still makes no difference, because the lyrics site will not be 
able to read information from your banking site.


>>> And I try to avoid logging in to the bank, but the bank sometimes
>>> requires me to log in to do certain things, now.
>>>
>>
>> I would hope they require logging in to do *anything* with your 
accounts.

>
> I was thinking of things that you used to be able to do at the teller
> window in the physical bank, which they now charge service charges
> for, but are free if you do them from an ATM or over the web.
>
> I was assuming that much would be understood, since we are talking
> about protecting passwords and such things. Guess I should have tried
> to make that a little more clear.
>

My bank doesn't charge for doing things at the teller window.  Neither 
does my wife's.  Maybe it's time to change banks.


 But too many people use the same userid/password for multiple 
sites, and

 a
 security problem on one site can expose those userids/passwords.  This
 makes
 it easy for a hacker to access one's banking account.

 I use online banking all the time.  But I have a unique 
userid/password
 combination on each of my accounts.  These are long, non-obvious, 
known

 only
 to me and not stored on any computer.
>>>
>>>
>>> That's important, too. Which means that the problem here is getting
>>> used to manage more than a few userids and passwords, and most people
>>> are intimidated by what it takes to get that experience.
>>>
>>
>> It's not all that hard if you come up with a system.  For instance, 
take a
>> phrase you know very well, i.e "To be, or not to be: that is the 
question".
>> Take the first character of each word (numeric homonyms become 
numbers), to

>> get 2bon2btitq.  If the first word starts with a-m, capitalize the
>> odd-numbered letters; otherwise capitalize the even numbered 
letters.  So

>> you get 2BoN2BtItQ.
>>
>> (You might not want to use a phrase quite that well known, but it is 
only an

>> example).
>>
>> Different phrases for different sites.  Even of someone gets one 
password,

>> they won't be able to guess passwords on other sites.
>> Archive: http://lists.debian.org/524d70c0.7080...@attglobal.net
>
> You have your t

www.mototemat.pl - blogi pasjonatów motoryzacji, podziel się swoją pasją

[Witam]

mototemat.pl ( http://mototemat.pl/ ) to platforma hostingowa przeznaczona do 
zakładania
i prowadzenia blogów o tematyce motoryzacyjnej.
Czy to ciekawy film na youtube, premiera nowego modelu, przepisy ruchu 
drogowego itd.
Teraz i ty możesz zostać komentatorem motoryzacji- założenie bloga jest
bardzo proste.
To miejsce gdzie dochodzi do wymiany myśli i debaty na motoryzacyjne
tematy. Miejsce, gdzie można poruszyć każdy motoryzacyjny temat.
Zapraszamy wszystkich.
Zespół mototemat.pl ( http://mototemat.pl/ )

Re: Re (3): Multiplicity of accounts.

[Joel Rees]

On Fri, Oct 4, 2013 at 12:47 AM,   wrote:
> From:   Jerry Stuckle 
> Date:   Thu, 03 Oct 2013 09:27:28 -0400
>> ... [local user compromise(?) is] not where the leaks occur.
>
> If someone can review the greatest hazards or give a link to
> a document, that would help many of us.

I posted this in another branch of this thread, but since it contains
some of the information you ask for, I'll post it here, too. It's a
starting point.

http://en.wikipedia.org/wiki/Linux_malware

But basically, once you understand that a web browser is running
someone else's code on your machine, under the user id that the
browser is running under, which is the user id that you logged into
your machine with, well, imagination is the limit. There is no
greatest hazard to protect yourself from and then feel comfortable.

I'm trying to work up a set of blogs that explain some best practices,
but there aren't really any best practices that are effective right
now.

Well, refraining from surfing the web logged in to the user that you
do your bank business with is probably good enough for many people,
but you have to consider what packages you have loaded, what kinds,
how many, who packages them for you.

I would not do bank business using a computer running Wine. It's not
that I remember specific vulnerabilities in Wine, but Wine is
providing libraries that allow MSWindows binaries to run. That means
that some MSWindows Malware will run if you click the link in the
e-mail. Running as a non-root user may help limit the damage to the
local user, but there may be an escalation path.

One thing I'm thinking about is buying an ARM chromebook, wiping
Chrome, and installing Debian, and keeping that as the dedicated bank
browser machine. You probably don't have to go that far at this point
in time, but you need to keep a log of what hits your router and what
gets through (both sides) to have an idea of how safe your local LAN
is.

>> [Managing userids and passwords] not all that hard if you come up with a 
>> system.
>
> Clever idea.  My system wasn't so simple and effective.

Once you understand the idea of making things memorable to yourself,
and learn to think about the memes floating around and how passwords
should avoid them, there are quite a few tricks.

I personally just leetspeak nonsense or semi-nonsense phrases. I used
to use something like "wiredvibes", leetspoke, for an admin account
because wired reminded me of the network. (That password was retired
many years ago.)

The initial letters of a line or lyric you know, as Jerry suggested,
is another one, but I'd use the second letters at least in some cases,
and I'd avoid the more well known lines from well-known literature. To
be or not to be is probably now in the cracking dictionaries in
several forms, including leetspeak. And well-known quotes from Star
Trek or The Matrix will also likely end up in such dictionaries at
some point or other.

If you are likely to have an attack directed specifically at you,
avoid personal information. Don't use, for instance, the name of your
dog in combination with a family member's name. (For several reasons.)
And you should probably also avoid swear words or the names of deity,
especially words that you tend to use regularly. Memes, you see.

> Thanks,   ... Peter E.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caar43imaa63bdcl+drehytkpqbvtvkdktnopusvhntza3m3...@mail.gmail.com

Re: Building computer

[Paul Cartwright]

On 10/03/2013 05:11 PM, Stan Hoeppner wrote:
> No apology necessary.  I'm on many open lists (LKML) where hitting
> reply-to-list only goes to the sender.  So I've been guilty myself a few
> times.
>  
so that is list specific... I wondered, because sometimes I hit reply &
it goes to the person, other times it goes to the list.. Thunderbird..

-- 
Paul Cartwright
Registered Linux User #367800 and new counter #561587


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524e8e0c.2050...@gmail.com

Re: Re (3): Multiplicity of accounts.

[Joel Rees]

I'm feeling talkative today:

On Fri, Oct 4, 2013 at 4:20 AM, John Hasler  wrote:
> Jerry Stuckle writes:
>> Plus, this being a Debian list, there are few Linux virii and trojans
>> out there.
>
> Can you name any?

http://en.wikipedia.org/wiki/Linux_malware

which came up when I did a Google search on "linux malware".

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAr43iMZG4hSbxrXpvDrGGh=ymnvg0dnjpfgvky6on8be2t...@mail.gmail.com

Debian-LAN: installing a complete network environment

[Andreas B. Mundt]

Hi all,

I would like to point your attention to the Debian-LAN project [1].

Debian-LAN is an approach to simplify installing a complete kerberized
network environment made of Debian machines.  It might be used for
schools, small enterprises, associations, (university) work groups or
to install complex test environments.

Debian-LAN provides a way to install a server and various workstation
profiles [2] by providing a FAI [3] config space for the setup.

The system has been presented on DebConf13, slides and recordings are
available [4].  The code is in wheezy-backports [5] or on alioth [6].

If you run systems as described above, give Debian-LAN a try!
Comments and contributions are of course welcome.

Best regards,

 Andi


[1] https://wiki.debian.org/DebianLAN>
[2] https://wiki.debian.org/DebianLAN/Setup_A#Machine_Types>
[3] http://fai-project.org/>
[4] http://penta.debconf.org/dc13_schedule/events/962.en.html>
[5] http://packages.debian.org/source/stable-backports/debian-lan-config>
The system's target is always the latest stable Debian release.
[6] http://anonscm.debian.org/gitweb/?p=collab-maint/debian-lan.git>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131004091807.GA4374@flashgordon

Re: Re (2): Multiplicity of accounts.

[Joel Rees]

Should I add to the confusion?

On Thu, Oct 3, 2013 at 10:27 PM, Jerry Stuckle  wrote:
> On 10/3/2013 8:45 AM, Joel Rees wrote:
>>
>> On Thu, Oct 3, 2013 at 1:53 AM, Jerry Stuckle 
>> wrote:
>>>
>>> On 10/2/2013 12:24 PM, peasth...@shaw.ca wrote:


 From:   Joel Rees 
 Date:   Wed, 2 Oct 2013 15:30:26 +0900
>
>
> [...]
>>>
>>>
> And accessing your bank logged in as the same user that you use to
> surf random sites is one of the primary causes of leaked bank account
> numbers and passwords.



 The banking information is stored in a cookie.  Subsequently a site
 other
 than the bank is allowed to read the cookie?  A failure of the browser.
 Correct?  Prior to studying this thoroughly, I might stick to personal
 banking.

>>>
>>> Not if your browser is working properly.  Cookies can only be sent to the
>>> domain which originated them (and, depending on the cookie options,
>>> subdomains of the main domain).
>>
>>
>> subdomains.
>>
>> And too many places, bank sites included, outsource parts of their
>> sites. Particularly ad-related stuff.
>>
>
> It doesn't matter if they outsource parts of their sites.  Those outsourced
> sites will have different domains, and the cookies cannot be sent to them.

You must be looking at the page source code of different banks than I am.

> And no bank would be stupid enough to create a subdomain and hand it over to
> some unknown entity.  They wouldn't be in business for long if they did.

Banks should be smart enough to not use flash on any part of any page
where they have people logging in. Maybe there are some that are, but
there sure are many that aren't.

>> I play it safe and limit logging in to my bank to a user that does
>> nothing but logging into that bank. Hey, it's my computer, I can add
>> users all I like.
>
> Which doesn't make any difference because that's not where the leaks occur.

Huh?

I mean a user on my computer. Dedicated to one bank. Reduces the odds
that a drive-by from, say, a song lyrics site, will still be sitting
in my browser when I visit the bank. If a drive-by does get root,
there's no help for that, but at least I can protect myself from the
drive-bys that only get local access.

>> And I try to avoid logging in to the bank, but the bank sometimes
>> requires me to log in to do certain things, now.
>>
>
> I would hope they require logging in to do *anything* with your accounts.

I was thinking of things that you used to be able to do at the teller
window in the physical bank, which they now charge service charges
for, but are free if you do them from an ATM or over the web.

I was assuming that much would be understood, since we are talking
about protecting passwords and such things. Guess I should have tried
to make that a little more clear.

>>> But too many people use the same userid/password for multiple sites, and
>>> a
>>> security problem on one site can expose those userids/passwords.  This
>>> makes
>>> it easy for a hacker to access one's banking account.
>>>
>>> I use online banking all the time.  But I have a unique userid/password
>>> combination on each of my accounts.  These are long, non-obvious, known
>>> only
>>> to me and not stored on any computer.
>>
>>
>> That's important, too. Which means that the problem here is getting
>> used to manage more than a few userids and passwords, and most people
>> are intimidated by what it takes to get that experience.
>>
>
> It's not all that hard if you come up with a system.  For instance, take a
> phrase you know very well, i.e "To be, or not to be: that is the question".
> Take the first character of each word (numeric homonyms become numbers), to
> get 2bon2btitq.  If the first word starts with a-m, capitalize the
> odd-numbered letters; otherwise capitalize the even numbered letters.  So
> you get 2BoN2BtItQ.
>
> (You might not want to use a phrase quite that well known, but it is only an
> example).
>
> Different phrases for different sites.  Even of someone gets one password,
> they won't be able to guess passwords on other sites.
> Archive: http://lists.debian.org/524d70c0.7080...@attglobal.net

You have your techniques and I have mine and we can handle more than
one password, so why shouldn't we be able to handle more than one user
id?

But this thread was originally talking about why sharing a file on a
computer between multiple users take so much thought and effort and
using less familiar tools, like chown and chgrp and groupadd and
useradd.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caar43iownbf0yij4jv3wkrg4wmmn4butfq3wk7u5fqi1_cd...@mail.gmail.com

Re: Debian installer and raid0

[Francesco Pietra]

>
> recall that it has been added with Wheezy.  But let me put forward
> that it doesn't really matter.  If you have RAID then you know you
> want grub on both disks.  After installing simply run the grub install
> script against both disks manually and then you will be assured that
> it has been installed on both disks.
>

I had problems with that methodology and was unable to detect my error.
>From a thread on debian dated Mar 2, 2013:

> I carried out a reinstall of amd64 wheezy
> on the machine with new HD. md0 (boot, ext20, md1 (LVM, home, usr,
> etc). GRUB came installed on /dev/sda only
>
> Then the command
>
> grub-install /dev/sdb
>  was reported by complete installation. No error, no warning.
>
> On rebooting, GRUB was no more found. Then entering in
>
> grub rescue >
>
> prefix/root/ were now wrong.
>
>
Now I am in the same situation, two servers with mirroring raid, grub on
/dev/sda only. Identical data on both servers to cope with grub on one disk
only. Not smart from my side.



> I agree with the other responder.  It is unlikely IMNHO that you want
> RAID0 (striping) for the system disk.  You most likely want RAID1
> (mirroring) instead.  The answer above is the same regardless.  If you
> are thinking striping for performance instead I recommend using an SSD
> for the system disk.


Ah! my mistake. Sure, raid1 (mirroring)

thanks
francesco


On Fri, Oct 4, 2013 at 12:22 AM, Bob Proulx  wrote:

> Francesco Pietra wrote:
> > Did you use a recent version of the installer? What I would like to know
> -
> > before reinstalling everything on my servers - is whether the option to
> set
> > grub on both disks of raid 0 has now been introduced.
>
> I recall that it has been added with Wheezy.  But let me put forward
> that it doesn't really matter.  If you have RAID then you know you
> want grub on both disks.  After installing simply run the grub install
> script against both disks manually and then you will be assured that
> it has been installed on both disks.
>
> I agree with the other responder.  It is unlikely IMNHO that you want
> RAID0 (striping) for the system disk.  You most likely want RAID1
> (mirroring) instead.  The answer above is the same regardless.  If you
> are thinking striping for performance instead I recommend using an SSD
> for the system disk.
>
> Bob
>