LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 07-11-2013, 06:43 AM   #1
dlc
LQ Newbie
 
Registered: Oct 2004
Location: Gaithersburg, MD, USA
Distribution: Debian Sid, Linux Mint XFCE, RHEL
Posts: 5

Rep: Reputation: 0
scp broken, root now copies to /dev/null on Sid and Mint XFCE 15


BTW, I am not a Linux newbie (Linux Counter number 2419) but this is my first post on this site, so this seems to be the place I am expected to post it.

I use Debian Sid and Linux Mint XFCE. Several months ago I noticed scp transfers as root stopped always working. They sometimes appear to transfer with expected transfer statistics reported using -v, but the files and directories do not actually get incorporated into the receiving host's filesys. Between Sid, Mint XFCE 14, and Mint XFCE 15 (RC), it only works when the scp is invoked from Mint XFCE 14, regardless of transfer direction. I am finally attempting to get to the bottom of this, expecting to find a new config item or a changed default value somewhere, but so far it's not obvious. I guess it's worth a question here before I start using diff on the config files.
 
Old 07-11-2013, 02:26 PM   #2
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: CentOS 6 (pre-systemd)
Posts: 2,610

Rep: Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702
What is the exact command that is not doing what you expect?
 
Old 07-11-2013, 03:36 PM   #3
dlc
LQ Newbie
 
Registered: Oct 2004
Location: Gaithersburg, MD, USA
Distribution: Debian Sid, Linux Mint XFCE, RHEL
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by smallpond View Post
What is the exact command that is not doing what you expect?
Thanks for your inquiry.

scp -vp mint14:file14 . fails on mint15 as root in /root
scp -vp file14 mint15: works on mint14 as root in /root

Both report appropriate transfer stats, but only the second causes file14 to appear in root's home directory on mint15. Remote host passwords are solicited by both commands.
 
Old 07-11-2013, 04:57 PM   #4
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: CentOS 6 (pre-systemd)
Posts: 2,610

Rep: Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702Reputation: 702
Does it work if you use full pathnames and hostnames instead of abbreviating?
Like: mint14.example.com instead of mint14, and /root/file14 instead of file14.

To be pedantic, I should also say to use /usr/bin/scp instead of scp.
All of those are depending on other programs to resolve the full names some of which are likely not configured correctly.
 
Old 07-12-2013, 09:33 AM   #5
dlc
LQ Newbie
 
Registered: Oct 2004
Location: Gaithersburg, MD, USA
Distribution: Debian Sid, Linux Mint XFCE, RHEL
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by smallpond View Post
Does it work if you use full pathnames and hostnames instead of abbreviating?
None of those changes make any difference, including using dotted-decimal addresses instead of DNS addresses. I am appending two sanitized session logs to provide full details of this issue. The mint14 session successfully transfered xyzzy15 from mint15 as xyzzyDDIPV4. The mint15 session then tried to transfer xyzzyDDIPV4 back from mint14 to mint15.


#------------------------------------------------------------------
root@mint14~ # dig mint14.home

; <<>> DiG 9.8.1-P1 <<>> mint14.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50719
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mint14.home. IN A

;; ANSWER SECTION:
mint14.home. 3600 IN A 10.11.12.18
mint14.home. 3600 IN A 10.11.12.19

;; Query time: 5 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Jul 12 08:46:39 2013
;; MSG SIZE rcvd: 61

root@mint14~ # dig mint15.home

; <<>> DiG 9.8.1-P1 <<>> mint15.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52972
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mint15.home. IN A

;; ANSWER SECTION:
mint15.home. 3600 IN A 10.11.12.90
mint15.home. 3600 IN A 10.11.12.91

;; Query time: 5 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Jul 12 08:49:31 2013
;; MSG SIZE rcvd: 93

