Re: Problems with Buster and Bluetooth

2019-10-15 Thread David Parker
It turns out this may have been a hardware issue all along.  When I got the
new PC a few weeks ago, I just plugged the USB Bluetooth adapter into a
port on the front and went from there.  It turns out that I had chosen a
USB 3.1 port, which can cause interference and connection issues with
Bluetooth.  I moved the adapter to a USB 2.0 port and so far it seems to be
working much better.  I'm going to try it like this for a while and see how
it goes.  If the problems come back, I'll keep digging!

On Thu, Oct 10, 2019 at 2:09 AM deloptes  wrote:

> David Parker wrote:
>
> > # dbus-send --print-reply --system --dest=org.bluez
> > /org/bluez/hci0/dev_9B_1F_48_B8_55_F6 org.freedesktop.DBus.Properties.Get
> > string:org.bluez.Device1 string:TxPower
>
> This is a property of the device. I am not sure if it is visible onlywhen
> connected. I am sure I have seen it in dbus, but could be I am wrong or it
> was the network. In any case the property is in the interface
> specification, but I do not know why it is not visible
>
> > Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'TxPower'
> >
> > The strings I have available are:
> >
> > Address
> > AddressType
> > Name
> > Alias
> > Class
> > Icon
> > Paired
> > Trusted
> > Blocked
> > LegacyPairing
> > Connected
> > UUIDs
> > Adapter
> > ServicesResolved
> >
> > Anything else I should check?
>
> What about the PA latency? For example I google for "fine tuning
> pulseaudio"
> https://forums.linuxmint.com/viewtopic.php?t=44862
> https://wiki.archlinux.org/index.php/PulseAudio
>
> someone also susggest to try without PA
>
> http://shellscreen.blogspot.com/2015/01/tips-to-fix-sound-server-issues-on.html
>
> regards
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-10-09 Thread David Parker
Hello,

That's a good question.  "Audio" is not listed even when the earbuds are
connected and working.  I have no explanation for that.

It looks like TxPower is not an available string in the dbus-send output:

# dbus-send --print-reply --system --dest=org.bluez
/org/bluez/hci0/dev_9B_1F_48_B8_55_F6 org.freedesktop.DBus.Properties.Get
string:org.bluez.Device1 string:TxPower
Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'TxPower'

The strings I have available are:

Address
AddressType
Name
Alias
Class
Icon
Paired
Trusted
Blocked
LegacyPairing
Connected
UUIDs
Adapter
ServicesResolved

Anything else I should check?

Thanks!

On Mon, Oct 7, 2019 at 6:07 PM deloptes  wrote:

> David Parker wrote:
>
> > # hciconfig -a
> > hci0: Type: Primary  Bus: USB
> > BD Address: 5C:F3:70:8C:B7:98  ACL MTU: 1021:8  SCO MTU: 64:1
> > UP RUNNING PSCAN
> > RX bytes:62062 acl:40 sco:0 events:3178 errors:0
> > TX bytes:499936 acl:776 sco:0 commands:1088 errors:38
> > Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
> > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> > Link policy: RSWITCH SNIFF
> > Link mode: SLAVE ACCEPT
> > Name: 'debian'
> > Class: 0x100104
> > Service Classes: Object Transfer
> > Device Class: Computer, Desktop workstation
> > HCI Version: 4.0 (0x6)  Revision: 0x153a
> > LMP Version: 4.0 (0x6)  Subversion: 0x220e
> > Manufacturer: Broadcom Corporation (15)
>
> Under Service Classes you have only "Object Transfer"
>
> hci0:   Type: Primary  Bus: USB
> BD Address:   ACL MTU: 310:10  SCO MTU: 64:8
> UP RUNNING PSCAN
> RX bytes:19767535 acl:62926 sco:0 events:3572 errors:0
> TX bytes:390503 acl:2479 sco:0 commands:1081 errors:0
> Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'fujitsu'
> Class: 0x3c0104
> Service Classes: Rendering, Capturing, Object Transfer, Audio
> Device Class: Computer, Desktop workstation
> HCI Version: 2.1 (0x4)  Revision: 0x12e7
> LMP Version: 2.1 (0x4)  Subversion: 0x12e7
> Manufacturer: Cambridge Silicon Radio (10)
>
> Why is Audio not listed?
>
> You can get the TxPower (if lucky) from the device via DBUS Device1
> Interface
>
> dbus-send --print-reply --system --dest=org.bluez
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> org.freedesktop.DBus.Properties.Get string:org.bluez.Device1 string:TxPower
>
> dbus-send --print-reply --system --dest=org.bluez
> /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX
> org.freedesktop.DBus.Properties.GetAll string:org.bluez.Device1
>
> replace dev_XX_XX_XX_XX_XX_XX with your BT MAC
>
>
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-10-04 Thread David Parker
Hello,

I need to correct my previous statements; I was previously running Stretch,
not Jessie.  I hooked up my old hard drive and verified the versions I was
using before:

bluez 5.43-2+deb9u1
pulseaudio-module-bluetooth 10.0-1+deb9u1

Everything worked under those versions, on Debian 9.

I'll give hcidump a try and see if that reveals anything I didn't see with
btmon.  Thanks for the suggestion.  And as requested:

# hciconfig -a
hci0: Type: Primary  Bus: USB
BD Address: 5C:F3:70:8C:B7:98  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:62062 acl:40 sco:0 events:3178 errors:0
TX bytes:499936 acl:776 sco:0 commands:1088 errors:38
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'debian'
Class: 0x100104
Service Classes: Object Transfer
Device Class: Computer, Desktop workstation
HCI Version: 4.0 (0x6)  Revision: 0x153a
LMP Version: 4.0 (0x6)  Subversion: 0x220e
Manufacturer: Broadcom Corporation (15)

# sdptool browse 9B:1F:48:B8:55:F6
Browsing 9B:1F:48:B8:55:F6 ...

