Re: [OT] Will upcoming Debian 8 release default to XFCE for the CD media?

2012-08-09 Thread Laurence Hurst

On 09/08/2012 16:50, Darac Marjal wrote:

Fair point. However, comparing[3] popcon results for xfce4-session[1] and
gnome-session[2], less than 4% of debian users use[4] xfce, compared to a
little over 16% who use gnome.

Hmm. My numbers seem a little suspect there. Is a graphical session
REALLY used by such a small majority of the userbase?



You seem to be suggesting that xfce4-session and gnome-session are the 
only desktop environments - I, for example, use pekwm at the moment (and 
openbox before that) so will not be in either that 20% (assuming no 
overlap, which is probably wrong).


Looking at xserver-xorg[0], the most popular X server at the moment, it 
is installed on 52% of systems partaking in the popularity contest.  I 
suspect this is a reasonable reflection on the number of graphical 
installs in popcon as a lot of production headless servers will probably 
not be reporting stats (whereas my headless boxes at home, which do not 
have an X server installed, do).  Because of this I expect the real 
number of graphical desktop (compared to non-desktop installs) is less 
than 52%.


 [0] http://qa.debian.org/popcon.php?package=xorg

Just my .2

Laurence


--
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/5023de3f.5020...@lboro.ac.uk



USB ports not working after device disconnect

2012-08-08 Thread Laurence Hurst

Hi folks,

Occasionally, when I disconnect a device (usually a mass storage device) 
from my laptop (Lenovo Thinkpad x201), the USB ports stop recognising 
devices when I plug them in until I reboot.  The ports are still powered 
and will charge e.g. a phone if I plug one in but nothing at all is 
registered by dmesg or logged in /var/log/messages.


Last time this happened lsusb showed a 'linux root hub' and an 'Intel 
rate matching hub' and nothing else.  I've rebooted the machine and then 
had two of each of these (there was only 1 before) along with the 
inbuilt fingerprint reader and a device just described as Lenovo, 
which suggests to me Debian is somehow losing one of the root hubs.


Before I rebooted it last time, I tried removing and reprobing the usb 
modules (i.e. usbcore and anything which depend on it) but this made no 
difference.


Anyone any idea why this might be happening, or what I can do to try and 
fix it?


Thanks
Laurence


--
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/50224cba.9020...@lboro.ac.uk



Re: USB ports not working after device disconnect

2012-08-08 Thread Laurence Hurst

On 08/08/2012 15:51, Camaleón wrote:


Weird. Check if there's a BIOS update, just in case.



I didn't think of that (d'oh!). There is a newer BIOS (more than one, 
actually) on Lenovo's website for my machine.  I will have a go at 
installing the latest one and see if it helps.




Kernel does not usually lose USB hubs, it only shows what is there and
presents nothing when either a) a hardware problem arises or b) a bug is
hitting you :-)



Absolutely, the problem is figuring out which one...


So, to discard a kernel problem you can try by loading a different kernel
release (better an updated version). This can be easily done from a
LiveCD (nothing to install) or getting a new kernel version (from the
backports or compiling yourself from sources).



I am running a kernel from backports, as I had wireless driver issues 
with the stock one, but I am fairly sure I was having this problem 
before.  Unfortunately the problem is intermittent - sometimes I can 
unplug/plug devices without a problem and sometimes the ports stop 
working.  This is going to make it very hard to tell if the problem has 
gone away permanently or it's just hibernating for a while.




Mmm... I was going to suggest precisely that (i.e., modprobe -r usbcore
modporbe usbcore).



Sorry to have beaten you to it!


What Debian flavour are you running?



Stable (6.0.5) on amd64 (the laptop's a Core i5) with iceweasel and 
linux-image from backports (only those 2 packages, and their required 
dependencies)




Problems with USB ports usually come from power issues (a damaged USB
controller which cannot provide 5V to the ports can cause devices
attached to it that require more power are not properly detected or
experience random disconnects). You can run the usual tests: try with
different devices other than mass storage, replace the USB cable (if
any), attach the device to a different port, etc...



Hmm, given this is a laptop I suppose a power problem is a strong 
possibility.  This usually happens with my iPod and/or USB cd drive so I 
would not be surprised if they were trying to draw more current than the 
USB port (and specs!) can provided.  Perhaps I need to try using a 
(powered) hub for a while and see if that stops it happening.



Greetings,



Thanks for your input,
Laurence


--
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/50228539.8030...@lboro.ac.uk



Re: how to open ssh tunnel port ?

2012-06-27 Thread Laurence Hurst

On 27/06/2012 15:37, J. Bakshi wrote:


Dear list,

I have made a successful ssh tunnel between two pcs A and B.
A is running mysql and B have the tunnel with A , so that B
can access that remote mysql with its local port 3360. Everything
is fine..

But B is bind the port with localhost only, hence no one can access
B's 3360 port. How can B open the port so that others can also
use the 3360 port on B which is actually tunneled with A ?

A running mysql  --tunnel-B localhost:3360
butc  can't see 3360 onB

Thanks




Hi,

Your current ssh command (assuming you are connection from B to A) 
presumably looks something like:


ssh -L 3360:localhost:3306 A

According to the ssh man page (try running man ssh and read the bit 
about the '-L' argument), you can specify the bind address as part of 
that argument. Basically you should end up with something like this:


ssh -L 192.168.0.1:3360:localhost:3306 A

where '192.168.0.1' is the ip address you want to bind to (i.e. the ip 
address of eth0, or whichever interface you want to use). The same 
method applies if you are using -R to create the tunnel the other way - 
again read the manual page, it's there to help you!


I would think carefully about whether you really want to do this, as you 
will be exposing the mysql server to anyone who can connect to machine B 
on port 3360. Security is one of the main motivators for binding only to 
localhost by default (by both mysql and ssh).


Regards,
Laurence


--
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/4feb1f01.5090...@lboro.ac.uk



Re: the ghost of UEFI and Micr0$0ft

2012-06-06 Thread Laurence Hurst

On 06/06/2012 11:47, Tom H wrote:


Nowhere is the proposed Fedora 99-dollar-key being offered to other
distributions. Since it only costs USD 99 it wouldn't make sense for
Debian, for example, not to get its own rather than use Fedora's. And
Fedora wouldn't want to take the risk of loaning its key to Debian,
having the latter screwing up, and having Fedora's key being
blacklisted.



Fedora have also signed the entire chain from their shim bootloader 
(with the 99USD key), grub, kernel and kernel modules (latter 3 with 
Fedora's own key/chain-of-trust). Even if they were willing to take the 
risk of sharing, I don't think they would with anyone who wasn't willing 
to sign their own entire boot-chain down to the kernel module level. I 
think it would be very bad for the principals of free (as in freedom) 
software if Debian went down the same route creating a walled-garden for 
the entire boot chain through to the kernel modules on secure-boot 
enabled systems.


Could the hardware manufactures not have provided a method to allow OS 
installers (as in installation programs) to add their own keys via an 
UEFI level call which results in a prompt at next boot saying A new key 
has been added (fingerprint: $key_fingerprint). Do you want to trust it 
(Yes/No)?? It wouldn't solve the potential risk for users who just say 
yes to everything, but for anyone with a little clue it provides 
protection and is not as anti-competitive as the current situation 
appears to be.


Laurence


--
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/4fcf4386.2000...@lboro.ac.uk



Re: the ghost of UEFI and Micr0$0ft

2012-06-06 Thread Laurence Hurst

On 06/06/2012 14:56, Jon Dowland wrote:

and it'd require resources to manage and maintain, something better suited to
a commercial enterprise.


That's the big deal. Fedora seem to believe they can manage maintaining closed
and signed bootloaders, kernel and kernel modules.  That would be very difficult
to achieve in Debian.



I can see this turning into a support nightmare for Fedora when, 
inevitably, some hardware or firmware comes along which (at least as an 
interim measure until official fixes are released) requires the use of 
a newer kernel and/or module, or a patch/rebuild of an existing one.


I wonder how they will cope with the likes of nvidia/ati/intel who 
release their own kernel modules and installers outside of the 
distribution ecosystem, which will presumably be unsigned and a lot of 
people seem to use for the [potential/perceived] performance benefits.



A more interesting approach might be to maintained a locked-down install image
chain which offered, as a very early installer option, to disable the secure
boot BIOS setting on your behalf.  From then onwards you could run whatever you
like.  Whether or not that will be generally possible, I don't know.




I doubt there will be an easy way to disable the secure boot BIOS 
setting on the users' behalf, even from a signed boot loader, as that 
would just lead to malware finding a way to silently disable it to get 
around it.


Laurence


--
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/4fcf6bcd.9050...@lboro.ac.uk



Re: Could rsync do something like robocopy does?

2012-01-16 Thread Laurence Hurst
On Mon, Jan 16, 2012 at 11:43:44AM +, TCP wrote:
 robocopy C:\CDs D:\Covers cover.jpg /s
 
 This copy all avatar.jpg under C:\CDs to D:\Covers with respective
 directory name.
 
 
 Regards,
 Penguin
 

Penguin,

I believe something like this might do what you describe (note this is 
untested!):
rsync --recursive --prune-empty-dirs --include '*/' --include cover.jpg 
--exclude '*' C:\CDs D:\Covers 

The rsync man page has a whole section on filter rules (`man rsync`) which you 
can read yourself for more insight into its capabilities.

Kind Regards,
Laurence



-- 
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/20120116120611.gd10...@fk-176.lut.ac.uk



Re: Could rsync do something like robocopy does?

2012-01-16 Thread Laurence Hurst
On Mon, Jan 16, 2012 at 12:19:27PM +, TCP wrote:
 Thanks, this works perfectly what I want.
 btw, what does the --include '*/' does?

According to the man page the --include '*/' includes all the directories, 
without which it won't actually look in any directories (even though it's 
recursive) because they'll be blocked by the --exclude '*'.

 Wouldn't --exclude '*' exclude all files even the cover.jpg?
 

I think it processes the options in order, left to right, and stops at the 
first match (like I said, it is untested so I stand to be corrected). So, with 
the options I suggested rsync should, I think, use the following logic: Is it a 
file matching the pattern '*/'? (i.e. a directory. If yes - include) If not, 
is it a file matching the pattern 'cover.jpg'? (If yes - include) If not, is 
it a file matching the pattern '*'? (i.e. anything at all! If yes - exclude).

This is why I needed to add the --prune-empty-dirs option, as the --include 
'*/' will make it copy all the directories, even if there are not files called 
'cover.jpg' in them, and --prune-empty-dirs tells it not to bother copying 
directories which would be empty.

Hope this helps,
Laurence


-- 
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/20120116122950.ge10...@fk-176.lut.ac.uk



Re: IPv6 and DNS

2011-07-13 Thread Laurence Hurst
On Wed, Jul 13, 2011 at 12:09:45PM +0100, Scott Ferguson wrote:
 On 13/07/11 02:30, Laurence Hurst wrote:
  On Tue, Jul 12, 2011 at 04:09:27PM +0100, Scott Ferguson wrote:
  Why not just use a single host file on your firewall/router? 
  snipped
^^^
  I addition I need forward and reverse host-name lookups to function 
  correctly across a variety of platforms which is easily achieved by 
  running my own internal DNS with little more effort than a static 
  hosts file which I then have to copy around a dozen machines (and 
  spend time wondering why stuff broke when I forget one!).
  
 
 Just brush up on your reading skills and that problem will vanish. ;-p
 
Ah, yes I did misread what you were suggesting. For my current setup my way 
works for me, your way works for you. My setup at home is also very similar to 
that of a number of companies I work for, which is handy for experimentation 
(say, look at how IPv6 might integrate with and eventually replace the IPv4 
infrastructure) ;-)
 I can think of a number of large networks that don't run internal DNS
 servers - dynamic addresses are a pain to manage on a large scale, and
 static addresses make DNS servers redundant on most private networks.
 But them my motivation is not to increase the workload for the network
 monkeys (I mean - valued, value-adding staff) :-D
 
I'm still going to disagree with you on this point - user's expect to be able 
to plug in a machine and it just work without faffing around with setting 
IP/Subnet/Gateway/DNS/local domain settings (or getting the network monkeys 
to do it for them). I also worked for a company which had static addresses and 
the amount of time changing the settings on every single network connected 
device on the 2 occasions we had to change the router and/or DNS settings was 
measured in days - had we been using DHCP it would have been a 30s change to 
the config at the end of the day and the clients would most likely all be 
working next morning having renewed their leases and got the updated 
configuration at the same time. At lot of this depends on your (and mine!) 
users and environment.

I think, from what I've read, this goes away with IPv6 whereby even if I 
statically configure the interfaces address it will still use the 
route-discovery to find the router and DNS server so infrastructure changes 
are picked up automatically (after a period of time) without the need to change 
every connected hosts settings (as was the case with a static IPv4 setup).
snip / 
 
  
  Pretty much the same as the example above - just substitute an
  IPv6 address. Debian is just waiting for you to feed it IPv6, ditto
  for Windows 7, not so much for OSX, dunno about your embedded
  devices.
  
  From what I've read the auto-configured address is NOT guaranteed 
  to be identical each time a machine is connected to the network 
  (e.g. turned on after being powered off for a period of time), just
  unique to the network at the time it is configured. While in 
  practice IF the mac address of the NIC is used to generate the IPv6
  address it may be the same,
 
 A static address assigned by MAC is the same process whether by IPv4,5,
 or 6.
 Dynamic addressing is randomising.
I think we're talking at cross purposes here. I am specifically referring to 
stateless auto-configuration which the current most common convention, for 
IPv6, is to use the MAC address for the but this is not guaranteed and I have 
specific references to other methods being used whereby a given NIC does not 
always auto-configure to the same address each time it is connected to the same 
network.
 
  the RFC[0] simply states it will be generated from an interface 
  identifier and makes specific reference to instances where the 
  identifier is not a hardware address which means that although 
  current convention seems to be to use the MAC address this is not 
  guaranteed. If the addresses are not guaranteed to be static 
  between connections to the network then surely a local static DNS 
  (or, indeed, hosts file) cannot guarantee to be reliable?
  [0] http://tools.ietf.org/html/rfc4862
 
 I believe you've misinterpreted the context their. None of your concerns
 were validated by the trials I looked at during IPv6 day where very
 large WANs ran native IPv6 - but then those networks don't allow dynamic
 addresses (or bluetooth, or wireless). Again - I'd encourage you to read
 the internode guides I linked rather than just one of over a dozen RFCs,
 which only cover the basics.
 
Again I think we're talking cross purposes. My interest is purely in how IPv6 
will operate within a private network. Assuming my ISP allocated me a range of 
addresses how I go about managing that range within the networks which exist in 
my house (or an organisation). In terms of a smallish network I'm repeatedly 
being told that stateless auto-configuration makes DHCP redundant (which it 
clearly does as far

IPv6 and DNS

2011-07-12 Thread Laurence Hurst
Hi folks,

I notice a couple of other IPv6 related questions on this list so I hope this 
isn't too far of topic...

I currently have an IPv4-only network (192.168.0.0/24 behind a NAT 
firewall/router) at home which includes a variety of systems (Windows, Debian, 
OSX and some embedded devices). All of these devices support IPv4 DHCP so the 
least painful and most reliable method of configuring them with hostnames has 
been to run my own DHCP server and DNS with static mappings for most of the 
devices (I do not allow dynamic updating of the DNS) including reverse DNS.

I am curious, if I wanted to translate my IPv4 configuration into an IPv6 world;
  * I know there's a lot of talk about IPv6's wonderful auto-configuration 
eliminating the need for DHCP but how does this work with a static DNS setup?
  * Would I need to use DHCP6 and DNS, or auto-configuration and allow dynamic 
DNS updating (assuming IPv6's router discovery allows the clients to discover 
and update the DNS themselves)?
  * Would I have to trust the clients to update their own DNS records (I don't 
at the moment)?
  * In the DHCP-less world, how would clients discover the local DNS suffix 
(e.g. (fictitous) internal.home.my.tld)?

As I'm sure you can see I've got a whole load of questions and no compelling 
answers so I hope that some of the well informed folks on this list might be 
willing to point me in something approximating the right direction!

Cheers,
Laurence


-- 
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/20110712105439.ga68...@diss-84-211.lut.ac.uk



Re: IPv6 and DNS

2011-07-12 Thread Laurence Hurst
On Tue, Jul 12, 2011 at 04:09:27PM +0100, Scott Ferguson wrote:
 Why not just use a single host file on your firewall/router?  DHCP
 always seems like overkill for equipment you own.
 eg. reserve static addresses 192.168.0.2-10 for your machines,
 192.168.10-20 for people who regularly bring machines onto your network
 (LAN parties, your mums computer when it needs fixing etc) and use DHCP
 for 192.168.0.30-40 for irregularly connected machines.
 
 I'm simplifying - you probably have at least a Green zone, which would
 we setup up similar to the above example, and an Orange for webserver/s
 - where you definitely want static addresses eg 192.168.1.2-10, and a
 Blue zone for wireless devices eg 192.168.2.2-10, with maybe
 192.168.2.11-20 as dynamic.
 Your router/firewall would then be 192.168.0.1 for the Green gateway,
 192.168.1.1 for the Orange, and 192.168.2.1 for the Blue.
 
 Your name resolution would be fast, the load on your DHCP server
 minimal, and pinholes and portforwarding would be simple and easy to
 maintain.
 
That as may be, my current setup works very well for me and to date has been 
reliable. I addition I need forward and reverse host-name lookups to function 
correctly across a variety of platforms which is easily achieved by running my 
own internal DNS with little more effort than a static hosts file which I then 
have to copy around a dozen machines (and spend time wondering why stuff broke 
when I forget one!).
 
 
  I am curious, if I wanted to translate my IPv4
  configuration into an IPv6 world;
  � * I know there's a lot of talk about IPv6's
  wonderful auto-configuration eliminating the need for DHCP
  but how does this work with a static DNS setup?
 
 Pretty much the same as the example above - just substitute an IPv6
 address. Debian is just waiting for you to feed it IPv6, ditto for
 Windows 7, not so much for OSX, dunno about your embedded devices.
 
From what I've read the auto-configured address is NOT guaranteed to be 
identical each time a machine is connected to the network (e.g. turned on 
after being powered off for a period of time), just unique to the network at 
the time it is configured. While in practice IF the mac address of the NIC is 
used to generate the IPv6 address it may be the same, the RFC[0] simply states 
it will be generated from an interface identifier and makes specific 
reference to instances where the identifier is not a hardware address which 
means that although current convention seems to be to use the MAC address this 
is not guaranteed. If the addresses are not guaranteed to be static between 
connections to the network then surely a local static DNS (or, indeed, hosts 
file) cannot guarantee to be reliable?
  [0] http://tools.ietf.org/html/rfc4862

snip /
  � * In the DHCP-less world, how would clients
  discover the local DNS suffix (e.g. (fictitous)
  internal.home.my.tld)?
 
 It will depend on what methods your ISP provides
 
I'm talking about DNS which exists entirely within my private network and has 
nothing to do with my isp. Currently my DHCP server hands out my DNS server's 
details and the search domain (for the sake of argument 'internal.home.my.tld). 
The configured clients then use my DNS for all their DNS lookups - my server is 
configured to be authoritative for hosts on my network, within my subdomain 
('internal.home.my.tld') and for reverse lookups on 192.168.0.0/24 addresses 
(and on it's other subnets, but let's not over-complicate here) and forwards 
any other request upstream to my ISPs DNS servers. It's the DNS bit contained 
in my network that I'm unclear on.
 But it's really too early to determine what can be done with what the
 ISPs will provide, until the ISPs provide it.
 
 For some current real world implementations try:-
 http://ipv6.internode.on.net/configuration/
 http://ipv6.internode.on.net/access/tunnel-broker/
 
 NOTE: your region and ISPs may offer different implementations, I don't
 know how relevant the examples of Internode are as I've only compared
 them to iiNet's offerings. As discussed in another thread the big ISPs
 in my country have no plans for IPv6 in the forseeable future. As in $43
 billion for a National Broadband network that doesn't support IPv6 :-(
 
snip / 
 
 Fortunately neither of you have got to worry about that for a while :-)
 When the majority of sites and ISPs move to IPv6 it'll be dual-stacks
 and tunnels for some time - maybe not out of respect for your investment
 in dial-up modems but there's a lot of big ticket telco equipment (and
 other gear) owned by influential companies that won't natively support IPv6.
 I'd hesitantly suggest not buying IPv6 equipment until it's absolutely
 necessary - both for price and feature reasons.