root@mint14~ # pwd
/root
root@mint14~ # /bin/ls -laht xyzzy*
-rw-r--r-- 1 root root 6 Jul 11 06:30 xyzzy15
-rw-r--r-- 1 root root 6 Jul 11 05:41 xyzzy14
root@mint14~ # /usr/bin/scp -pv 10.11.12.90:/root/xyzzy15 /root/xyzzyDDIPV4
Executing: program /usr/bin/ssh host 10.11.12.90, user (unspecified), command scp -v -p -f /root/xyzzy15
OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.11.12.90 [10.11.12.90] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1p1 Debian-4
debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 15:15:15:15:15:15:15:15:15:15:15:15:15:15:15:15
debug1: Host '10.11.12.90' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:9
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@10.11.12.90's password:
debug1: Authentication succeeded (password).
Authenticated to 10.11.12.90 ([10.11.12.90]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/xyzzy15
File mtime 1373538613 atime 1373538902
Sending file timestamps: T1373538613 0 1373538902 0
Sink: T1373538613 0 1373538902 0
Sending file modes: C0644 6 xyzzy15
Sink: C0644 6 xyzzy15
xyzzy15 100% 6 0.0KB/s 00:00
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2024, received 1848 bytes, in 0.1 seconds
Bytes per second: sent 28817.9, received 26312.0
debug1: Exit status 0
root@mint14~ # /bin/ls -laht xyzzy*
-rw-r--r-- 1 root root 6 Jul 11 06:30 xyzzy15
-rw-r--r-- 1 root root 6 Jul 11 06:30 xyzzyDDIPV4
-rw-r--r-- 1 root root 6 Jul 11 05:41 xyzzy14
root@mint14~ #
#------------------------------------------------------------------
root@mint15[PN]~ # pwd
/root
root@mint15[PN]~ # /bin/ls -laht xyzzy*
-rw-r--r-- 1 root root 6 Jul 11 06:30 xyzzy15
-rw-r--r-- 1 root root 6 Jul 11 05:41 xyzzy14
root@mint15[PN]~ # /usr/bin/scp -pv 10.11.12.18:/root/xyzzyDDIPV4 /root/xyzzyDDIPV4
Executing: program /usr/bin/ssh host 10.11.12.18, user (unspecified), command scp -v -p -f /root/xyzzyDDIPV4
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.11.12.18 [10.11.12.188] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 14:14:14:14:14:14:14:14:14:14:14:14:14:14:14:14
debug1: Host '10.11.12.18' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@10.11.12.188's password:
debug1: Authentication succeeded (password).
Authenticated to 10.11.12.18 ([10.11.12.18]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/xyzzyDDIPV4
setterm: $TERM is not defined.
Sink: Sourcing /com/.bash_root...
Sourcing /com/.bash_root...
root@mint15[PN]~ # debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1984, received 1776 bytes, in 0.1 seconds
Bytes per second: sent 20367.5, received 18232.2
debug1: Exit status -1
root@mint15[PN]~ # /bin/ls -laht xyzzy*
-rw-r--r-- 1 root root 6 Jul 11 06:30 xyzzy15
-rw-r--r-- 1 root root 6 Jul 11 05:41 xyzzy14
root@mint15[PN]~ #
#------------------------------------------------------------------

Last edited by dlc; 07-12-2013 at 09:59 AM.
 
Old 07-12-2013, 11:11 AM   #6
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,404

Rep: Reputation: Disabled
I was about to suggest running lsof on the target system during transfer to see where the data ends up, but then I noticed this from the successful session:

Quote:
Originally Posted by dlc View Post
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/xyzzy15
File mtime 1373538613 atime 1373538902
Sending file timestamps: T1373538613 0 1373538902 0
Sink: T1373538613 0 1373538902 0
Sending file modes: C0644 6 xyzzy15
Sink: C0644 6 xyzzy15
xyzzy15 100% 6 0.0KB/s 00:00
...compared to this from the session that failed:

Quote:
Originally Posted by dlc View Post
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/xyzzyDDIPV4
setterm: $TERM is not defined.
Sink: Sourcing /com/.bash_root...
Sourcing /com/.bash_root...
It looks like the remote scp session never actually runs. You should be able to confirm that by attempting to copy a large file; the session should "complete" almost immediately.

This could be a configuration issue or even a profile issue, but I'd check and compare the sshd/scp versions on all systems just to rule out bugs.

Last edited by Ser Olmy; 07-12-2013 at 11:13 AM.
 
1 members found this post helpful.
Old 07-12-2013, 07:31 PM   #7
dlc
LQ Newbie
 
Registered: Oct 2004
Location: Gaithersburg, MD, USA
Distribution: Debian Sid, Linux Mint XFCE, RHEL
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by Ser Olmy View Post
It looks like the remote scp session never actually runs. You should be able to confirm that by attempting to copy a large file; the session should "complete" almost immediately.

This could be a configuration issue or even a profile issue, but I'd check and compare the sshd/scp versions on all systems just to rule out bugs.
They do report themselves to be the same version as I'd expect since I keep mint14 current and 15rc should be the current release within 24 hours. I decided to simply rename .profile to .profile.disable and .bashrc to .bashrc.disable and try another scp. Then I thought to list the remote directory first. The result is puzzling [figured it out--the globbing happens in the local directory before the scp executable is invoked]:

root@mint15[PN]~ # ssh mint14.home /bin/ls -FaCd .*
root@mint14.home's password:
/bin/ls: cannot access .bashrc: No such file or directory
/bin/ls: cannot access .config: No such file or directory
/bin/ls: cannot access .profile: No such file or directory
./ ../ .aptitude/ .bash_history .cache/ .dbus/ .ssh/ .synaptic/
root@mint15[PN]~ #


So I popped over to mint14:

root@mint15[PN]~ # ssh root@mint14.home
root@mint14.home's password:
Welcome to Linux Mint 14 Nadia (GNU/Linux 3.5.0-23-generic x86_64)

Welcome to Linux Mint
* Documentation: http://www.linuxmint.com
Last login: Fri Mar 15 09:37:38 2013
mint14 ~ # /bin/ls -FaCd .* 2>&1 | tee ls.log
./ .bash_history .dbus/ .profile.disable .ssh/
../ .bashrc.disable .gconf/ .pulse/ .synaptic/
.aptitude/ .cache/ .mateconf/ .pulse-cookie .viminfo
mint14 ~ # /bin/ls -l ls.log
-rw-r--r-- 1 root root 175 Jul 12 18:25 ls.log
mint14 ~ #


Then returned to mint15 for the actual test:

root@mint15[PN]~ # /usr/bin/scp -pv mint14.home:/root/ls.log /root/ls.log
Executing: program /usr/bin/ssh host mint14.home, user (unspecified), command scp -v -p -f /root/ls.log
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to mint14.home [10.11.12.18] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 14:14:14:14:14:14:14:14:14:14:14:14:14:14:14:14
debug1: Host 'mint14.home' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password
root@mint14.home's password:
debug1: Authentication succeeded (password).
Authenticated to mint14.home ([10.11.12.18]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -p -f /root/ls.log
File mtime 1373667935 atime 1373668489
Sending file timestamps: T1373667935 0 1373668489 0
Sink: T1373667935 0 1373668489 0
Sending file modes: C0644 175 ls.log
Sink: C0644 175 ls.log
ls.log 100% 175 0.2KB/s 00:00
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1952, received 2096 bytes, in 0.1 seconds
Bytes per second: sent 25854.6, received 27761.9
debug1: Exit status 0
root@mint15[PN]~ # /bin/ls -l ls.log
-rw-r--r-- 1 root root 175 Jul 12 18:25 ls.log
root@dlc-pl[PN]~ #


So mint15 actually performed the transfer! But what has changed in Debian Sid and Mint XFCE 15 that causes those local profile commands to break the transferring since they (still) cause no problem for the Mint XFCE 14 scp command environment? I need to experiment further with .profile and .bashrc invocation enviromental differences. The bash versions are slightly different:
mint14: GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
mint15: GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu)

I really appreciate this assistance--my brain has not been at 100% efficiency the last few days.

Last edited by dlc; 07-12-2013 at 08:57 PM.
 
Old 07-13-2013, 02:31 AM   #8
dlc
LQ Newbie
 
Registered: Oct 2004
Location: Gaithersburg, MD, USA
Distribution: Debian Sid, Linux Mint XFCE, RHEL
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by dlc View Post
So mint15 actually performed the transfer! But what has changed in Debian Sid and Mint XFCE 15 that causes those local profile commands to break the transferring since they (still) cause no problem for the Mint XFCE 14 scp command environment? I need to experiment further with .profile and .bashrc invocation enviromental differences.
I found out ssh causes .profile to be invoked but scp invokes .bashrc. But it took a bit of testing insertng tracing echo commands and set -xv commands until I finally hit upon the apparent restriction of the newer scp/bash that it won't tolerate many terminal stdout characters during the .bashrc processing before it decides to quietly shut it down. Once I redirected all echo command stdouts to a file, the new scp/bash is accomodating of the requests.

So, bug or feature? And thanks again for all assistance.

[However, further testing shows problems occur with non-root users transfering in/out of the implicit (remote scp's working) directory, as though it is not being set to the user's home directory. [Issue resolved: the non-root user's local .bashrc processing was resetting the working directory, so the old scp/bash was clearly not processing .bashrc]]

Last edited by dlc; 07-13-2013 at 03:36 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Why is there a need for /dev/null, /dev/zero and other special device (files) in /dev suttiwit Linux - General 13 08-07-2012 01:26 AM
Can't Log in to Desktop, root Can't Access My Files Mint 9 XFCE Trentixero Linux - Newbie 11 03-11-2011 04:49 PM
[SOLVED] scp -r copies files repeatedly MorayJ Linux - Software 2 07-30-2009 06:26 PM
What is meant by " file > /dev/null 2>&1 </dev/null " attockonian Linux - Newbie 5 06-30-2006 11:51 PM
Two Copies Of XFCE Starting? douceur Linux - Software 1 06-19-2005 02:05 PM


All times are GMT -5. The time now is 12:23 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration