headers
Stephen Young | 1 Apr 2011 01:31
Picon

Re: Lenny -> Squeeze : Apache2:LDAP SSL auth not working anymore

I'm having the example same problem after my upgrade from Lenny to Squeeze

With SSL on this just gives me "Internal Server Error" without writing to the logs:
<Location /usvn-1.0/svn/≥
        ErrorDocument 404 default
        DAV svn
        SVNParentPath /var/www/usvn-1.0/files/svn
        SVNListParentPath off
        AuthType Basic
        AuthName "USVN"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative off
        AuthLDAPURL ldaps://myserver.mydomain.com:989/cn=users,dc=myserver,dc=mydomain,dc=com?uid
        AuthzSVNAccessFile /var/www/usvn-1.0/files/authz
        Require valid-user
</Location>

If I turn SSL off on the LDAP server the following works fine:
<Location /usvn-1.0/svn/≥
        ErrorDocument 404 default
        DAV svn
        SVNParentPath /var/www/usvn-1.0/files/svn
        SVNListParentPath off
        AuthType Basic
        AuthName "USVN"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative off
        AuthLDAPURL ldap://myserver.mydomain.com:389/cn=users,dc=myserver,dc=mydomain,dc=com?uid
        AuthzSVNAccessFile /var/www/usvn-1.0/files/authz
        Require valid-user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Powell | 1 Apr 2011 01:51
Favicon

Re: Serial Connection -- shielding

On Thu, 31 Mar 2011 09:14:07 -0400 (EDT), MAROUNI Abbass wrote:
> In a production environment, this what will happen :
> 
> Two servers connected with a single serial cable ( Which I need to 
> figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2.
> getty is always listening to the ttyS0 port on both servers (assured by 
> inittab respawn).
> 
> Server1 is inaccessible. login to server2 launch a script that will kill 
> getty and comment its entry from inittab then launch minicom toward 
> ttyS0 on server1 login to server1 and find what happened. Finally on 
> server2 quit minicom launch another small script that would put getty on 
> ttyS0 and uncomment its entry from inittab. This way if something wrong 
> happens to server2 I am sure that I have a getty on its ttyS0 and all I 
> need to do is to go to server1 follow the same procedure.
> Reverse communication assured :)
> 
> Logical isn't? :)
> 
> I am still not convinced that the serial cable might have different ends 
> if it's a standard null modem cable, so I don't think that reversing the 
> ends between the two servers might help.

OK, now I think I understand.  I have some more thoughts, but before I
share them I want to address your attitude.

Suppose you were a medical doctor.  Suppose I came to you with a problem.
For the sake of example, let's say that I am complaining of a sore throat.
You use a tongue depressor and a flashlight and look at the back of my
throat.  It's deep red and very swollen.  You take my temperature.  I have
(Continue reading)

Permalink | Reply | 3 comments |
headers
PMA | 1 Apr 2011 01:45
Picon
Favicon

New Printer

Hi List.

How soon may there be a Debian driver for
the recently released Epson Stylus R3000?

Thanks,
Pete
Permalink | Reply | 2 comments |
headers
Stephen Powell | 1 Apr 2011 02:06
Favicon

[SOLVED] dreaded ethernet device renaming

On Thu, 31 Mar 2011 10:34:32 -0400 (EDT), briand <at> aracnet.com wrote:
> 
> Thanks to everyone who responded !
> 
> That explains everything.  I changed motherboards out from under the
> system.  So it appended the new eth to the old ones.
> 
> It seems to me that this is a really ugly user trap, even if it's a
> trap you get into replacing the old motherboard.

Yes, if the motherboard contains a built-in network interface, as
many of them do, then replacing the motherboard has the same effect
on network interface name assignments as if you had replaced a NIC card.
The built-in network interface has a different MAC address than the old
one, and that's how udev assigns interface names: by MAC address.  You
can get rid of your home-made udev rule.  This can also occur if you
(1) move the hard drive from one machine to another, (2) backup from
one computer and restore to another, etc.  It seems that everyone
gets burned by this at least once.  But once you find the solution,
you never forget it.

--

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-
Permalink | Reply | 1 comment |
headers
Ron Johnson | 1 Apr 2011 02:28
Picon
Gravatar

Re: New Printer

On 03/31/2011 06:45 PM, PMA wrote:
> Hi List.
>
> How soon may there be a Debian driver for
> the recently released Epson Stylus R3000?
>

Some time after there's a CUPS ppd?

--

-- 
"Neither the wisest constitution nor the wisest laws will secure
the liberty and happiness of a people whose manners are universally
corrupt."
Samuel Adams, essay in The Public Advertiser, 1749
Permalink | Reply | 0 comments |
headers
Chen Wei | 1 Apr 2011 02:44
Picon
Favicon

about mutt-patch sidebar indent level

Dear list:
In mutt-patch's sidebar(debian squeeze), some folders are
indented, they look like:

  comp.lang.python
Debian-User
Inbox
Spam

those folders are at same level, there are no sub folders, I notice
all indented folder have "." in their name, if I add "." to those
un-indented folder, they will be indented as well. For every "."
in folder name, the folder is indented one character to the right.

how to make those folder indent to same level?

--

-- 
Chen Wei
Permalink | Reply | 2 comments |
headers
ZephyrQ | 1 Apr 2011 03:52
Picon
Favicon

Re: Another mouse issue+Xorg after upgrade

On 03/31/2011 01:45 AM, Andrei Popescu wrote:
> On Mi, 30 mar 11, 22:09:15, ZephyrQ wrote:
>>
>> Is it that the boot-up is not reading it?
>  
> Please boot, count to ten, replug your mouse and then post the full 
> output of 'dmesg'.
> 
> Did you already replug the mouse? Because I see this:
> 
>> (II) config/udev: Adding input device Logitech Trackball 
>> (/dev/input/event5)
>> (**) Logitech Trackball: Applying InputClass "evdev pointer catchall"
>> (**) Logitech Trackball: always reports core events
>> (**) Logitech Trackball: Device: "/dev/input/event5"
>> (II) Logitech Trackball: Found 3 mouse buttons
>> (II) Logitech Trackball: Found scroll wheel(s)
>> (II) Logitech Trackball: Found relative axes
>> (II) Logitech Trackball: Found x and y relative axes
>> (II) Logitech Trackball: Configuring as mouse
>> (**) Logitech Trackball: YAxisMapping: buttons 4 and 5
>> (**) Logitech Trackball: EmulateWheelButton: 4, EmulateWheelInertia: 10,
>> EmulateWheelTimeout: 200
>> (II) XINPUT: Adding extended input device "Logitech Trackball" (type: MOUSE)
>> (II) Logitech Trackball: initialized for relative axes.
> 
> Is your "mouse" a Trackball? Later:

Yes, it is.  The same I've used through 3 stable releases. (not the same
physical trackball, but I've used the same brand/type for years...)
(Continue reading)

Permalink | Reply | 2 comments |
headers
briand | 1 Apr 2011 04:39

Re: Re (2): dreaded ethernet device renaming

On Thu, 31 Mar 2011 09:32:18 -0800
peasthope <at> shaw.ca wrote:

> From:	briand <at> aracnet.com
> Date:	Thu, 31 Mar 2011 07:34:32 -0700
> > It seems to me that this is a really ugly user trap, even if it's a
> > trap you get into replacing the old motherboard.
> 
> In the Linux world, udev is really a beautiful way of handling 
> contemporary peripheral devices.  eth0, eth1 ... worked for the 
> ISA bus.  Now devices are hot-swappable.  A more general naming 
> mechanism is needed. 
> http://en.wikipedia.org/wiki/Hot_swapping
> 
> > It was already eth0, what possible reason could it have to go
> > rename it.
> 
> You added a NIC which udev hadn't identified previously? 
> udev decided to call it eth0?  Something similar?
> 

no the problem was that it appended a new device at the end of the old
file.  the old file applied to the previous motherboard (I kept the
same disk).  so then when I brought up the new motherboard it
apparently kept the old devices and tacked the new eth onto the end, so
eth0 ended up being renamed eth3.

I see why though.  a device might come and go and you want it to keep
the same name.  so udev can't assume the devices are "gone", they might
just be "resting".  beatiful plumage, the norwegian blue.
(Continue reading)

Permalink | Reply | 3 comments |
headers
briand | 1 Apr 2011 04:39

Re: [SOLVED] dreaded ethernet device renaming

On Thu, 31 Mar 2011 20:06:51 -0400 (EDT)
Stephen Powell <zlinuxman <at> wowway.com> wrote:

> On Thu, 31 Mar 2011 10:34:32 -0400 (EDT), briand <at> aracnet.com wrote:
> > 
> > Thanks to everyone who responded !
> > 
> > That explains everything.  I changed motherboards out from under the
> > system.  So it appended the new eth to the old ones.
> > 
> > It seems to me that this is a really ugly user trap, even if it's a
> > trap you get into replacing the old motherboard.
> 
> Yes, if the motherboard contains a built-in network interface, as
> many of them do, then replacing the motherboard has the same effect
> on network interface name assignments as if you had replaced a NIC
> card. The built-in network interface has a different MAC address than
> the old one, and that's how udev assigns interface names: by MAC
> address.  You can get rid of your home-made udev rule.  This can also
> occur if you (1) move the hard drive from one machine to another, (2)
> backup from one computer and restore to another, etc.  It seems that
> everyone gets burned by this at least once.  But once you find the
> solution, you never forget it.
> 

lol, that's for sure !

Brian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerome BENOIT | 1 Apr 2011 05:16

Debian was hacked: The Canterbury Distribution

Hello List,

right now, the Official Debian site seems hacked by The Canterbury Distribution.

I guess it is a joke.

hth,
Jerome
Permalink | Reply | 64 comments |

Gmane