Indeed, I think a lot of this is still to be figured out (there maybe a spec 
but how the large corporations choose to interpret it may have knock on 
impact for the rest of us). I am more interested from an experimental point of 
view. I am only 

Re: Keeping stable stable.

2011-06-02 Thread Laurence Hurst
On Thu, Jun 02, 2011 at 12:07:40AM +0100, R. Clayton wrote:
 I'm running squeeze on a system, and I'd like to keep the system on the stable
 release independent of what the release is called.  I changed all 
 non-commented
 appearances of squeeze with stable in sources.list; do I need to do
 anything else?  Is this the right approach to take for a perpetually stable
 system?

One of the advantages of sticking with the named release in your sources.list 
is that when the next release becomes stable you can still install/update/etc. 
your old system until such time as you are ready to sit down and do the 
dist-upgrade to the new stable in a planned manner. It's important to plan your 
major updates and make sure you have time to fix any unexpected issues which 
may arise before hitting the return key on 'apt-get dist-upgrade', even on your 
own [non-production] machines to avoid headaches and panicking when things do 
not go as intended.

Laurence


-- 
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/20110602091944.gb77...@diss-84-211.lut.ac.uk



Managing large numbers (100+) of Debian-based machines

2011-04-07 Thread Laurence Hurst
Hi folks,
I am looking at possibly deploying Debian (or a derivative thereof) on a large 
number of machines (initially 80 but I fully expect the final number to end up 
being in excess of 100) which are intermittently connected to the network (due 
to multi-boot setup). I was wondering if anyone else has a large(ish) 
installation base and what tools they were using to manage the machines 
(especially when it comes to patching)? On this scale manual ssh methods become 
unmanageable, even using the likes of pdsh and before I even consider the fact 
the machines will not all be in Linux at any given time. Unfortunately I have 
no budget for this project so an Ubuntu/Landscape solution is not workable. 
Ideally something usable by non-Linux (but technically competent Windows) 
administrators would be nice (e.g. a point and shoot web-interface to mass 
deploy updates). Does anyone have any suggestions of existing projects which 
fit this bill or am I going to have to roll my own solution?
Thanks in advance
Laurence


-- 
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/20110407112130.ga45...@diss-84-211.lut.ac.uk