(There's no other output from sdptool, it just exits back to the shell).

Thanks,
Dave

On Thu, Oct 3, 2019 at 6:20 PM deloptes  wrote:

> David Parker wrote:
>
> > I'm starting to suspect that this is mostly a bluetooth issue and not
> > really a PA one.  I struggle to get these earbuds connected whether
> > PulseAudio is involved or not.  I can trust them and pair them just fine,
> > but the actual connection generally fails, and when it does work, it
> > doesn't stay connected for long.  I'm not sure how to check the BT power
> > strength, but bluetoothctl reports that the controller is powered:
>
> OK, but in Jessie you had bluez 5.23-2+deb8u1 and in Stretch 5.43-2+deb9u1
> and in buster 5.50-1. Can you confirm which you had in Jessie and which in
> what you use now?
>
> PA is as following
> pulseaudio-module-bluetooth (5.0-13)
> pulseaudio-module-bluetooth (10.0-1+deb9u1)
> pulseaudio-module-bluetooth (12.2-4+deb10u1)
>
> did you use PA in Jessie at all?
>
> I also find it difficult debugging, I usually do both BT and PA but if you
> think it is BT you can try hcidump (sudo hcidump -i hci0). You can also
> monitor dbus
> $ dbus-monitor --system
>
> and for the curiosity paste here output of
> $ hciconfig -a
> $ sdptool browse 
> please
>
>
>
> regards
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-10-03 Thread David Parker
Hi,

I'm starting to suspect that this is mostly a bluetooth issue and not
really a PA one.  I struggle to get these earbuds connected whether
PulseAudio is involved or not.  I can trust them and pair them just fine,
but the actual connection generally fails, and when it does work, it
doesn't stay connected for long.  I'm not sure how to check the BT power
strength, but bluetoothctl reports that the controller is powered:

[bluetooth]# show
Controller 5C:F3:70:8C:B7:98 (public)
Name: debian
Alias: debian
Class: 0x001c0104
*Powered: yes*
Discoverable: no
Pairable: yes
UUID: Headset AG(1112--1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
UUID: A/V Remote Control(110e--1000-8000-00805f9b34fb)
UUID: OBEX File Transfer(1106--1000-8000-00805f9b34fb)
UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
UUID: OBEX Object Push  (1105--1000-8000-00805f9b34fb)
UUID: PnP Information   (1200--1000-8000-00805f9b34fb)
UUID: IrMC Sync (1104--1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (110c--1000-8000-00805f9b34fb)
UUID: Audio Source  (110a--1000-8000-00805f9b34fb)
UUID: Audio Sink(110b--1000-8000-00805f9b34fb)
UUID: Vendor specific   (5005--1000-8000-0002ee01)
UUID: Message Notification Se.. (1133--1000-8000-00805f9b34fb)
UUID: Phonebook Access Server   (112f--1000-8000-00805f9b34fb)
UUID: Message Access Server (1132--1000-8000-00805f9b34fb)
UUID: Headset   (1108--1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0532
Discovering: no

Likewise, I'm not sure how to check the LE details.

It doesn't seem to matter whether or not I am moving around.  I can set the
earbuds down on my desk, a few feet from the BT adapter on my PC, and the
connection will go haywire and then drop after a random (but brief) period
of time.  But I can pair them with my phone and connect without any
problems, and walk 10-20 feet away with no signal interruption or
disconnections.

I did solve one mystery, though: the left/right channels are actually
reversed in the earbuds.  I tested it on my phone and verified.  I have an
identical pair at home which do not have this issue, so it must just be a
defect in this pair.  So at least that's not related to PA or anything else.

Thanks,
Dave


On Thu, Oct 3, 2019 at 3:33 PM deloptes  wrote:

> David Parker wrote:
>
> > Thanks for the additional information.  Unfortunately, the connection
> > problems have returned and I haven't made any progress in solving them.
> > When I kill the pulseaudio process, it simply restarts itself and I'm
> > unable to stop this behavior, so I therefore can't run it manually with
> > the -vvv to further trace the Bluetooth issue.  I have followed
> everything
> > I found online, including the steps from the PulseAudio page in the
> Debian
> > wiki[1] but nothing seems to work.
> >
>
> you kill the PA server with pulseaudio -k - it shouldn't spawn
> automatically
> You can also add no-spawn option to the config file
>
> > I found instructions yesterday to enable PA debugging by adding "-d" to
> > its startup options and setting a specific log file.  It worked (I got
> > output to the file) but it didn't log anything during my subsequent
> > Bluetooth issues.
>
> You didn't answer my previous questions - is it interrupting while you are
> moving and did you check
> - latency in PA
> - power strength on BT
> - specific LE details
>
>
>
>
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-10-02 Thread David Parker
Non-flushable Packet Boundary Flag
  Link Supervision Timeout Changed Event
  Inquiry TX Power Level
  Extended features
< HCI Command: R.. (0x01|0x001c) plen 3  #672 [hci0] 2019-10-02
11:25:56.688956
Handle: 12
Page: 1
> HCI Event: Command St.. (0x0f) plen 4  #673 [hci0] 2019-10-02
11:25:56.689923
  Read Remote Extended Features (0x01|0x001c) ncmd 1
Status: Success (0x00)
> HCI Event: Read Remo.. (0x23) plen 13  #674 [hci0] 2019-10-02
11:25:56.694963
Status: Success (0x00)
Handle: 12
Page: 1/1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  Secure Simple Pairing (Host Support)
< HCI Command:... (0x01|0x0019) plen 10  #675 [hci0] 2019-10-02
11:25:56.695006
Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x
< ACL Data TX: Han.. flags 0x00 dlen 10  #676 [hci0] 2019-10-02
11:25:56.695011
  L2CAP: Information Request (0x0a) ident 1 len 2
Type: Extended features supported (0x0002)
> HCI Event: Command St.. (0x0f) plen 4  #677 [hci0] 2019-10-02
11:25:56.695956
  Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Remote N.. (0x07) plen 255  #678 [hci0] 2019-10-02
11:25:56.716936
Status: Success (0x00)
Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Name: BT910
@ MGMT Event: De.. (0x000b) plen 25  {0x0002} [hci0] 2019-10-02
11:25:56.716969
BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Flags: 0x
Data length: 12
Name (complete): BT910
Class: 0x240404
  Major class: Audio/Video (headset, speaker, stereo, video, vcr)
  Minor class: Wearable Headset Device
  Rendering (Printing, Speaker)
  Audio (Speaker, Microphone, Headset)
@ MGMT Event: De.. (0x000b) plen 25  {0x0001} [hci0] 2019-10-02
11:25:56.716969
BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Flags: 0x
Data length: 12
Name (complete): BT910
Class: 0x240404
  Major class: Audio/Video (headset, speaker, stereo, video, vcr)
  Minor class: Wearable Headset Device
  Rendering (Printing, Speaker)
  Audio (Speaker, Microphone, Headset)
< ACL Data TX: Han.. flags 0x00 dlen 12  #679 [hci0] 2019-10-02
11:26:00.830607
  L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 64
> HCI Event: Disconnect.. (0x05) plen 4  #680 [hci0] 2019-10-02
11:26:02.824947
Status: Success (0x00)
Handle: 12
Reason: Remote User Terminated Connection (0x13)
@ MGMT Event: Dev.. (0x000c) plen 8  {0x0002} [hci0] 2019-10-02
11:26:02.824985
BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Reason: Connection terminated by remote host (0x03)
@ MGMT Event: Dev.. (0x000c) plen 8  {0x0001} [hci0] 2019-10-02
11:26:02.824985
BR/EDR Address: 9B:1F:48:B8:55:F6 (OUI 9B-1F-48)
Reason: Connection terminated by remote host (0x03)
= bluetoothd: 9B:1F:48:B8:55:F6: error updating...   2019-10-02
11:26:02.825623
< HCI Command: W.. (0x03|0x001a) plen 1  #681 [hci0] 2019-10-02
11:26:02.862646
Scan enable: Page Scan (0x02)
> HCI Event: Command Co.. (0x0e) plen 4  #682 [hci0] 2019-10-02
11:26:02.863930
  Write Scan Enable (0x03|0x001a) ncmd 1
Status: Success (0x00)

On Wed, Oct 2, 2019 at 10:15 AM David Parker  wrote:

> Correction: The "-d" for debugging to a file was for bluetoothd, not PA.
>
> On Wed, Oct 2, 2019 at 10:10 AM David Parker  wrote:
>
>> Thanks for the additional information.  Unfortunately, the connection
>> problems have returned and I haven't made any progress in solving them.
>> When I kill the pulseaudio process, it simply restarts itself and I'm
>> unable to stop this behavior, so I therefore can't run it manually with the
>> -vvv to further trace the Bluetooth issue.  I have followed everything I
>> found online, including the steps from the PulseAudio page in the Debian
>> wiki[1] but nothing seems to work.
>>
>> I found instructions yesterday to enable PA debugging by adding "-d" to
>> its startup options and setting a specific log file.  It worked (I got
>> output to the file) but it didn't log anything during my subsequent
>> Bluetooth issues.
>>
>> Thanks,
>> Dave
>>
>> [1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn)
>>
>> On Thu, Sep 26, 2019 at 3:21 PM deloptes  wrote:
>>
>>> David Parker wrote:
>>>
>>> > This issue seems to not be fixed entirely, after all.  Yesterday, the
>>> > earbuds would pair but not connect when I powered them on.  I had to
>>> > connect them manually each time, us

Re: Problems with Buster and Bluetooth

2019-10-02 Thread David Parker
Correction: The "-d" for debugging to a file was for bluetoothd, not PA.

On Wed, Oct 2, 2019 at 10:10 AM David Parker  wrote:

> Thanks for the additional information.  Unfortunately, the connection
> problems have returned and I haven't made any progress in solving them.
> When I kill the pulseaudio process, it simply restarts itself and I'm
> unable to stop this behavior, so I therefore can't run it manually with the
> -vvv to further trace the Bluetooth issue.  I have followed everything I
> found online, including the steps from the PulseAudio page in the Debian
> wiki[1] but nothing seems to work.
>
> I found instructions yesterday to enable PA debugging by adding "-d" to
> its startup options and setting a specific log file.  It worked (I got
> output to the file) but it didn't log anything during my subsequent
> Bluetooth issues.
>
> Thanks,
> Dave
>
> [1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn)
>
> On Thu, Sep 26, 2019 at 3:21 PM deloptes  wrote:
>
>> David Parker wrote:
>>
>> > This issue seems to not be fixed entirely, after all.  Yesterday, the
>> > earbuds would pair but not connect when I powered them on.  I had to
>> > connect them manually each time, using either bluetoothctl or
>> > blueman-manager.  At one point they disconnected, and subsequent
>> attempts
>> > to reconnect them resulted in a "Device or resource busy" error in
>> syslog.
>> > I had to remove them and go through the pairing and connection process
>> > again to fix it.
>> >
>> > So, there's definitely still a problem here, although they do work most
>> of
>> > the time, which is better than where I started.
>>
>> Hmmm - what priority PA is running at?
>>
>> I don't know really why it is a problem - I think this new combination of
>> BT+PA is not quite ready yet, but was forced to us without alternative. I
>> suffer in a different way by the replacement of bluez4.
>>
>> Anyway - what you also can try is try to fine tune PA - for example there
>> were options regarding latency and so on.
>>
>> Also the signal strength - is it breaking when you are moving?
>>
>> and so on.
>>
>> I do not think you have to remove pairing to solve the problem - could be
>> you restart BT+PA.
>>
>> Also try running pulseaudio with -v or -vv or -vvv to get more information
>> and find out where is exactly your problem.
>>
>> I also read about LE that this is still somehow buggy, but if you say it
>> was
>> working for you before ...
>>
>> regards
>>
>>
>
> --
> Dave Parker '11
> Database & Systems Administrator
> Utica College
> Integrated Information Technology Services
> (315) 792-3229
> Registered Linux User #408177
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-10-02 Thread David Parker
Thanks for the additional information.  Unfortunately, the connection
problems have returned and I haven't made any progress in solving them.
When I kill the pulseaudio process, it simply restarts itself and I'm
unable to stop this behavior, so I therefore can't run it manually with the
-vvv to further trace the Bluetooth issue.  I have followed everything I
found online, including the steps from the PulseAudio page in the Debian
wiki[1] but nothing seems to work.

I found instructions yesterday to enable PA debugging by adding "-d" to its
startup options and setting a specific log file.  It worked (I got output
to the file) but it didn't log anything during my subsequent Bluetooth
issues.

Thanks,
Dave

[1] https://wiki.debian.org/PulseAudio#Disabling_daemon_autospawn)

On Thu, Sep 26, 2019 at 3:21 PM deloptes  wrote:

> David Parker wrote:
>
> > This issue seems to not be fixed entirely, after all.  Yesterday, the
> > earbuds would pair but not connect when I powered them on.  I had to
> > connect them manually each time, using either bluetoothctl or
> > blueman-manager.  At one point they disconnected, and subsequent attempts
> > to reconnect them resulted in a "Device or resource busy" error in
> syslog.
> > I had to remove them and go through the pairing and connection process
> > again to fix it.
> >
> > So, there's definitely still a problem here, although they do work most
> of
> > the time, which is better than where I started.
>
> Hmmm - what priority PA is running at?
>
> I don't know really why it is a problem - I think this new combination of
> BT+PA is not quite ready yet, but was forced to us without alternative. I
> suffer in a different way by the replacement of bluez4.
>
> Anyway - what you also can try is try to fine tune PA - for example there
> were options regarding latency and so on.
>
> Also the signal strength - is it breaking when you are moving?
>
> and so on.
>
> I do not think you have to remove pairing to solve the problem - could be
> you restart BT+PA.
>
> Also try running pulseaudio with -v or -vv or -vvv to get more information
> and find out where is exactly your problem.
>
> I also read about LE that this is still somehow buggy, but if you say it
> was
> working for you before ...
>
> regards
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-09-26 Thread David Parker
This issue seems to not be fixed entirely, after all.  Yesterday, the
earbuds would pair but not connect when I powered them on.  I had to
connect them manually each time, using either bluetoothctl or
blueman-manager.  At one point they disconnected, and subsequent attempts
to reconnect them resulted in a "Device or resource busy" error in syslog.
I had to remove them and go through the pairing and connection process
again to fix it.

So, there's definitely still a problem here, although they do work most of
the time, which is better than where I started.

On Tue, Sep 24, 2019 at 5:52 PM deloptes  wrote:

> Mark Fletcher wrote:
>
> > On Tue, Sep 24, 2019 at 01:21:03PM -0400, David Parker wrote:
> >> Ok, I think I may have solved the connectivity issue.  Some additional
> >> Googling revealed that GDM starts an instance of PulseAudio, and that
> >> conflicts with the PulseAudio server used by the Bluetooth device.  The
> >> steps to stop GDM from starting PulseAudio can be found online, and I've
> >> adapted them for Buster here:
> >>
> >> (as root):
> >> echo "autospawn = no" >> /var/lib/gdm3/.config/pulse/client.conf
> >> echo "daemon-binary = /bin/true" >>
> >> /var/lib/gdm3/.config/pulse/client.conf su - Debian-gdm -c "mkdir -p
> >> /var/lib/gdm3/.config/systemd/user" su - Debian-gdm -c "ln -s /dev/null
> >> /var/lib/gdm/.config/systemd/user/pulseaudio.socket"
> >>
> >
> > Ah -- that old chestnut! I had that problem back in the day (wheezy or
> > stretch, I don't remember which) with a pair of high-end bluetooth
> > headphones.
> >
> > I recently fresh-installed Buster, I've used Bluetooth with a speaker
> > but not with my headphones without problems, but I just checked and I
> > _do_ have 2 instances of pulseaudio running, one as my regular user and
> > one as Debian-. Isn't that a bug in Debian's setup? Is there
> > some reason one would want things that way?
> >
> > Mark
>
> I just check, I do not use gdm - don't have it installed, but I also have
> two processes. I found this and many other entries dedicated to the topic
>
> https://lists.debian.org/debian-user/2015/11/msg01119.html
>
> However I do not have any issues with audio - very strange - also the date
> of the thread.
>
> regards
>
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-09-24 Thread David Parker
Ok, I think I may have solved the connectivity issue.  Some additional
Googling revealed that GDM starts an instance of PulseAudio, and that
conflicts with the PulseAudio server used by the Bluetooth device.  The
steps to stop GDM from starting PulseAudio can be found online, and I've
adapted them for Buster here:

(as root):
echo "autospawn = no" >> /var/lib/gdm3/.config/pulse/client.conf
echo "daemon-binary = /bin/true" >> /var/lib/gdm3/.config/pulse/client.conf
su - Debian-gdm -c "mkdir -p /var/lib/gdm3/.config/systemd/user"
su - Debian-gdm -c "ln -s /dev/null
/var/lib/gdm/.config/systemd/user/pulseaudio.socket"

After a reboot, the issue seems to be fixed.  The earbuds have now been
connected for over 40 minutes.

The channels are still reversed, but at least now they'll stay connected
long enough to troubleshoot that problem.

- Dave

On Tue, Sep 24, 2019 at 12:06 PM David Parker  wrote:

> Oh man, it turns out the original issue is still there, too.  The earbuds
> stayed connected for about 15 minutes, but suddenly the sound got really
> choppy and distorted, and then went silent, and then they disconnected and
> this was in syslog:
>
> Sep 24 12:02:58 debian bluetoothd[627]: Start: Connection timed out (110)
> Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c:
> Transport Acquire() failed for transport
> /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Input/output error)
> Sep 24 12:02:58 debian bluetoothd[627]: avdtp_start failed
> Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c:
> Transport Acquire() failed for transport
> /org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Operation Not Authorized)
> Sep 24 12:03:00 debian bluetoothd[627]: Abort: Connection timed out (110)
> Sep 24 12:03:00 debian gsd-media-keys[1510]: Unable to get default sink
>
> So it looks like I still have Bluetooth and/or pulseaudio issues here.
> This was definitely broken by something that changed between Jessie and
> Buster.  Should I file a bug report, perhaps?
>
> On Tue, Sep 24, 2019 at 11:58 AM David Parker  wrote:
>
>> Thanks for the advice.  I unpaired the earbuds, removed my
>> ~/.config/pulse directory, rebooted, then used bluetoothctl to trust, pair,
>> and connect them again.  It seems to have worked (they have been connected
>> for about 10 minutes and have not disconnected yet), but I am still having
>> a few issues which I did not have under Jessie:
>>
>> 1. The left/right channels are swapped (according to the speaker test in
>> the Gnome sound settings)
>> 2. The sound frequently becomes choppy and/or cuts out for several
>> seconds.  I am sitting about 3 feet from the USB Bluetooth adapter plugged
>> into the PC, and it was always fine before.
>>
>> Any ideas on fixing the channels and sound quality?
>>
>> Thanks!
>>
>> On Fri, Sep 20, 2019 at 5:40 PM deloptes  wrote:
>>
>>> David Parker wrote:
>>>
>>> > But I just got a new PC and installed Buster on
>>> > it, and now I struggle just to get the earbuds paired and connected
>>>
>>> if there are problems with the GUI in Gnome use bluetoothctl for pairing
>>> There are also few options you may try
>>>
>>>
>>>
>>>
>>
>> --
>> Dave Parker '11
>> Database & Systems Administrator
>> Utica College
>> Integrated Information Technology Services
>> (315) 792-3229
>> Registered Linux User #408177
>>
>
>
> --
> Dave Parker '11
> Database & Systems Administrator
> Utica College
> Integrated Information Technology Services
> (315) 792-3229
> Registered Linux User #408177
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-09-24 Thread David Parker
Oh man, it turns out the original issue is still there, too.  The earbuds
stayed connected for about 15 minutes, but suddenly the sound got really
choppy and distorted, and then went silent, and then they disconnected and
this was in syslog:

Sep 24 12:02:58 debian bluetoothd[627]: Start: Connection timed out (110)
Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c:
Transport Acquire() failed for transport
/org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Input/output error)
Sep 24 12:02:58 debian bluetoothd[627]: avdtp_start failed
Sep 24 12:02:58 debian pulseaudio[1408]: E: [bluetooth] bluez5-util.c:
Transport Acquire() failed for transport
/org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd0 (Operation Not Authorized)
Sep 24 12:03:00 debian bluetoothd[627]: Abort: Connection timed out (110)
Sep 24 12:03:00 debian gsd-media-keys[1510]: Unable to get default sink

So it looks like I still have Bluetooth and/or pulseaudio issues here.
This was definitely broken by something that changed between Jessie and
Buster.  Should I file a bug report, perhaps?

On Tue, Sep 24, 2019 at 11:58 AM David Parker  wrote:

> Thanks for the advice.  I unpaired the earbuds, removed my ~/.config/pulse
> directory, rebooted, then used bluetoothctl to trust, pair, and connect
> them again.  It seems to have worked (they have been connected for about 10
> minutes and have not disconnected yet), but I am still having a few issues
> which I did not have under Jessie:
>
> 1. The left/right channels are swapped (according to the speaker test in
> the Gnome sound settings)
> 2. The sound frequently becomes choppy and/or cuts out for several
> seconds.  I am sitting about 3 feet from the USB Bluetooth adapter plugged
> into the PC, and it was always fine before.
>
> Any ideas on fixing the channels and sound quality?
>
> Thanks!
>
> On Fri, Sep 20, 2019 at 5:40 PM deloptes  wrote:
>
>> David Parker wrote:
>>
>> > But I just got a new PC and installed Buster on
>> > it, and now I struggle just to get the earbuds paired and connected
>>
>> if there are problems with the GUI in Gnome use bluetoothctl for pairing
>> There are also few options you may try
>>
>>
>>
>>
>
> --
> Dave Parker '11
> Database & Systems Administrator
> Utica College
> Integrated Information Technology Services
> (315) 792-3229
> Registered Linux User #408177
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Problems with Buster and Bluetooth

2019-09-24 Thread David Parker
Thanks for the advice.  I unpaired the earbuds, removed my ~/.config/pulse
directory, rebooted, then used bluetoothctl to trust, pair, and connect
them again.  It seems to have worked (they have been connected for about 10
minutes and have not disconnected yet), but I am still having a few issues
which I did not have under Jessie:

1. The left/right channels are swapped (according to the speaker test in
the Gnome sound settings)
2. The sound frequently becomes choppy and/or cuts out for several
seconds.  I am sitting about 3 feet from the USB Bluetooth adapter plugged
into the PC, and it was always fine before.

Any ideas on fixing the channels and sound quality?

Thanks!

On Fri, Sep 20, 2019 at 5:40 PM deloptes  wrote:

> David Parker wrote:
>
> > But I just got a new PC and installed Buster on
> > it, and now I struggle just to get the earbuds paired and connected
>
> if there are problems with the GUI in Gnome use bluetoothctl for pairing
> There are also few options you may try
>
>
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Problems with Buster and Bluetooth

2019-09-20 Thread David Parker
Hello,

I have a set of Bluetooth earbuds and a USB Bluetooth adapter (Plugable
USB-BT4LE).  With minimal effort, I had everything working fine under
Jessie for several months.  But I just got a new PC and installed Buster on
it, and now I struggle just to get the earbuds paired and connected, and
when they do connect, it's not long before they randomly disconnect again.
And when they are connected, the left and right channels are reversed (per
the speaker test in Gnome Settings > Sound > Output > Test Speakers).

I have tried just about everything I can find in my Google searches.
Nothing seems to work.  When the earbuds fail to connect after pairing,
syslog shows the following:

Sep 20 15:11:59 debian bluetoothd[654]: connect error: Software caused
connection abort (103)

And when they disconnect after some random interval:

Sep 20 15:23:48 debian bluetoothd[654]: Start: Connection timed out (110)
Sep 20 15:23:48 debian pulseaudio[1381]: E: [pulseaudio] bluez5-util.c:
Transport Acquire() failed for transport
/org/bluez/hci0/dev_9B_1F_48_B8_55_F6/fd1 (Input/output error)
Sep 20 15:23:50 debian bluetoothd[654]: Abort: Connection timed out (110)

What's most frustrating about all of this is that I was able to get them
paired, connected, and used as the default output with very little hassle
under Debian 9.  I'm not sure what's changed in 10, but I've been trying to
get this working for days and I'm out of ideas.

Any help is greatly appreciated.

Thanks,
Dave

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Removing firefox-esr also removes gnome

2018-11-05 Thread David Parker
Thanks for the information.  I guess I'm just surprised that the
dependencies are limited to firefox/firefox-esr/chromium.  Seems like other
browsers like Iceweasel are just arbitrarily left out.

- Dave


On Mon, Nov 5, 2018 at 12:01 PM Greg Wooledge  wrote:

> On Mon, Nov 05, 2018 at 11:55:48AM -0500, David Parker wrote:
> > Does anyone know why Gnome apparently depends on
> > firefox-esr, and how I can just uninstall firefox-esr and leave Gnome
> alone?
>
> apt-cache show gnome-core | grep Depends
>
> It says "... firefox-esr (>= 30) | firefox (>= 30) | chromium ..."
> so you would need to replace firefox-esr with one of those two
> alternatives instead of just flat-out trying to remove it.
>
>

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Removing firefox-esr also removes gnome

2018-11-05 Thread David Parker
Hello,

I'm running Debian 9.5 (amd64) and attempting to uninstall firefox-esr.
However, apt says that gnome and gnome-core are among the packages which
will also be uninstalled.  Does anyone know why Gnome apparently depends on
firefox-esr, and how I can just uninstall firefox-esr and leave Gnome alone?

Thanks!

# apt-get remove firefox-esr
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  empathy empathy-common fonts-stix hyphen-en-us libdiscid0 libjsoncpp1
libreoffice libreoffice-help-en-us libreoffice-report-builder-bin
libtelepathy-farstream3 mythes-en-us sound-juicer telepathy-gabble
  telepathy-salut
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  firefox-esr gnome gnome-core iceweasel libarchive12 libepc-1.0-3
libepc-ui-1.0-3 libgnutls-deb0-28 libgnutls28 libhogweed2 libhogweed2:i386
libnettle4 libnettle4:i386 task-gnome-desktop
0 upgraded, 0 newly installed, 14 to remove and 82 not upgraded.
After this operation, 121 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.



-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Error while upgrading from Wheezy to Stretch

2018-04-19 Thread David Parker
I never thought to use the backports repo in Jessie to keep pacemaker
installed.  That's a great idea, I'll give it a try and see what happens.

Regarding Pacemaker's data and config, as far as I could tell, it was
gone.  I'm not positive what happened with it, but I wonder if the fact
that the pacemaker package was missing entirely from the new release caused
apt to just get rid of it during the upgrade.  I can also re-try that and
keep closer track of what gets removed.  I do know that when I upgraded
from Wheezy to Jessie and then to Stretch, and then I re-installed
Pacemaker in Stretch, it didn't find any old config data and acted like a
new installation.

Thanks!
Dave

On Thu, Apr 19, 2018 at 11:32 AM, Roberto C. Sánchez 
wrote:

> On Thu, Apr 19, 2018 at 11:26:20AM -0400, Greg Wooledge wrote:
> >
> > According to http://packages.debian.org/pacemaker there is also a
> > backport of the stretch version of the package in the jessie-backports
> > repository.  So perhaps there is some way to convince the jessie upgrade
> > to use the jessie-backports version of this package rather than removing
> > it.  But that's beyond my experience.
> >
>
> I totally forgot about backports. Generally, including backports
> repositories of the upgrade target (i.e., the suite being upgraded to)
> is not a good idea. However, this situation would qualify as extenuating
> circumstances. Plus, someone who manages a HA cluster almost certainly
> has the skills to deal with the occasional minor hiccup assocaited with
> mixing backports into an upgrade.
>
> The only thing I would say is use apt "pinning" to prioritize the
> backports repository lower than the other repositories so you don't
> accidentally get backports for *everything* that has a backport
> available.
>
> Regards,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Error while upgrading from Wheezy to Stretch

2018-04-19 Thread David Parker
Hi all,

Sorry I didn't get back to this sooner, had some crazy life stuff getting
in the way.

I should have said in my original post that there is a reason I'm trying to
jump from Wheezy to Stretch.  These boxes are in an HA cluster with
Pacemaker, Corosync, and DRBD.  I have all 3 of these installed from the
Debian packages.  Pacemaker is not in Jessie (apparently the devs missed
the deadline for inclusion), so an upgrade to Jessie uninstalls pacemaker
and all of its configuration.  That's what I was hoping to avoid, because
setting up an configuring Pacemaker always takes me a while to get right,
so an upgrade path which does not include the removal of it is preferable.

I did read the documentation and I did try Wheezy -> Jessie - > Stretch
first, but the problem was that Pacemaker was removed.  Hence, I was hoping
to skip Jessie.

If it's simply not possible to do this upgrade then I guess that's that.
I'll have to reinstall and reconfigure Pacemaker, which hopefully will
continue to be delivered in future releases without fail.

Thanks,
Dave

On Thu, Apr 12, 2018 at 2:35 PM, David Wright <deb...@lionunicorn.co.uk>
wrote:

> On Thu 12 Apr 2018 at 06:42:33 (-0400), Dan Ritter wrote:
> > On Wed, Apr 11, 2018 at 07:57:07PM -0500, David Wright wrote:
> > > On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote:
> > > > I am trying to upgrade two test boxes from Wheezy to Stretch
> (skipping
> > > > Jessie).  The upgrade worked on one of them, although I ran into
> errors and
> > > > had to run "apt-get -f install" a few times, but that resolved the
> issues
> > > > and it ultimately worked.
> > > >
> > > > However, on the second box, I ran into an error about halfway
> through the
> > > > upgrade, and I'm not able to get past it.  No matter what I do, I
> keep
> > > > running into version mismatch issue with libpam-modules.  It's
> preventing
> > > > the upgrade from finishing.
> > >
> > > The other "incantation" that's worth trying is
> > >
> > > # dpkg --configure -a
>
> That's the short answer.
>
> > I would start by reinstating jessie in all of your sources
> > files, then try dpkg --configure -a, then apt-get -f install,
> > then apt-get dist-upgrade to jessie. After a successful jessie
> > reboot, upgrade to stretch.
>
> dpkg --configure -a   and   apt-get -f install   can be useful
> to fix a logjam, but when you get an error like
>  E: Sub-process /usr/bin/dpkg returned an error code (1)
> it's worth running dpkg directly, seeing which packages are stuck,
> and then try   dpkg -i 
> as this can sometimes fix circular and reciprocal dependencies
> that running from apt* is unable to solve.
>
> BTW if they're test boxes, keep on trying: you may learn something
> useful about rescuing systems, which the reinstall people won't.
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Error while upgrading from Wheezy to Stretch

2018-04-11 Thread David Parker
Hello,

I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
Jessie).  The upgrade worked on one of them, although I ran into errors and
had to run "apt-get -f install" a few times, but that resolved the issues
and it ultimately worked.

However, on the second box, I ran into an error about halfway through the
upgrade, and I'm not able to get past it.  No matter what I do, I keep
running into version mismatch issue with libpam-modules.  It's preventing
the upgrade from finishing.

# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer
required:
  libcfg4 libcib1 libclass-isa-perl libconfdb4 libcoroipcc4 libcoroipcs4
libcrmcluster1 libcrmcommon2 libevs4 liblogsys4 libpe-status3 libpengine3
libpload4 libquorum4 libsam4 libstonithd1 libswitch-perl
  libsystemd-login0 libtransitioner1 libvotequorum4
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libpam-modules
The following packages will be upgraded:
  libpam-modules
1 upgraded, 0 newly installed, 0 to remove and 199 not upgraded.
2 not fully installed or removed.
Need to get 0 B/308 kB of archives.
After this operation, 62.5 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Preconfiguring packages ...
dpkg: dependency problems prevent processing triggers for man-db:
 man-db depends on bsdmainutils; however:
  Package bsdmainutils is not configured yet.

dpkg: error processing archive
/var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb (--unpack):
 dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any ideas or suggestions for resolving this will be greatly appreciated.

Thanks!
Dave

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: All of my enoX interfaces are mapped to eth0

2018-04-02 Thread David Parker
I don't normally set IP addresses on interfaces which I know to be offline,
so perhaps my methodology here was flawed.  In this case, I set IP
addresses on eno2, eno3, and eno4 to test whether or not they were actually
discrete interfaces, or if they were all somehow mapped to the one
interface which was actually connected.

Normally, I only set IP addresses on interfaces which are already
connected, but in that case I will stop seeing a ping response from any IP
on an interface which is subsequently disconnected, regardless of whether
or not I have multiple interfaces on the same subnet.

The reason I was trying to figure out whether or not they were actually
mapped to the same physical interface was that I needed to setup a bonded
interface.  A quick unload/reload of the network driver resulted in a
correct mapping (eno1->eth0, eno2->eth1, etc.) and then I was able to set
up the bonded interface in active/passive failover mode just fine.  So it's
all set now.

Thanks!

On Sat, Mar 31, 2018 at 10:11 AM, David Wright <deb...@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 23:16:26 (-0400), David Parker wrote:
> > They are all on the same subnet, yes.  But I haven't ever seen this
> > behavior before.  Normally, when I have an interface which is unplugged,
> > its IP is unreachable.
>
> So we have two machines, one with eth0, eth1, eth2, eth3 and one
> with eno1, eno2, eno3, eno4. The first one has no issues, and the
> second reportedly does.
>
> What differences are there in the symptoms presented by the two
> machines? Are the former's interfaces on the same subnet too?
>
> AIUI, which is not very much, your ping behaviour is not unexpected,
> and running multiple interfaces on the same subnet takes some out
> of the ordinary configuration. (Or are your interfaces eno2-4 just
> treading water until you have something to connect them too?)
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: All of my enoX interfaces are mapped to eth0

2018-03-30 Thread David Parker
They are all on the same subnet, yes.  But I haven't ever seen this
behavior before.  Normally, when I have an interface which is unplugged,
its IP is unreachable.

On Fri, Mar 30, 2018 at 10:30 PM, David Wright <deb...@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 22:01:23 (-0400), David Parker wrote:
> > That's what I thought, too.  As you pointed out, the logs show each eno
> > interface being assigned to a different MAC address.  However, I am able
> to
> > assign IP addresses to any (or all) of those interfaces and then ping
> them
> > from a different machine, even though the first interface is the only one
> > which is physically connected to the network.  The other three interfaces
> > are unplugged.  So that leads me to believe that all 4 eno interfaces are
> > actually mapping to the first physical interface (a.k.a. eth0).
>
> Do you have the IP addresses for the different interfaces on the same
> subnet?
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: All of my enoX interfaces are mapped to eth0

2018-03-30 Thread David Parker
That's what I thought, too.  As you pointed out, the logs show each eno
interface being assigned to a different MAC address.  However, I am able to
assign IP addresses to any (or all) of those interfaces and then ping them
from a different machine, even though the first interface is the only one
which is physically connected to the network.  The other three interfaces
are unplugged.  So that leads me to believe that all 4 eno interfaces are
actually mapping to the first physical interface (a.k.a. eth0).

That's why I'm really confused.

Thanks!

On Fri, Mar 30, 2018 at 7:50 PM, David Wright <deb...@lionunicorn.co.uk>
wrote:

> On Fri 30 Mar 2018 at 16:19:30 (-0400), David Parker wrote:
> > Hello,
> >
> > I have two identical HP servers running Debian 9.  One of them is a clean
> > install of 9, whereas the other was upgraded from Debian 8.
> >
> > The one that was upgraded has no networking issues (indeed, it still uses
> > the ethX interface names).  However, the one that was installed from
> > scratch is having an issue which I can't seem to figure out.  There are 4
> > network interfaces -- eno[1-4] -- but they are all getting mapped to
> eth0.
> > It looks like they were mapped correctly until I reloaded the network
> > driver a few days ago.  Any idea how I can get them back into a 1:1
> mapping
> > with the actual physical interfaces, instead of all pointing to the same
> > one?
> >
> > Some dmesg output for reference:
> >
> > [Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014)
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e0
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e1
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: dma_rwctrl[0001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e2
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: dma_rwctrl[0001]
> > dma_mask[64-bit]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e3
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: dma_rwctrl[0001]
> > dma_mask[64-bit]
> >
> >
> >
> > *[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eno2: renamed from eth1[Wed
> > Mar 28 17:00:45 2018] tg3 :03:00.0 eno1: renamed from eth0[Wed Mar 28
> > 17:00:45 2018] tg3 :03:00.3 eno4: renamed from eth3[Wed Mar 28
> 17:00:45
> > 2018] tg3 :03:00.2 eno3: renamed from eth2*
> >
> > Looks fine, but then...
> >
> > [Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014)
> > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
> d8:9d:67:2c:ec:e0
> > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: attached PHY is 5719C
> > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
> > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: RXcsums[1]
> LinkChgREG[0]
> > MIirq[0] ASF[1] TSOcap[1]
> > [Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001]
> > dma_mask[64-bit]
> > *[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eno1: renamed from eth0*
> > [Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: Tigon3
> > [partno(629133-001) rev 5719001] (PCI Express) MAC address
&

All of my enoX interfaces are mapped to eth0

2018-03-30 Thread David Parker
Hello,

I have two identical HP servers running Debian 9.  One of them is a clean
install of 9, whereas the other was upgraded from Debian 8.

The one that was upgraded has no networking issues (indeed, it still uses
the ethX interface names).  However, the one that was installed from
scratch is having an issue which I can't seem to figure out.  There are 4
network interfaces -- eno[1-4] -- but they are all getting mapped to eth0.
It looks like they were mapped correctly until I reloaded the network
driver a few days ago.  Any idea how I can get them back into a 1:1 mapping
with the actual physical interfaces, instead of all pointing to the same
one?

Some dmesg output for reference:

[Wed Mar 28 17:00:45 2018] tg3.c:v3.137 (May 11, 2014)
[Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
[Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eth1: dma_rwctrl[0001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
[Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.2 eth2: dma_rwctrl[0001]
dma_mask[64-bit]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
[Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:00:45 2018] tg3 :03:00.3 eth3: dma_rwctrl[0001]
dma_mask[64-bit]



*[Wed Mar 28 17:00:45 2018] tg3 :03:00.1 eno2: renamed from eth1[Wed
Mar 28 17:00:45 2018] tg3 :03:00.0 eno1: renamed from eth0[Wed Mar 28
17:00:45 2018] tg3 :03:00.3 eno4: renamed from eth3[Wed Mar 28 17:00:45
2018] tg3 :03:00.2 eno3: renamed from eth2*

Looks fine, but then...

[Wed Mar 28 17:12:33 2018] tg3.c:v3.137 (May 11, 2014)
[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e0
[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eth0: dma_rwctrl[0001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 :03:00.0 eno1: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e1
[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eth0: dma_rwctrl[0001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 :03:00.1 eno2: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e2
[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eth0: dma_rwctrl[0001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 :03:00.2 eno3: renamed from eth0*
[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: Tigon3
[partno(629133-001) rev 5719001] (PCI Express) MAC address d8:9d:67:2c:ec:e3
[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: attached PHY is 5719C
(10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[1] TSOcap[1]
[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eth0: dma_rwctrl[0001]
dma_mask[64-bit]
*[Wed Mar 28 17:12:33 2018] tg3 :03:00.3 eno4: renamed from eth0*

I should note that this server is now 

Re: Open socket not connected to any real process

2018-03-07 Thread David Parker
Well, crap.  It turns out this isn't a problem.  PAM is configured for LDAP
authentication and so it opens a connection each time I log in, owned by my
sshd process, even though it's not using LDAP authentication for root.  And
the other LDAP queries I'm seeing are being sent when users authenticate
via sendmail.  Case closed!

On Wed, Mar 7, 2018 at 4:16 PM, David Parker <dpar...@utica.edu> wrote:

> Hello,
>
> I have an SMTP server running Debian Wheezy (64-bit).  A few weeks ago, I
> stopped nscd on it, because it was holding a connection open to our LDAP
> server and sending a ton of unnecessary queries to it.
>
> Even though nscd is not running, I am once again seeing nscd-type queries
> on the LDAP server from this SMTP server, and a connection is open from the
> SMTP server.  But I can't seem to figure out what process is using that
> connection.  Every time I check using netstat or lsof, it just reports that
> the socket is owned by my current sshd process.
>
> An example:
>
> root@smtp:~# netstat -anp | grep 389
> tcp0  0 :58786   :389ESTABLISHED
> *10249/0*
>
> root@smtp:~# lsof -n -i :389
> COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
> sshd*10249 root*4w  IPv4 86936230  0t0  TCP
> :58786->:ldap (ESTABLISHED)
>
> root@smtp:~# ps -ef | grep 10249
> *root 10249 17111  0 15:49 ?00:00:00 sshd: root@pts/0*
> root 10251 10249  0 15:50 pts/000:00:00 -bash
> root 10286 10251  0 15:54 pts/000:00:00 grep 10249
>
> So I log out and back in, and the PID for this socket changes to my new
> sshd process:
>
> root@smtp:~# netstat -anp | grep 389
> tcp0  0 :58798   :389ESTABLISHED
> *10288/0*
>
> root@smtp:~# lsof -n -i :389
> COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
> sshd*10288 root*4w  IPv4 86936319  0t0  TCP
> :58798->:ldap (ESTABLISHED)
>
> root@smtp:~# ps -ef | grep 10288
> *root 10288 17111  0 15:54 ?00:00:00 sshd: root@pts/0*
> root 10290 10288  0 15:54 pts/000:00:00 -bash
> root 10304 10290  0 15:55 pts/000:00:00 grep 10288
>
> And all the while, LDAP queries continue to be sent over this connection.
> Does anyone have any idea why I can't seem to track down the real process
> which is holding this socket open?
>
> Thanks!
> Dave
>
> --
> Dave Parker '11
> Database & Systems Administrator
> Utica College
> Integrated Information Technology Services
> (315) 792-3229
> Registered Linux User #408177
>



-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Open socket not connected to any real process

2018-03-07 Thread David Parker
Hello,

I have an SMTP server running Debian Wheezy (64-bit).  A few weeks ago, I
stopped nscd on it, because it was holding a connection open to our LDAP
server and sending a ton of unnecessary queries to it.

Even though nscd is not running, I am once again seeing nscd-type queries
on the LDAP server from this SMTP server, and a connection is open from the
SMTP server.  But I can't seem to figure out what process is using that
connection.  Every time I check using netstat or lsof, it just reports that
the socket is owned by my current sshd process.

An example:

root@smtp:~# netstat -anp | grep 389
tcp0  0 :58786   :389ESTABLISHED *10249/0*

root@smtp:~# lsof -n -i :389
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd*10249 root*4w  IPv4 86936230  0t0  TCP
:58786->:ldap (ESTABLISHED)

root@smtp:~# ps -ef | grep 10249
*root 10249 17111  0 15:49 ?00:00:00 sshd: root@pts/0*
root 10251 10249  0 15:50 pts/000:00:00 -bash
root 10286 10251  0 15:54 pts/000:00:00 grep 10249

So I log out and back in, and the PID for this socket changes to my new
sshd process:

root@smtp:~# netstat -anp | grep 389
tcp0  0 :58798   :389ESTABLISHED *10288/0*

root@smtp:~# lsof -n -i :389
COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd*10288 root*4w  IPv4 86936319  0t0  TCP
:58798->:ldap (ESTABLISHED)

root@smtp:~# ps -ef | grep 10288
*root 10288 17111  0 15:54 ?00:00:00 sshd: root@pts/0*
root 10290 10288  0 15:54 pts/000:00:00 -bash
root 10304 10290  0 15:55 pts/000:00:00 grep 10288

And all the while, LDAP queries continue to be sent over this connection.
Does anyone have any idea why I can't seem to track down the real process
which is holding this socket open?

Thanks!
Dave

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Grow an ext4 filesystem

2017-06-09 Thread David Parker
Indeed it has!  I upgraded to Jessie and all is well  Thank you!

# e2fsck -f /dev/sdb1
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb1: 45983/183140352 files (1.0% non-contiguous), 668815777/732530432
blocks

# resize2fs /dev/sdb1
resize2fs 1.42.12 (29-Aug-2014)
Resizing the filesystem on /dev/sdb1 to 1220884224 (4k) blocks.
The filesystem on /dev/sdb1 is now 1220884224 (4k) blocks long.

And now...

root@tapesrv:~# df -h /dev/sdb1
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1   4.5T  2.5T  1.9T  58% /export

Thanks again!

On Fri, Jun 9, 2017 at 10:34 AM, Sven Joachim <svenj...@gmx.de> wrote:

> On 2017-06-09 10:15 -0400, David Parker wrote:
>
> > I have a storage server running Debian 7.6 x64.  It's an HP server with
> 24
> > HDDs and a hardware RAID controller.  It has a 2.9 TB ext4 filesystem
> which
> > resides on a RAID 5 volume, and I recently needed to grow this filesystem
> > so I added more disks to the volume and then used parted to grow the
> > partition to the new size of 5 TB, so the space is now available in that
> > partition:
> >
> > # parted print /dev/sdb
> > Model: HP LOGICAL VOLUME (scsi)
> > Disk /dev/sdb: 5001GB
> > Sector size (logical/physical): 512B/512B
> > Partition Table: gpt
> >
> > Number  Start   End SizeFile system  Name Flags
> >  1  1049kB  5001GB  5001GB  ext4 primary
> >
> > However, the filesystem is still stuck at the old size:
> >
> > # df -h /dev/sdb1
> > Filesystem  Size  Used Avail Use% Mounted on
> > /dev/sdb1   2.7T  2.5T  104G  97% /export
> >
> > I cannot figure out how to resize the actual ext4 filesystem to use the
> > added space.  I have tried both resize2fs without any luck.  When I try
> > resize2fs, I get this error:
> >
> > # resize2fs /dev/sdb1
> > resize2fs 1.42.5 (29-Jul-2012)
> > resize2fs: /dev/sdb1: The combination of flex_bg and
> > !resize_inode features is not supported by resize2fs.
> >
> > In a potentially stupid move, I did indeed remove the resize_inode
> feature
> > from this filesystem in order to get parted to work with it, which
> > ultimately proved unnecessary, but now I cannot add it back:
> >
> > # tune2fs -O resize_inode /dev/sdb1
> > tune2fs 1.42.5 (29-Jul-2012)
> > Setting filesystem feature 'resize_inode' not supported.
> >
> > Is there a way I can resize this filesystem to use the additional 2 TB
> > available to it?
>
> By using a newer e2fsprogs version, this particular problem has been
> fixed in e2fsprogs 1.42.8[1].
>
> Cheers,
>Sven
>
>
> 1. https://bugs.debian.org/696746
>
>


-- 
Dave Parker
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Grow an ext4 filesystem

2017-06-09 Thread David Parker
Hello,

I have a storage server running Debian 7.6 x64.  It's an HP server with 24
HDDs and a hardware RAID controller.  It has a 2.9 TB ext4 filesystem which
resides on a RAID 5 volume, and I recently needed to grow this filesystem
so I added more disks to the volume and then used parted to grow the
partition to the new size of 5 TB, so the space is now available in that
partition:

# parted print /dev/sdb
Model: HP LOGICAL VOLUME (scsi)
Disk /dev/sdb: 5001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End SizeFile system  Name Flags
 1  1049kB  5001GB  5001GB  ext4 primary

However, the filesystem is still stuck at the old size:

# df -h /dev/sdb1
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdb1   2.7T  2.5T  104G  97% /export

I cannot figure out how to resize the actual ext4 filesystem to use the
added space.  I have tried both resize2fs without any luck.  When I try
resize2fs, I get this error:

# resize2fs /dev/sdb1
resize2fs 1.42.5 (29-Jul-2012)
resize2fs: /dev/sdb1: The combination of flex_bg and
!resize_inode features is not supported by resize2fs.

In a potentially stupid move, I did indeed remove the resize_inode feature
from this filesystem in order to get parted to work with it, which
ultimately proved unnecessary, but now I cannot add it back:

# tune2fs -O resize_inode /dev/sdb1
tune2fs 1.42.5 (29-Jul-2012)
Setting filesystem feature 'resize_inode' not supported.

Is there a way I can resize this filesystem to use the additional 2 TB
available to it?  The output of dumpe2fs is below (not including the data
about the 22,355 groups in the filesystem):

dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   
Last mounted on:  /export
Filesystem UUID:  0306070a-6d39-48da-8235-aa99c9e48141
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr dir_index filetype
needs_recovery extent flex_bg sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options:user_xattr acl
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  183140352
Block count:  732530432
Reserved block count: 36626521
Free blocks:  63964655
Free inodes:  183094383
First block:  0
Block size:   4096
Fragment size:4096
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8192
Inode blocks per group:   512
Flex block group size:16
Filesystem created:   Thu Sep 18 14:40:07 2014
Last mount time:  Fri Jun  9 09:46:28 2017
Last write time:  Fri Jun  9 09:46:28 2017
Mount count:  5
Maximum mount count:  -1
Last checked: Thu Jun  8 11:51:32 2017
Check interval:   0 ()
Lifetime writes:  17 TB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Journal inode:8
Default directory hash:   half_md4
Directory Hash Seed:  81bb6e96-1eea-44c2-8dbd-f3b046f9b2a9
Journal backup:   inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length:   32768
Journal sequence: 0x020ee1a8
Journal start:1

Any help is greatly appreciated.  Thanks!

-- 
Dave Parker
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Getting a serial console to work on Jessie

2015-09-07 Thread David Parker
Hello,

Thanks for all the clarification.  I now find myself in need of doing this
again on another server running Jessie, and I just want to make sure I'm
clear on what the best procedure is.  As I understand it, I should
copy /lib/systemd/system/serial-getty@.service to
/etc/systemd/system/serial-getty@ttyS0.service, then
edit serial-getty@ttyS0.service to include the following:

[Service]
ExecStart=
ExecStart=-/sbin/agetty -8 --noclear %I 9600 vt100
...

Is that correct?

Thanks!
Dave

On Sun, Sep 6, 2015 at 9:52 PM, Stephen Powell  wrote:

> On Sun, 06 Sep 2015 16:06:35 -0400 (EDT), Michael Biebl wrote:
> > Am 06.09.2015 um 21:04 schrieb Stephen Powell:
> >> ...
> >>[Service]
> >>ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> >>
> >> But when I restart the service, I get the following error:
> >>
> >> systemd[1]: serial-getty@ttyS0.service: Service has more than one
> ExecStart= setting, which is only allowed for Type=oneshot services.
> Refusing.
> >>
> >> I want to override "ExecStart", not add a new one.  What am I doing
> wrong?
> >
> > By default, systemd will simply merge all drop-ins.
> > In your case, ExecStart is a setting which can not be specified more
> > then once. So you need to "clear" it first. The following should do the
> > trick:
> >
> > [Service]
> > ExecStart=
> > ExecStart=-/sbin/agetty -8 --noclear %I 38400 ibm3151
> >
> >
> > The "ExecStart=" resets the existing setting.
> >
> > ...
>
> That works.  This is definitely a better solution than copying
> serial-getty@.service from /lib/systemd/system to /etc/systemd/system
> and then editing the copy in /etc/systemd/system to change the ExecStart
> value.  It is better for two reasons:
>
> (1) When systemd is serviced, I don't need to recopy and reedit the file
> in order to keep my changes synced up with changes to the file made by
> service to systemd.
>
> (2) It allows two different serial ports to have different ExecStart values
> for two different terminal types, for example.  Using my original method,
> both serial ports would be locked into the same terminal type.
>
> I shall change my documentation accordingly.  Thanks, Michael and Sven
> for your suggestions and help.
>
> Regards,
>
> --
>   .''`. Stephen Powell
>  : :'  :
>  `. `'`
>`-
>
>


-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Getting a serial console to work on Jessie

2015-09-02 Thread David Parker
Thanks.  I actually found that site in a Google search, and it's where I
found the tip on copying the /lib/systemd/system/serial-getty@.service
template file to customize the baud rate, etc.  Specifically, I found the
info I needed at:

http://users.wowway.com/~zlinuxman/serial.htm#Systemd

Thanks!

On Tue, Sep 1, 2015 at 6:43 PM, Stephen Powell <zlinux...@wowway.com> wrote:

> On Tue, 01 Sep 2015 12:13:56 -0400 (EDT), David Parker wrote:
> >
> > I have a bunch of Debian Wheezy servers set up with the console available
> > via the serial port.  Generally, I just add this line to /etc/inittab:
> > ...
> > That's all fine and good, but when I try to do this on my desktop PC
> > running Jessie, it doesn't work.
> > ...
>
> I realize that you already have a resolution to your problem, but if you're
> using serial consoles on Debian Linux, you might find some useful
> information here:
>
>http://users.wowway.com/~zlinuxman/serial.htm
>
> --
>   .''`. Stephen Powell<zlinux...@wowway.com>
>  : :'  :
>  `. `'`
>`-
>
>


-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Getting a serial console to work on Jessie

2015-09-01 Thread David Parker
Hello,

I have a bunch of Debian Wheezy servers set up with the console available
via the serial port.  Generally, I just add this line to /etc/inittab:

co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102

And then run "kill -HUP 1" and the serial console works (I could also use
"telinit q" or "init q" instead of kill -HUP").  I just did this on a
Wheezy server to make sure, and checked the getty processes prior to making
the change:

# ps -ef | grep getty
root  2660 1  0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1
root  2661 1  0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2
root  2662 1  0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3
root  2663 1  0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4
root  2664 1  0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5
root  2665 1  0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6

And then after:

# ps -ef | grep getty
root  2660 1  0 Jul24 tty1 00:00:00 /sbin/getty 38400 tty1
root  2661 1  0 Jul24 tty2 00:00:00 /sbin/getty 38400 tty2
root  2662 1  0 Jul24 tty3 00:00:00 /sbin/getty 38400 tty3
root  2663 1  0 Jul24 tty4 00:00:00 /sbin/getty 38400 tty4
root  2664 1  0 Jul24 tty5 00:00:00 /sbin/getty 38400 tty5
root  2665 1  0 Jul24 tty6 00:00:00 /sbin/getty 38400 tty6
root 31705 1  0 11:33 ttyS000:00:00 /sbin/getty -L ttyS0 9600
vt102

And there's the getty on ttyS0 as expected.

That's all fine and good, but when I try to do this on my desktop PC
running Jessie, it doesn't work.  My PC is running an X server, Gnome,
etc., whereas the servers are not.  Also, on Wheezy, /sbin/getty and
/sbin/agetty seem to be two copies of the same file, wheras on Jessie,
/sbin/getty is a symlink to /sbin/agetty.

The PC is using the default /etc/inittab file.  When I check the list of
getty processes after a clean reboot, there's only this:

# ps -ef | grep getty
root  2092 1  0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1
linux

If I access the virtual consoles via CTRL-ALT-F1, etc., they show up in the
process list only after they have been accessed:

# ps -ef | grep getty
root  2092 1  0 11:50 tty1 00:00:00 /sbin/agetty --noclear tty1
linux
root  2998 1  0 11:56 tty2 00:00:00 /sbin/agetty --noclear tty2
linux
root  3001 1  0 11:56 tty3 00:00:00 /sbin/agetty --noclear tty3
linux

And still not in the same way that they appear on Wheezy ("/sbin/getty
38400 tty1", etc.).  If I add the line for the serial console to
/etc/inittab and reload the init deamon, or even reboot the PC, it simply
does nothing.  No getty process shows up on ttyS0, and no serial console is
available.

I know the serial port itself works, because I can connect to it from my
laptop, then do "screen /dev/ttyS0 9600" on the PC and see characters in
the screen session as I type them on the laptop.  So the serial port works,
and I/O seems to work, but I can't seem to start a persistent getty process
on that port and access the console through it.

Any ideas or suggestions are very much appreciated.

Thanks!
Dave

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Sendmail greeting delay

2015-01-13 Thread David Parker
Hello,

We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit.  We're
using the file /etc/mail/access for access control and rate limiting, and
this is enabled via the following lines in /etc/mail/sendmail.cf:

Kaccess hash -TTMPF /etc/mail/access
# FEATURE(`access_db', `hash -TTMPF /etc/mail/access', `skip')dnl

For some reason, I just can't get it to not pause when greeting external
(non-localhost) connections.  I was testing SSL/TLS connectivity when I
discovered the delay, using openssl s_client -connect smtp-server:465.
If I run this command from the SMTP server, it connects and then prints all
of the SSL and certificate information immediately.  But if I test from
another PC on our network, it connects, pauses for 5 seconds, and then
prints the SSL information.

My /etc/mail/access file is pasted below.  The PC I'm testing from is on
the 10.x.x.x network, which should be allowed to connect with no delay.  I
have also tried setting the default GreetPause to 0 but it still made no
difference.


Connect:localhost RELAY
GreetPause:localhost 0
ClientRate:localhost 0
ClientConn:localhost 0
Connect:127 RELAY
GreetPause:127 0
ClientRate:127 0
ClientConn:127 0
Connect:IPv6:::1 RELAY
GreetPause:IPv6:::1 0
ClientRate:IPv6:::1 0
ClientConn:IPv6:::1 0
Connect:10 RELAY
GreetPause:10 0
ClientRate:10 0
ClientConn:10 0

# Defaults
Connect: REJECT
GreetPause: 5000
ClientRate: 10
ClientConn: 10

# Whitelisted users
Spam:postmaster@ FRIEND
Spam:abuse@ FRIEND
Spam:spam@ FRIEND

# Blacklisted users
reject@ REJECT

# Block invalid IPs
Connect:169.254 REJECT
Connect:192.0.2 REJECT
Connect:224 REJECT
Connect:255 REJECT


Any help would be greatly appreciated.  Thanks!

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Sendmail greeting delay

2015-01-13 Thread David Parker
Thanks for the replies.

The system is not using tcpwrappers, and it's also not a DNS issue.  The
client PC does have a reverse DNS entry.  A tcpdump packet capture on the
server shows the initial connection from the client followed by a bunch of
DNS traffic, all within the same second.  Then nothing happens for exactly
5 seconds, then the server sends data back to the client.

Just to be extra sure, I added an entry for it in /etc/hosts so DNS
wouldn't even be needed.  Still made no difference.

Thanks,
Dave

On Mon, Jan 12, 2015 at 4:21 PM, Chris Davies chris-use...@roaima.co.uk
wrote:

 David Parker dpar...@utica.edu wrote:
  We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit.

  Kaccess hash -TTMPF /etc/mail/access
  # FEATURE(`access_db', `hash -TTMPF /etc/mail/access', `skip')dnl

  For some reason, I just can't get it to not pause when greeting external
  (non-localhost) connections. [...]
  if I test from another PC on our network, it connects, pauses for 5
  seconds, and then prints the SSL information.

 Does your PC have an rDNS entry, and if not could this delay be a DNS
 lookup timeout?

 Chris


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/rfqdobx8se@news.roaima.co.uk




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Sendmail greeting delay

2015-01-13 Thread David Parker
Thanks, but it looks like the IDENT setting was the culprit.  I just had to
change this setting in sendmail.cf:

O Timeout.ident=5s

Changing it from 5s to 0s resolved the problem immediately.  Thanks again,
everyone!

On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle jsie...@psu.edu wrote:

 On 2015-01-13 at 12:38, David Parker wrote:

  Hello,

 My /etc/mail/access file is pasted below.  The PC I'm testing from is on
 the 10.x.x.x network, which should be allowed to
 connect with no delay.  I have also tried setting the default GreetPause
 to 0 but it still made no difference.

 
 Connect:localhost RELAY
 GreetPause:localhost 0
 ClientRate:localhost 0
 ClientConn:localhost 0
 Connect:127 RELAY
 GreetPause:127 0
 ClientRate:127 0
 ClientConn:127 0
 Connect:IPv6:::1 RELAY
 GreetPause:IPv6:::1 0
 ClientRate:IPv6:::1 0
 ClientConn:IPv6:::1 0
 Connect:10 RELAY
 GreetPause:10 0
 ClientRate:10 0
 ClientConn:10 0



 Dave,
 I'm struggling with a reference beyond my own work. Please try
 putting a second and maybe a third octet on your GreetPause: 10 line. Also,
 please verify you are issuing a kill -HUP on sendmail. We never got
 sendmail greetpause to work with a single octet. Normally we do 3 octets
 for all the RFC1918 addresses we use.

 -Jonathan




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Sendmail greeting delay

2015-01-13 Thread David Parker
Just for the sake of completeness, this wasn't actually an issue with the
GreetPause option or anything else in the access file.  The problem was
that sendmail was attempting an IDENT query to the client, with a 5-second
timeout.  The access file wasn't even checked until after the timeout
expired.  In retrospect, I guess it makes sense because I was testing this
by connecting with openssl, which is just looking for the SSL/TLS info at
the beginning of the connection, and doesn't need to wait for the
greeting.  The GreetPause values work as expected for actual client
connections on port 25, 465, or 587.

Thanks!

On Tue, Jan 13, 2015 at 3:27 PM, David Parker dpar...@utica.edu wrote:

 Thanks, but it looks like the IDENT setting was the culprit.  I just had
 to change this setting in sendmail.cf:

 O Timeout.ident=5s

 Changing it from 5s to 0s resolved the problem immediately.  Thanks again,
 everyone!

 On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle jsie...@psu.edu wrote:

 On 2015-01-13 at 12:38, David Parker wrote:

  Hello,

 My /etc/mail/access file is pasted below.  The PC I'm testing from is on
 the 10.x.x.x network, which should be allowed to
 connect with no delay.  I have also tried setting the default GreetPause
 to 0 but it still made no difference.

 
 Connect:localhost RELAY
 GreetPause:localhost 0
 ClientRate:localhost 0
 ClientConn:localhost 0
 Connect:127 RELAY
 GreetPause:127 0
 ClientRate:127 0
 ClientConn:127 0
 Connect:IPv6:::1 RELAY
 GreetPause:IPv6:::1 0
 ClientRate:IPv6:::1 0
 ClientConn:IPv6:::1 0
 Connect:10 RELAY
 GreetPause:10 0
 ClientRate:10 0
 ClientConn:10 0



 Dave,
 I'm struggling with a reference beyond my own work. Please try
 putting a second and maybe a third octet on your GreetPause: 10 line. Also,
 please verify you are issuing a kill -HUP on sendmail. We never got
 sendmail greetpause to work with a single octet. Normally we do 3 octets
 for all the RFC1918 addresses we use.

 -Jonathan




 --
 Dave Parker
 Systems Administrator
 Utica College
 Integrated Information Technology Services
 (315) 792-3229
 Registered Linux User #408177




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Sendmail greeting delay

2015-01-13 Thread David Parker
Yes!  That seems to be the culprit.  I ran an strace on the sendmail
process and that's exactly what happens:

[ ... ]
4007  15:09:08.386921 connect(5, {sa_family=AF_INET, sin_port=htons(113),
sin_addr=inet_addr(10.3.1.40)}, 16 unfinished ...
3792  15:09:13.386272 ... select resumed ) = 0 (Timeout)
[ ... ]

Where 10.3.1.40 is the IP of the client PC.  So now I just need to dig into
the config and figure out how to stop it.  Thanks!


On Tue, Jan 13, 2015 at 3:16 PM, Joe j...@jretrading.com wrote:

 On Tue, 13 Jan 2015 20:12:11 +
 Joe j...@jretrading.com wrote:

  On Tue, 13 Jan 2015 14:27:42 -0500
  David Parker dpar...@utica.edu wrote:
 
   Thanks for the replies.
  
   The system is not using tcpwrappers, and it's also not a DNS issue.
   The client PC does have a reverse DNS entry.  A tcpdump packet
   capture on the server shows the initial connection from the client
   followed by a bunch of DNS traffic, all within the same second.
   Then nothing happens for exactly 5 seconds, then the server sends
   data back to the client.
  
   Just to be extra sure, I added an entry for it in /etc/hosts so DNS
   wouldn't even be needed.  Still made no difference.
  
 
  Is it asking for an ident from the connecting server (TCP port 7)?
  This is an old-fashioned custom, when computers with MTAs also ran
  ident servers, which provided some fairly harmless information.
 
  Exim4 can certainly ask for an ident, and does nothing for a
  configurable timeout unless one is received, or the sender address is
  whitelisted. It is a simple anti-spam measure, as practically nothing
  runs ident servers today, and most malware will give up before a
  thirty-second timeout expires, whereas a legitimate MTA will wait
  for that long.
 

 OK, where did the 7 come from? Should be port 113. I saw it just as the
 mouse button clicked...

 --
 Joe


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/20150113201613.0b84c...@jresid.jretrading.com




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


SFTP chroot and FileZilla question

2014-09-17 Thread David Parker
Hello,

I have set up a Debian Wheezy box as a simple SFTP server.  I have created
an SFTP-only user account and configured SSH to jail the account to its
home directory with the following in sshd_config:

Subsystem sftp internal-sftp

Match group radius
ChrootDirectory /home
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

Where radius is the primary group for the SFTP user account.  All of this
works fine when I connect using OpenSSH from another Linux box.  I land in
the /home directory, but running pwd in the SFTP session shows that the
working directory is / and then I cannot navigate any further up the
filesystem tree.  That's exactly what I would expect

However, if I connect using FileZilla, I see that I am in /home and I can
freely navigate the rest of the filesystem.  What's up with that?  I would
really like for this user account to be jailed regardless of the client,
and it seems to me like it should be, since this is a server-side
configuration.

Any help or insight would be greatly appreciated.  Thanks!

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Accessing Glipper in testing (Jessie)

2014-02-24 Thread David Parker
Hello,

I was running Wheezy for a while, with a little bit of tweaking, I came to
enjoy the new Gnome interface (I had been a KDE fan for years until I
upgraded to Wheezy).  In installed the Glipper clipboard manager and could
access it by placing the mouse cursor into the lower right corner of the
screen.  It was otherwise hidden, and I thought the whole thing was very
slick.

I recently upgraded to testing, and Glipper disappeared.  It's still
installed, but I can no longer access it like I used to.  The only way I
can find to access Glipper is to open the Gnome Tweak Tool and enable the
Window list extension.  This enables a traditional task bar at the bottom
of the screen which shows the currently open windows, a workspace switcher,
and at the very end on the right it has a blue circle with a 1 on it.  If
I click on that blue circle, a gray bar slides up and shows the Glipper
icon, which I can then click on.

I don't care for this solution, because the task bar takes up space at the
bottom of the screen and I can't seem to hide it, and I also have to click
the blue circle in order to get to Glipper.  I neither need nor want the
window list or workspace switcher, so to have it there simply for the
puspose of accessing Glipper is irksome.  It was much nicer when I could
simply move the cursor to the lower right corner without clicking on
anything.  Is there something I can do to get this old behavior back?

Thanks in advance.

- Dave

P.S.  Yes, I do realize that I can use CTRL-ALT-C to pop up Glipper
anytime, and that's what I'm doing right now, but I really liked the
mouse-only solution I had before.

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Long delays caused by rpcinfo

2013-09-24 Thread David Parker
Hello,

I recently set up a VM running Debian Wheezy (amd64) to be used as an NFS
server.  I noticed that running /etc/init.d/nfs-kernel-server start would
hang for about 60 seconds while starting nfsd, but if I started nfsd
directly, there was no problem.  After a lot of strace adventures and
Google searches, I eventually traced the problem to the rpcinfo command.
 I commented out the following lines from the nfs-kernel-server init
script, everything started working:

$PREFIX/bin/rpcinfo -u localhost nfs 3 /dev/null 21 ||
RPCMOUNTDOPTS=$RPCMOUNTDOPTS --no-nfs-version 3

Indeed, running rpcinfo -u localhost nfs 3 causes a long pause before it
finally outputs the following:

rpcinfo: RPC: Port mapper failure - Timed out
program 13 version 3 is not available

Running rpcinfo -p localhost causes the same long pause, and then outputs
this:

rpcinfo: can't contact portmapper: RPC: Remote system error -
Connection timed out

Running showmount --exports results in the long pause, and then outputs
this:

clnt_create: RPC: Port mapper failure - Timed out

However, running rpcinfo -p without specifying the host returns
immediately:

program vers proto   port  service
 104   tcp111  portmapper
 103   tcp111  portmapper
 102   tcp111  portmapper
 104   udp111  portmapper
 103   udp111  portmapper
 102   udp111  portmapper
 1000241   udp  42629  status
 1000241   tcp  56434  status

I have confirmed that rpc.statd is running, which I believe is the port
mapper in newer distributions.

Any idea why I would be seeing this behavior?  Is there a configuration
option I'm missing?  Any help would be greatly appreciated.

Thanks!
Dave

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
Thanks for the reply.  Unfortunately, it looks like rpcbind is not the
culprit.  I verified that rpcbind installed and running:

root@test-vm-1:~# ps -ef | grep bind
root  1538 1  0 11:23 ?00:00:00 /sbin/rpcbind -w
root 28002  2289  0 15:17 pts/000:00:00 grep bind

I restarted the rpcbind service just to make sure...

root@test-vm-1:~# service rpcbind stop
[ ok ] Stopping rpcbind daemon
root@test-vm-1:~# ps -ef | grep bind
root 28227  2289  0 15:18 pts/000:00:00 grep bind
root@test-vm-1:~# service rpcbind start
[ ok ] Starting rpcbind daemon
root@test-vm-1:~# ps -ef | grep bind
root 28254 1  0 15:18 ?00:00:00 /sbin/rpcbind -w
root 28288  2289  0 15:18 pts/000:00:00 grep bind

... but the problem persisted:

root@test-vm-1:~# rpcinfo -p localhost
LONG PAUSE
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection
timed out

Anything else I can look into?  FWIW, an strace shows that rpcbind gets
stuck when trying to connect to a socket on the loopback interface.  The
relevant portion of the strace output is below:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
getsockname(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(0.0.0.0)}, [16]) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(944),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(944),
sin_addr=inet_addr(0.0.0.0)}, [16]) = 0
getsockopt(3, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
mmap(NULL, 200704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fdfa4cfb000
getpeername(3, 0x7fff62295d00, [128])   = -1 ENOTCONN (Transport endpoint
is not connected)
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 ETIMEDOUT (Connection timed out)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)= 0
write(2, rpcinfo: can't contact portmappe..., 83rpcinfo: can't contact
portmapper: RPC: Remote system error - Connection timed out
) = 83
exit_group(1)

The long pause happens after this call:

connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr(127.0.0.1)}, 16)

Which eventually results in = -1 ETIMEDOUT (Connection timed out) and
moves on.

As always, any help will be greatly appreciated!

- Dave


On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote:

 David Parker wrote:
  I have confirmed that rpc.statd is running, which I believe is the port
  mapper in newer distributions.

 AFAIK rpc.statd is not a portmapper replacement.  The two portmapper
 equivalents that I am aware of are:

   portmap - RPC port mapper
   rpcbind - converts RPC program numbers into universal addresses

 The 'portmap' package is the older one.  I think in newer releases it
 has been replaced with 'rpcbind'.  I don't know what is different
 between them.

 Try installing rpcbind.  I think that will solve your problem.

 Bob




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
root@test-vm-1:~# cat /etc/hosts
127.0.0.1localhostlocalhost
192.168.25.200  testbed.utica.edu   testbed
192.168.25.201  test-vm-1.utica.edu test-vm-1
192.168.25.202  test-vm-2.utica.edu test-vm-2
192.168.25.203  test-vm-3.utica.edu test-vm-3
192.168.25.204  test-vm-4.utica.edu test-vm-4

/etc/hosts.allow and /etc/hosts.deny are the Debian-delivered versions;
they only contain comments, no actual rules.

Thanks,
Dave


On Tue, Sep 24, 2013 at 3:41 PM, Mark Neyhart mark.neyh...@akleg.govwrote:

 David Parker wrote:
  Thanks for the reply.  Unfortunately, it looks like rpcbind is not the
  culprit.  I verified that rpcbind installed and running:
 
 
  Anything else I can look into?  FWIW, an strace shows that rpcbind gets
  stuck when trying to connect to a socket on the loopback interface.  The
  relevant portion of the strace output is below:
 
 Maybe rpcbind is not listening on the loopback interface.

 What are the contents of /etc/hosts, /etc/hosts.deny and /etc/hosts.allow?

 Mark


 --
 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/5241eaf4.20...@akleg.gov




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
Hello,

Thanks for the suggestions.  The combination of checking
/etc/network/interfaces and verifying that rpcbind was listening on
127.0.0.1 led me in the right direction, and boy do I feel silly...

Somehow, my interfaces file was missing the loopback entry, so the loopback
interface showed in the ifconfig output but it wasn't actually up.  I
added these lines:

auto lo
iface lo inet loopback

Then, after ifup lo, everything just worked.

I think I wrote the interfaces file from scratch and copied it over the
original, and of course, I didn't include the loopback interface.  *Sigh*.

Thanks again!

- Dave


On Tue, Sep 24, 2013 at 9:52 PM, Tom H tomh0...@gmail.com wrote:

 On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote:
  David Parker wrote:
 
  I have confirmed that rpc.statd is running, which I believe is the port
  mapper in newer distributions.
 
  AFAIK rpc.statd is not a portmapper replacement.  The two portmapper
  equivalents that I am aware of are:
 
portmap - RPC port mapper
rpcbind - converts RPC program numbers into universal addresses
 
  The 'portmap' package is the older one.  I think in newer releases it
  has been replaced with 'rpcbind'.  I don't know what is different
  between them.

 rpcbind uses ti-rpc rather than sunrpc and can handle nfsv4 and ipv6.


 --
 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/CAOdo=SwGGBU=lyjyhxh0tfbddoobogbgkzdexeuvka2eog+...@mail.gmail.com




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: Long delays caused by rpcinfo

2013-09-24 Thread David Parker
And for the sake of completeness, yes, NFS clients were able to mount the
exported volume on this server once the nfs-kernel-server startup
completed.  And that makes a lot of sense to me now, because the entire
issue was in rpcbind's attempt to verify that it could connect to
127.0.0.1, which doesn't matter for remote mounts.


On Tue, Sep 24, 2013 at 11:38 PM, David Parker dpar...@utica.edu wrote:

 Hello,

 Thanks for the suggestions.  The combination of checking
 /etc/network/interfaces and verifying that rpcbind was listening on
 127.0.0.1 led me in the right direction, and boy do I feel silly...

 Somehow, my interfaces file was missing the loopback entry, so the
 loopback interface showed in the ifconfig output but it wasn't actually
 up.  I added these lines:

 auto lo
 iface lo inet loopback

 Then, after ifup lo, everything just worked.

 I think I wrote the interfaces file from scratch and copied it over the
 original, and of course, I didn't include the loopback interface.  *Sigh*.

 Thanks again!

 - Dave


 On Tue, Sep 24, 2013 at 9:52 PM, Tom H tomh0...@gmail.com wrote:

 On Tue, Sep 24, 2013 at 3:02 PM, Bob Proulx b...@proulx.com wrote:
  David Parker wrote:
 
  I have confirmed that rpc.statd is running, which I believe is the port
  mapper in newer distributions.
 
  AFAIK rpc.statd is not a portmapper replacement.  The two portmapper
  equivalents that I am aware of are:
 
portmap - RPC port mapper
rpcbind - converts RPC program numbers into universal addresses
 
  The 'portmap' package is the older one.  I think in newer releases it
  has been replaced with 'rpcbind'.  I don't know what is different
  between them.

 rpcbind uses ti-rpc rather than sunrpc and can handle nfsv4 and ipv6.


 --
 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/CAOdo=SwGGBU=lyjyhxh0tfbddoobogbgkzdexeuvka2eog+...@mail.gmail.com




 --
 Dave Parker
 Systems Administrator
 Utica College
 Integrated Information Technology Services
 (315) 792-3229
 Registered Linux User #408177




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


NFS Failover

2013-06-26 Thread David Parker
Hello,

I'm wondering if there is a way to set up a highly-available NFS share
using two servers (Debian Wheezy), where the shared volume can failover if
the primary server goes down.  My idea was to use two NFS servers and keep
the exported directories in sync using DRDB.  On the client, mount the
share via autofs using the Replicated Server syntax.

For example, say I have two servers called server1 and server2, each of
which is exporting the directory /export/data via NFS, and /export/data is
a synced DRDB filesystem shared between them.On the client, set up an
autofs map file to mount the share and add this line:

/mnt/dataserver1,server2:/export/data

This is close, but it doesn't do what I'm looking to do.  This seems to
round-robin between the two servers whenever the filesystem needs to be
mounted, and if the selected server isn't available, it then tries the
other one.

What I'm looking for is a way to have the client be aware of both servers,
and gracefully failover between them.  I thought about using Pacemaker and
Corosync to provide a virtual IP which floats between the servers, but
would that work with NFS?  Let's say I have an established NFS mount and
server1 fails, and the virtual IP fails over to server2.  Wouldn't there be
a bunch of NFS socket and state information which server2 is unaware of,
therefore rendering the connection useless on the client?  Also, data
integrity is essential in this scenario, so what about active writes to the
NFS share which are happening at the time the server-side failover takes
place?

In full disclosure, I have tried the autofs method but not the
Pacemaker/Corosyn HA method, so some experimentation might answer my
questions.  In the meantime, any help would be greatly appreciated.

Thanks!
Dave

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: NFS Failover

2013-06-26 Thread David Parker
On Wed, Jun 26, 2013 at 3:20 PM, Adrian Fita adrian.f...@gmail.com wrote:

 On 06/26/2013 09:11 PM, David Parker wrote:
 
  What I'm looking for is a way to have the client be aware of both
  servers, and gracefully failover between them.  I thought about using
  Pacemaker and Corosync to provide a virtual IP which floats between the
  servers, but would that work with NFS?  Let's say I have an established
  NFS mount and server1 fails, and the virtual IP fails over to server2.
   Wouldn't there be a bunch of NFS socket and state information which
  server2 is unaware of, therefore rendering the connection useless on the
  client?  Also, data integrity is essential in this scenario, so what
  about active writes to the NFS share which are happening at the time the
  server-side failover takes place?
 

 I have also studied NFS fail-over with Pacemaker/Corosync/DRBD and it
 could work with NFSv3; NFSv4 uses TCP which makes things very hard. But
 even with NFSv3 I stumbled over strange situations, the likes of which I
 don't really remember, but the bottom line I have decided that NFS NFS
 fail-over is too fiddly and hard to control reliably. Now I'm studying
 using Gluster for replicating data between nodes and mounting the
 gluster volumes on the clients via glusterfs - this seems like a much
 better, simpler and more robust approach. I suggest you take a look at
 Gluster, it's an exceptionally good technology.


Thank you for the information and suggestions.  Dan, thanks for the link,
it exactly describes what I'm trying to do.  As you both pointed out, it
would be easier and safer to use a clustered filesystem instead of NFS for
this project.  I'll check out GlusterFS, it looks like a great option.

Thanks!

-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Re: what's your Debian uptime?

2013-04-26 Thread David Parker
I have a box running Etch that hasn't been rebooted in 1,589 days:

irp:~# uptime
 12:09:06 up 1589 days, 18:23,  1 user,  load average: 0.00, 0.01, 0.03
irp:~#

I swear this is real.  :-)


On Sun, Apr 21, 2013 at 6:32 PM, Vincent Lefevre vinc...@vinc17.net wrote:

 On 2013-04-20 19:24:00 -0600, Bob Proulx wrote:
  Vincent Lefevre wrote:
   That's theory. In practice, old machines get no longer supported...
   I submitted a bug report (and a patch), but AFAIK the bug has never
   been fixed. I upgraded everything except the kernel, without being
   sure I could boot it again (udev incompatibilities...). That's why
   the machine was no longer rebooted.
 
  And if you get into a situation where the machine reboots whether you
  desire it or not?  Power, cosmic ray hit, dead cooling fan, other?

 It was a laptop, so that power wasn't a problem. A hardware failure
 wuld have meant that the machine would be probably dead anyway (after
 the last boot the laptop was already more than 8 year old). This is
 actually what happened a few months ago: strange noises from the disk
 and I/O errors...

  It happens. Even with UPS mains and redundant power supplies.
  Hardware doesn't last forever. Will it boot? If so then great. If
  not then you have a nasty problem to sort out and the machine is
  down until you do. I would rather know about it on my schedule
  rather than its schedule.

 Even if there were a software problem, I wouldn't have wasting my
 time to try to fix it for a machine that was almost no longer used
 (mainly just for portability testing), in particular if the machine
 couldn't boot.

 --
 Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
 Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


 --
 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/20130421223223.gg9...@xvii.vinc17.org




-- 
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


Debian Squeeze ext4 corruption under VMware

2012-05-15 Thread David Parker

Hello,

We have several Debian Squeeze servers running in VMs under VMware ESXi 
4.1.0 (build 502767 if that matters) with the latest VMware Tools bundle 
installed.  We're using the ext4 filesystem on each of these servers.  
We have had a few crashes of our VMware infrastructure, and each time, 
the Debian servers have all suffered filesystem corruption.  The problem 
seems to be that VMware attempts to freeze each VM when something goes 
wrong, and depending on the circumstances, it tries to move each VM to 
another VMware server.  This works fine for our Windows servers, but the 
Debian servers get all messed up.  Each VM remains in a running state, 
but the root filesystem is mounted read-only, and the console shows a 
ton of filesystem errors.  In most cases, the corruption has been 
recoverable by booting the VM to a Knoppix live CD and running fsck on 
the unmounted filesystem.  We've tried forcing fsck to run on boot, but 
for some reason it will not repair the filesystem, hence why we need to 
boot to a live CD.  In a few isolated cases, we have ended up with 
serious filesystem damage resulting in a huge number of files in 
/lost+found, and we've just rebuilt the VMs.


I'm just wondering if anyone else has seen this, or if anyone knows a 
way to make Debian deal with VMware's shenanigans more smoothly.  We do 
have a planned upgrade to VMware ESXi 5.0 in the next few months, and 
we're looking to get a new SAN solution (our SAN has been the source of 
at least two of these crashes), but I'd really like to get a handle on 
this issue sooner in case we have another problem.  I've Googled this 
problem, but I'm not finding much useful information.


Thanks!

- Dave

--

Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177


--
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/4fb2604f.9050...@utica.edu



Re: [OT] Nagios question

2011-08-26 Thread David Parker
- Original Message -
From: Brad Alexander stor...@gmail.com
Date: Friday, August 26, 2011 6:07 pm
Subject: [OT] Nagios question
To: Debian-user List debian-user@lists.debian.org

 There is a nagios plugin called check_ubc, which checks for increasing 
 /proc/user_beancounters. This is an indication of a spec that needs to be 
 tuned for the vm. In any case, I can run the check_ubc from the command line 
 on both machines, but on the original server, hornet, when I run it from nrpe 
 on the nagios server:
 
 # /usr/local/nagios/libexec/check_nrpe -H hornet -c check_ubc
 OK. 

 On the new server, built two days ago, same configuration, I get

 # /usr/local/nagios/libexec/check_nrpe -H akagi -c check_ubc
 NRPE: Command 'check_ubc' not defined
 
 I have the check_ubc script in /usr/local/nagios/libexec/nrpe_local on both, 
 the command is defined in/usr/local/nagios/etc/nrpe_local/override.cfg with 
 an include in /usr/local/nagios/etc/nrpe.cfg. Everything is the same on both 
 servers. Why does the command work on one but not the other?
 
Just to clarify, the configs are *exactly* the same?  Are these two machines 
different architectures (32-bit vs. 64-bit, etc.)?

    - Dave



Re: [OT] Nagios question

2011-08-26 Thread David Parker
- Original Message -
From: Brad Alexander stor...@gmail.com
Date: Friday, August 26, 2011 8:13 pm
Subject: [Spam: 5.2] Re: [OT] Nagios question
To: David Parker dpar...@utica.edu

 On Fri, Aug 26, 2011 at 6:41 PM, David Parker dpar...@utica.edu wrote:
  - Original Message -
 From: Brad Alexander stor...@gmail.com
 Date: Friday, August 26, 2011 6:07 pm
 Subject: [OT] Nagios question
  To: Debian-user List debian-user@lists.debian.org

  There is a nagios plugin called check_ubc, which checks for increasing 
  /proc/user_beancounters. This is an indication of a spec that needs to be 
  tuned for the vm. In any case, I can run the check_ubc from the command 
  line on both machines, but on the original server, hornet, when I run it 
  from nrpe on the nagios server:
  
  # /usr/local/nagios/libexec/check_nrpe -H hornet -c check_ubc
  OK. 
 
  On the new server, built two days ago, same configuration, I get

  # /usr/local/nagios/libexec/check_nrpe -H akagi -c check_ubc
   NRPE: Command 'check_ubc' not defined
 
  I have the check_ubc script in /usr/local/nagios/libexec/nrpe_local on 
  both, the command is defined 
  in/usr/local/nagios/etc/nrpe_local/override.cfg with an include in 
  /usr/local/nagios/etc/nrpe.cfg. Everything is the same on both servers. Why 
  does the command work on one but not the other?
  
 Just to clarify, the configs are *exactly* the same?  Are these two machines 
 different architectures (32-bit vs. 64-bit, etc.)?

 Nope. Both are Dell PE 1850s with dual 3.2GHz Xeons. The only differing 
 factor is that one has 2GB of RAM and the other has 6GB. 
 
That's really strange.  This may seem obvious, but are the permissions on the 
config file correct, and is it readable by the user who is running this 
command?  Also, is the Nagios version the same on the two boxes?

Does strace show anything?  Try:

    strace -o strace.out /usr/local/nagios/libexec/check_nrpe -H akagi -c 
check_ubc

Then check strace.out and see if it shows anything along the lines of 
permissions errors, parsing errors, etc.

    - Dave



Re: Serial Console Access

2011-05-22 Thread David Parker
 In a nut-shell, this is what is how my Debian box is configured (for serial 
 console)
   root@leviathan:~# setserial -g /dev/ttyS[0123] /dev/ttyS0, UART: 16550A, 
Port: 0xdc00, IRQ: 16 /dev/ttyS1, UART: 16550A, Port: 0xdc00, IRQ: 16 
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4   /dev/ttyS3, UART: unknown, 
Port: 0x02e8, IRQ: 3 root@leviathan:~# grep -e tty -e serial 
/etc/default/grub GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,115200n8' 
GRUB_TERMINAL=serial   GRUB_SERIAL_COMMAND=serial --speed=115200 --unit=0 
--word=8 --parity=no --stop=1 #GRUB_CMDLINE_LINUX='console=ttyS1 
console=ttyS1,38400n8' #GRUB_TERMINAL=serial #GRUB_SERIAL_COMMAND=serial 
--speed=38400 --unit=0 --word=8 --parity=no --stop=1   root@leviathan:~# grep 
ttyS /etc/inittab #T0:23:respawn:/sbin/getty -L ttyS0 19200 vt100 
#T1:23:respawn:/sbin/getty -L ttyS1 19200 vt100 T0:2345:respawn:/sbin/getty -L 
ttyS0 115200 vt100   #T0:2345:respawn:/sbin/getty -L ttyS1 38400 vt100 
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3 root@leviathan:~# grep ttyS 
/etc/securetty ttyS0 #ttyS1 root@leviathan:~#  
 Now, the one part that could be causing a problem on the server but I can't 
 tell is setserial's output, which is noteworthy. The motherboards COM header 
 is expressly disabled in the bios (as I don't have the header to physically 
 put in this box), but I do have a Serial Card and many working null modem 
 cables.  
 The serial card is: 01:09.0 Serial controller: NetMos Technology PCI 9835 
 Multi-I/O Controller (rev 01)
Was your onboard serial port disabled in the BIOS at the time you installed 
Debian?  If it was, then the first port on your serial card should be mapped to 
/dev/ttyS0.  If not, then udev may have picked up the onboard port as 
/dev/ttyS0 and made your card /dev/ttyS1 (or another number).

I have two Debian 4 boxes with the serial console working.  It has been quite a 
while since I set this up, but I'm pretty sure that I just added this line to 
/etc/inittab and then restarted init:

co:2345:respawn:/sbin/getty -L ttyS0 9600 vt102

I think the co may have something to do with it.  Sorry I can't be more help, 
I'm really rusty on this.  I did this 5 years ago and I've never had to do it 
again.

Hope this helps.

    - Dave




Re: Quiet option for ifup/ifdown (dhcp)

2011-01-28 Thread David Parker
 dhclient has a quiet option but because ifup/ifdown calls it I haven't
 been able overide this.

ifup must get called from a script, so you could probably just edit the script 
and suppress the output from ifup.

- Dave


Re: Programming question

2010-05-14 Thread David Parker
- Original Message -
From: Alexander Samad a...@samad.com.au
Date: Friday, May 14, 2010 9:35 pm
Subject: Programming question
To: Debian User List debian-user@lists.debian.org

 Hi
 
 I was wondering if it is possible to decode this javascript from the
 command line
 
 
 var serializer = new Serializer()
 serializer.deserialize('B64ENCe30=')
 
 can't find any reference on how serialize works and can't find any
 cmdline tools to help
 
 Alex


Hi Alex,

I'm not an expert, but my understanding is that serialization is a process 
which converts various data types into a byte stream which can be stored and 
transmitted like a string.  If you had some serialized data stored in a file 
and you knew what scheme was used to serialize the data, you might be able to 
use a tool such as dd to decode it.  I'm not sure if there is a standard 
serialization encoding scheme, though, or if it is implemented differently 
across various programming languages.  The Wikipedia article on serialization 
might answer some questions:

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

Hope this helps.

    - Dave




Re: bind9 rndc reload problem

2010-03-31 Thread David Parker
- Original Message -
From: Jari Fredriksson ja...@iki.fi
Date: Wednesday, March 31, 2010 9:24 pm
Subject: bind9 rndc reload problem
To: Debian Users list debian-user@lists.debian.org

 
 When I command rndc reload, this will be written to daemon.log
 
 Apr  1 04:13:17 spitfire named[19287]: received control 
 channel command
 'reload'
 Apr  1 04:13:17 spitfire named[19287]: loading 
 configuration from
 '/etc/bind/named.conf'
 Apr  1 04:13:17 spitfire named[19287]: using default 
 UDP/IPv4 port
 range: [1024, 65535]
 Apr  1 04:13:17 spitfire named[19287]: using default 
 UDP/IPv6 port
 range: [1024, 65535]
 Apr  1 04:13:17 spitfire named[19287]: reloading 
 configuration succeeded
 Apr  1 04:13:17 spitfire named[19287]: reloading zones succeeded
 
 All seems good. But no, if I have changed, or modified the zone 
 records,for example added or removed an address, the changes do 
 not show!
 
 Using Debian Lenny, BIND 9.6.1-P3
 
 I tried to google, but could not find a suitable solution.
 
 The new configuration comes alive if I do a restart for bind, 
 but that
 reload does not make it.
 
 The configuration files are as follows:
 
 /etc/bind/named.conf
     |
     /etc/bind/named.conf.local
  |
  
 /etc/bind/myzone.hosts
 I think this is how it is supposed to be in Debian.
 
 So.
 1. I change a zone file
 2. I add one to serial in the zone file
 3. I command rndc reload
 4. rndc connects to named, and all seems good
 5. changes do not show up :(
 
 Any ideas?
 

Hello,
 
 Are you changing the serial number in the zone file?  Generally, a good way to 
create the serial number is to use the format of:
 
 MMDDNN
 
 Where:
 
 Y = Year
 M = Month
 D = Day
 N = revision number starting at 00
 
 So if you edit the file on March 31, 2010, you would make the serial number 
2010033100.  If you edit it again on the same day, you would just increment the 
last digit.  You should update the serial number in any zone file you edit 
before running rndc reload.
 
     - Dave




Re: connecting to WPA wireless network with ipw2100

2010-03-31 Thread David Parker
Whoops.

  /sbin/iwscan list
 
Sorry, that command should be:
 
 /sbin/iwlist scan
 
     - Dave
 



Re: connecting to WPA wireless network with ipw2100

2010-03-31 Thread David Parker
- Original Message -
From: Seb levi.vi...@gmail.com
Date: Wednesday, March 31, 2010 8:32 pm
Subject: connecting to WPA wireless network with ipw2100
To: debian-user@lists.debian.org

 Hello all!
 
 I just aquired an IBM Thinkpad X31 laptop and have to work out the
 wireless (amongst other things). The firmware (firmware-ipw2x00) and
 drivers are installed and working (I think).
 
 dojo:~# lspci | grep -i wireless
 02:02.0 Network controller: Intel Corporation PRO/Wireless LAN 
 2100 3B Mini PCI Adapter (rev 04)
 
 I'm using wicd from the lenny-backports since I had very good
 experiences with wicd on my other machines. However, if I try and
 connect to my wireless - WPA-TKIP, Mixed mode (B and G) - I keep
 getting the message: Connection failed: Could not contact the
 wireless access point. I'm positive the WAP is up and running since
 I'm writing this here from my other machine through it.
 
 Syslog contains some dhclient messages that look like this:
 
 00:57:52 dhclient: Listening on LPF/eth2/00:04:23:96:55:2a
 00:57:52 dhclient: Sending on   LPF/eth2/00:04:23:96:55:2a
 00:57:52 dhclient: Sending on   Socket/fallback
 
 And that's all that sticks out to me...
 
 Any hints/tips/clues much appreciated, let me know if you need any
 more info.
 
 TIA, Sebi
 

Hello,
 
 Proving that your wireless card can communicate with your access point would 
be a good first step.  You can see if your card is picking up the access point 
by installing the wireless-tools package and then running this command:
 
 /sbin/iwscan list
 
 You should see information about every access point within an acceptable range 
of your laptop.  If your access point shows up, then at least you know that it 
is not a driver problem.  If it does not show up, or if you can't even get 
iwscan to work, then you might have a driver problem or some bad hardware.
 
 I have a laptop with an Intel Corporation PRO/Wireless 2200BG wireless card 
and it works fine on my WPA-TKIP wireless network using the ipw2200 driver.  
(AP is a Linksys WAP54G).
 
 Hope this helps.
 
     - Dave
 



Re: samba query

2009-11-13 Thread David Parker
 Hi,
 
 How can I make samba only accept log ins, if the password 
 supplied by
 the client, matches that username on the server? eg. blank or wrong
 passwords shouldn't be allowed access to the server, so how do I 
 enablethis? It seems samba by default accepts blank passwords, 
 and lets the
 client mount the share, or even if the password is wrong.
 
 Also, will this behaviour that I am asking about be compatible 
 with win
 xp? I'll add a user on the linux server, with the same user name 
 as the
 xp one, will the xp client be able to connect?
 
 Thanks,
 Dan.

This works fine for me.  You might simply be missing a line in your config file 
or something.
 
 In your smb.conf:
 
     # Guest account
     guest account = smbguest
 
     # Security mode
     security = user
 
     # Passwords
     encrypt passwords = true
     smb passwd file = /etc/samba/smbpasswd
     unix password sync = Yes
     passwd program = /usr/bin/passwd %u
     passwd chat = *New*password* %n\n *Retype*new*password* %n\n 
*passwd:*all*authentication*tokens*updated*successfully*
     pam password change = yes
 
     # User authentication
     username map = /etc/samba/smbusers
     obey pam restrictions = yes
 
     # Anonymous users mapped to guest user
     map to guest = bad user
 
In your smbusers file, map Linux usernames to Windows usernames:
 
     smbguest = guest
     myuser = My User
 
 So the Windows user My User would get mapped to the Linux user myuser.  You 
can specify passwords for the Samba users using smbpasswd:
 
     smbpasswd -c /etc/samba/smb.conf myuser
 
 And just replace /etc/samba with the path to your smb.conf file if it is 
different.
 
 This works fine for me from Windows XP.  When I access a Samba share I get 
prompted for the password, and if I put in an incorrect password then I get 
re-prompted a few times and eventually locked out (technically I get mapped to 
the Samba guest user, but my guest user has no access).  If I put in the 
correct password then itall works fine.
 
 Hope this helps.
 
     - Dave
 



Re: Domain server on linux

2009-11-12 Thread David Parker
 Need some help, i just want to know, is linux can be a domain server ??
 in my office, we already have 2 server, it is DHCP server and domain server. 
 both of it using windows.

 i want to change the domain server with linux, but don't know how??
 
 may be some body have some experience to share.. 

Hello,

Are you talking about Active Directory?  Have you looked at Samba?

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/samba-pdc.html#id2562489

Samba can act as a domain controller, but if you are looking to get rid of 
Windows completely then you would also need to implement an LDAP system and 
migrate your AD accounts over to it.

    - Dave



Re: Suggestions for video/tv capture?

2009-09-29 Thread David Parker
- Original Message -
From: David Parker dpar...@utica.edu
Date: Tuesday, September 29, 2009 8:08 pm
Subject: Re: Suggestions for video/tv capture?
To: debian-user@lists.debian.org

 I have had great luck with my Hauppauge PVR-350 and PVR-150 cards, but they 
 are getting harder to find these days.  They use the ivtv drivers under 
 Linux, and the manufacturer's drivers under Windows work quite well.

     - Dave

 - Original Message -
 From: Dennis Wicks w...@mgssub.com
 Date: Tuesday, September 29, 2009 8:03 pm
 Subject: Suggestions for video/tv capture?
 To: debian-user@lists.debian.org

  Greetings;
  
  I have a lot of VHS tapes that I would like to put on CDs or 
  DVDs.
  
  Any suggestions for a decent capture card?
  
  I would prefer one that is O/S neutral so I can run it on 
  Deb or XP, but that isn't an absolute requirement.
  
  Grateful for any help!
  
  TIA!
  Dennis

And sorry everyone for top-posting!  It was an accident!

    - Dave



Re: Suggestions for video/tv capture?

2009-09-29 Thread David Parker
I have had great luck with my Hauppauge PVR-350 and PVR-150 cards, but they are 
getting harder to find these days.  They use the ivtv drivers under Linux, and 
the manufacturer's drivers under Windows work quite well.

    - Dave

- Original Message -
From: Dennis Wicks w...@mgssub.com
Date: Tuesday, September 29, 2009 8:03 pm
Subject: Suggestions for video/tv capture?
To: debian-user@lists.debian.org

 Greetings;
 
 I have a lot of VHS tapes that I would like to put on CDs or 
 DVDs.
 
 Any suggestions for a decent capture card?
 
 I would prefer one that is O/S neutral so I can run it on 
 Deb or XP, but that isn't an absolute requirement.
 
 Grateful for any help!
 
 TIA!
 Dennis
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
 with a subject of unsubscribe. Trouble? Contact 
 listmas...@lists.debian.org


Re: AMD64 in vmware

2009-03-16 Thread David Parker
 Thanks everyone for the reply. 
 
 On Mon, 16 Mar 2009 11:06:48 -0400, David A. Parker wrote:
 
  You are asking if you can run a 64bit VM guest on a 32bit host?
  
  Sorry. Can't do it. Even if you have a 64bit processor, if 
 you only
  have a 32bit host it won't work.
  
  
  I thought this was possible 
 
 Interesting, IIRC, launching AMD64 apps under chroot in i386 
 won't work, 
 is this still true? 


I don't think the chroot will work, but VMware will run a 64-bit guest on a 
32-bit host if your CPU has VT support.

  as long as the physical CPU has VT support
  enabled and the BIOS supports it as well.
 
 How can I tell? 
 
 $ grep -i vt /proc/cpuinfo || echo no
 no
 
 Does it means that my CPU has no VT support?
 

I'm not sure if there is a way to tell from the CPU flags in cpuinfo.  If you 
can reboot the machine, the VT option should be somewhere in the BIOS if it is 
supported.

    - Dave




Re: Forward System Messages to SSH

2009-03-09 Thread David Parker

 
 Now and then, messages are output to the tty display, such as 
 USB 
 devices being plugged in, etc.  Is there a way to have 
 those messages 
 sent to an SSH terminal?  I'm using OpenSSH.
 

I believe you can change where those messages go by editing your 
/etc/syslog.conf file, specifically these lines (found at the bottom):

daemon.*;mail.*;\
    news.err;\
    *.=debug;*.=info;\
    *.=notice;*.=warn   |/dev/xconsole

I have never tried redirecting those messages to an SSH terminal, though.  I 
think it would need to be bound to a named pipe in order for syslog to send 
messages to it.  Again, I've never tried it so I could be very wrong about that.

    - Dave




Re: tv/radio card

2009-01-17 Thread David Parker
     There are a lot of TV tuner cards that work 
 in Linux, either with native
     drivers or with drivers like ivtv.  I 
 have a Debian Etch box running
     MythTV with two TV tuner cards in it, a 
 Hauppauge PVR-350 and a Hauppauge
     PVR-150, both of which use the ivtv 
 drivers.  The PVR-350 supports MPEG
     encoding and decoding, so it can be used for 
 recording and playback.  It
     also comes with a remote control and IR 
 sensor which work very well using
     lirc, and it has an on-board FM tuner which 
 I have not personally used,
     but I believe does work under Linux.  
 The PVR-150 is only an encoder and
     can only be used for recording.  These 
 two cards are fairly old, though,
     and I'm sure there are better options out 
 there now.  I have read a lot of
 
 Would you have any reason not to buy a PVR-350 card? Since from 
 if I
 understand you correctly, it will both record and allow me to 
 watch tv?
 Is this a usb or a card you put in your motherboard? 
 

The PVR-350 and PVR-150 are both internal PCI cards.  In my experience, the 
PVR-350 works very well and would be a good choice if you need both recording 
and playback functionality.  The encoder and decoder on the card are separate, 
which means you can record one show and watch an already-recorded show at the 
same time.  With the PVR-150 in the box, I can simultaneously record two things 
and watch something else, which is really nice.
 
 I have been very happy with these cards, but they fell out of favor with the 
maintainers of MythTV a while ago because of the lack of vendor support for 
Linux.  My understanding is that the first few versions of MythTV explicitly 
supported and recommended these cards, but in later versions they ran into some 
glitches while implementing new features, and Hauppauge would not provide any 
support for the cards under Linux.  The ivtv drivers are generic drivers for 
the Conexant chipset used on the Hauppauge cards, so they aren't supported by 
the vendor.  Nvidia came out with a series of hardware encoding/decoding 
chipsets and also provided native Linux drivers and support for them, so the 
MythTV devs started recommending those instead.  I have only used the two 
Hauppauge cards, though, so I don't know much about the other options.

 Ok. If I got remote support working, would I be able to do most things
 just with the remote eg, change channel, adjust volume, and 
 enable recording?

Yes.  If you are using lirc, you can create a config file which maps the 
buttons on the remote to functions in the software you are using.  MythTV comes 
with a stock config for the Hauppauge remote, and I'm sure other such projects 
do as well.  Channel selection, volume control, playback functions (play, 
pause, fast-forward, rewind, stop) all work.

     The MythTV forums might be a good place to 
 look, since tuner cards are a
     big topic of discussion, and a lot of people 
 mention other TV and radio
     programs, too.
 
 Cool I'll take a look.
 
 Thanks very much for the reply,

No problem.

    - Dave



Re: tv/radio card

2009-01-16 Thread David Parker
 
 I'm wanting to buy a tv tuner for my computer, but before I do I 
 have a
 couple of questions:
 - Do internal tv cards or usb tv cards work best?
 - What models/brands are well supported?
 - Does Remote control support work?
 - Do any allow for reccording of tv?
 - Do any supported cards come with a built in fm radio tuner? If 
 so what
 card should I get.
 
 Finally, once my card is working, what programs should I use to 
 controlthe radio and tv? I found gnomeradio which seems to work 
 with orca (I am
 blind, so I need a program that is either gtk or command line based),
 but does anyone know of a program that could control the tv? 
 (that isn't
 qt based).
 
 Finally these cards will allow me to pick up standard tv like my 
 normaltv would won't it?
 
 Thanks for any info,
 
 Daniel
 

Hi,

There are a lot of TV tuner cards that work in Linux, either with native 
drivers or with drivers like ivtv.  I have a Debian Etch box running MythTV 
with two TV tuner cards in it, a Hauppauge PVR-350 and a Hauppauge PVR-150, 
both of which use the ivtv drivers.  The PVR-350 supports MPEG encoding and 
decoding, so it can be used for recording and playback.  It also comes with a 
remote control and IR sensor which work very well using lirc, and it has an 
on-board FM tuner which I have not personally used, but I believe does work 
under Linux.  The PVR-150 is only an encoder and can only be used for 
recording.  These two cards are fairly old, though, and I'm sure there are 
better options out there now.  I have read a lot of praise for Nvidia's TV 
tuner cards as well.

MythTV may not fit your needs as it is based on Qt, and that's all I have 
personally used with these tuner cards so I'm afraid I can't make any 
recommendations about software, but I'm sure there are several available.  The 
MythTV forums might be a good place to look, since tuner cards are a big topic 
of discussion, and a lot of people mention other TV and radio programs, too.

I hope this helps.

    - Dave




Re: error in script

2008-09-04 Thread David Parker
- Original Message -
From: David Parker [EMAIL PROTECTED]
Date: Thursday, September 4, 2008 10:30 pm
Subject: Re: error in script
To: L.V.Gandhi [EMAIL PROTECTED]
Cc: debian-user debian-user@lists.debian.org

 Try echoing the value of $i each time through the loop.  I wonder if the 
 exit 0 when $i = 0 is the problem.

Oops.  I meant to say when $i = 20.  Sorry.

    - Dave



Re: error in script

2008-09-04 Thread David Parker
- Original Message -
From: L.V.Gandhi [EMAIL PROTECTED]
Date: Thursday, September 4, 2008 9:50 pm
Subject: error in script
To: debian-user debian-user@lists.debian.org

 I have a script as follows
 #!/bin/bash
 rm -f ~/stock/flstock.csv
 grep FUTSTK ~/stock/today/$1 |grep 25/09/2008|cut -s -d, -f9|sort -nr  temp
 i=0
 for trv in $(cat temp)
 do
      grep $trv ~/stock/today/$1  ~/stock/flstock.csv
     i=$((i+1))
     if [ $i -eq 20 ]
     then 
     exit 0
     fi
 done    
 rm -f temp
 cat ~/stock/flstock.csv |cut -s -d, -f2|sort  ~/stock/fliquidstocks.txt
 
 Last line is not getting  executed . But if I run last line afterwards in 
 console, it works. Can someone throw somelight why it happens.

Try echoing the value of $i each time through the loop.  I wonder if the exit 
0 when $i = 0 is the problem.

    - Dave




Re: udev z25_persistent-net.rules problem

2008-07-26 Thread David Parker

 Thanks. The post that said this was fixed in the forcedeth 
 driver in
 testing, any idea what this file is called so I can download it 
 and get it
 installed?

 
The driver is part of the linux-image-2.6.25.2 kernel package.

    - Dave



Re: udev z25_persistent-net.rules problem

2008-07-25 Thread David Parker
- Original Message -
From: Account for Debian group mail [EMAIL PROTECTED]
Date: Friday, July 25, 2008 10:43 pm
Subject: udev z25_persistent-net.rules problem
To: debian-user@lists.debian.org
 
 The next time it boots up the machine does not recognize eth0
 and there is a eth1 added to the above file. If I change the
 /etc/network/interfaces file to eth1 and do a ifup -a there is the
 Internet.
 
 Each time the machine is booted up the number climbs eth1 eth2 
 eth3 ...
 etc.
 

Hi,

This is a problem with the forcedeth driver in etch.  See this post:

http://lists.debian.org/debian-user/2007/10/msg02402.html

I hope this helps.

    - Dave




Re: sound on ibm netvista

2008-06-10 Thread David Parker
 I bought a used IBM Netvista machine and alsaconf cannot find the
 on board sound card. I really need a lot of help.

You might need to compile a driver (I had to for my onboard Intel audio chipset 
in Etch).  The lspci command might yield some better information about what the 
sound hardware is.

Check out the alsa vendor/driver list and see if there's something that will 
work with your hardware:

http://www.alsa-project.org/main/index.php/Matrix:Main

I hope this helps.

- Dave


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Gigabyte M61P-S3 and wild MAC address of ethernet interface

2008-02-10 Thread David Parker

 Problem solved! :-D
 
 Thank you for your help.
 
 I am still wondering why this kind of problem is possible. Is 
 the 
 problem the hardware, the driver or the kernel? Or is it just 
 the 
 property that I am not aware of?
 
 
 Tero Mäntyvaara
 

Hello,

I have this exact same motherboard, and I experienced this same problem.  As I 
understand it (through several Google searches), the main cause of the problem 
is that the onboard Nvidia NIC is not supported correctly by the forcedeth 
driver in Etch.  Basically, the driver isn't able to correctly query the NIC 
for the MAC address.  Because it's not able to get a real MAC address from NIC, 
it assigns a random one instead, which causes some bizarre behavior.  The 
specific problem that I was having was that the device number of the NIC would 
change each time I rebooted (since the MAC address was different), so it was 
eth0, then eth1, then eth2, etc.

Another person also had problems with this NIC and the forcedeth driver.  That 
post is here:

http://lists.debian.org/debian-user/2007/10/msg02402.html

Hope this helps.

- Dave



Re: The previous nonsense

2007-05-21 Thread David Parker

 The computer, a Toshiba Satellite A30 with 1.2 gig ram and a 40 
 gig hard
  drive was originally dual boot MS-Debian 3.1.  Windows 
 quit.  Who knows
  why.
  Printer: HP officejet 4110 all-in-one  -  cupsys 
 installed and set up
  according to the information I found but still non-
 functional.  However, it
  will copy and send faxes.
 
 
 It will copy and send faxes from Debian, or from the all-in-
 one's control
 interface on the unit itself? (Printing is still way too hard, 
 in Linux,
 Windows, and Mac OS/X.)
 

Hmmm...  CUPS (cupsys) is installed, but are the drivers?  You could try 
installing them if they're not already (as root):

apt-get install foomatic-filters foomatic-filters-ppds hpijs 
linuxprinting.org-ppds

 
 Speaker is dead.  It does work using the live Kubuntu disc
 
 As someone mentioned, what's the output of lsmod and of groups?
 

Try something like:

lsmod | grep snd_

 
 , but before I screw with the hard disk there are some pictures 
 of my wife,
  who recently died,
 

I'm very sorry to hear that.  I'm curious, do you have a USB thumbdrive or some 
other media you could back thing up on?  USB support in Debian is pretty good 
these days, and if you run into problems, I'm sure we could help you out.

Sorry if this message is formatted or or wrapped funny.  The client I'm using 
right now does not handle replies very well.

    - Dave



Re: Getting Thunderbird to use Firebird as default browser

2006-04-16 Thread David Parker
<[EMAIL PROTECTED]> frans <[EMAIL PROTECTED]> wrote:   Also thanks: I discovered by your information that the command:ln -s /usr/bin/mozilla /etc/alternatives/gnome-www-browserworked fine!!!  The true Debian Way (tm) would be:  #update-alternatives --config gnome-www-browser  This will give you a list of possible browsers to choose from. I installed Firefox from the tarball and not the Debian package a few months ago, and was not able to use update-alternatives because it did not recognize Firefox as satisfying the gnome-www-browser requirements. In this case, I discovered you have to run gconf-editor and set the http and https handler to your Firefox binary manually. Then all was well.  - Dave 


Re: trouble getting my wireless stuff to work

2006-04-11 Thread David Parker
- Original Message -From: tom arnall <[EMAIL PROTECTED]>Date: Tuesday, April 11, 2006 6:02 pmSubject: trouble getting my wireless stuff to workTo: debian-user@lists.debian.org i am a linux newbie having trouble getting my wireless stuff to  work. i am  running debian on a toshiba satellite laptop. the wireless card  is a d-link  dwl-g650. i am looking for info on the latest debian methods for  dealing with  this technology.  thanks,  tom arnall north spit, ca   --  To UNSUBSCRIBE, email to [EMAIL PROTECTED]  with a subject of "unsubscribe". Trouble? Contact  [EMAIL PROTECTED]Hello,I had great luck just a few days ago with ndiswrapper and wpa_supplicant. I am now using a Linksys WPC54G wireless card with an old Acer laptop running Debian and it works just fine. You will likely need to compile both of them, but it was very easy to do and once they were compiled, the instructions on their respective pages were very easy to follow. ndiswrapper allows you to use the Windows driver for almost any device in Linux. wpa_supplicant allows you to define connections that use WPA.http://ndiswrapper.sourceforge.net/http://hostap.epitest.fi/wpa_supplicant/ Good Luck, Dave 


Re: A Question

2005-12-21 Thread David Parker
 When you boot up with the promise card in, does it show on your 
 screen 
 (the next page after it shows all your drives)?

This is one of the weirder parts of the problem.  The Promise BIOS comes
up after the POST, but it says no drives are detected.  However, when
Debian booted, the drive was then found as hde (as it should be) and
this would be follwed by a whole bunch of CRC check failures.  The fact
that Debian found the drive and assigned it to a device, and usually
even mounted it, tells me that the card must be working.  It doesn't
explain why the card's BIOS says there is no drive attached, though. 
I'm going to hook the machine back up tonight, and I'll be able to post
the actual errors tomorrow.  These CRC check errors continued to spew
out into /var/messages several times per minute while the box was
running, even with the drive mounted and working fine.
  
 What about the BIOS? On the page where it gives your boot options, 
 do 
 you have 'SCSI listed?

SCSI isn't an option in the BIOS for this box.  It's an old Dell
Optiplex GX1, completey IDE-based, and the only options for a boot
device are PXE (Network), CD, HDD, and floppy.

 I don't mean to offend you with these 
 stupid 
 questions if you already know this stuff! g

No offense taken!  If you don't start with the basics, you'll never find
the cause of a problem.  This is all stuff I should have mentioned
before, anyway.

Also, I got your e-mail with the links, and they were helpful.  It looks
like most people are using this card with sarge just fine, which makes
me wonder about mine.  I would like to know the name of that driver if
you have it, though.

Thanks for all the help.

- Dave



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]