Re: OT: AOL fees (Re: Youtube - newbie guidance)

[rhkramer]

On Tuesday, December 26, 2017 12:35:16 PM Ric Moore wrote:
> On 12/23/2017 03:50 PM, rhkra...@gmail.com wrote:
> > On Saturday, December 23, 2017 03:31:31 PM Ric Moore wrote:
> >> Bob's your uncle. BTW, Google is no where as obnoxious as AOL during the
> >> old days when you could be paying hundreds a month for access to the web
> >> and email. I'll take Google any day and thank them for the huge
> >> freebies. Ric
> > 
> > This is OT, but I remember AOL as being expensive, but I didn't think it
> > was hundreds per month.
> 
> If you used it to any etent it was. I racked up several bills in the
> hundreds, doing what we take for granted nowadays. Luckily I had a
> moderator friend! Ric

Thanks!  I guess then I'm extra glad I never signed up for AOL!  (I used 
various Bulletin Boards back then.)

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[David Christensen]

On 12/26/17 11:37, Rick Thomas wrote:

Is btrfs mature enough to use in enterprise applications?

If you are using it, I’d like to hear from you about your experiences — good or 
bad.

My proposed application is for a small community radio station music library.
We currently have about 5TB of data in a RAID10 using four 3TB drives, with 
ext4 over the RAID.  So we’re about 75% full, growing at the rate of about 
1TB/year, so we’ll run out of space by the end of 2018.

I’m proposing to go to three 6TB drives in a btrfs/RAID5 configuration.  This 
would give us 12TB of usable data space and hold off til the end of 2024 before 
needing the next upgrade.

Will it work?  Would I be safer with ext4 over RAID5?


Take a look at ZFS before you decide -- either ZFS on Linux or FreeBSD:

https://packages.debian.org/stretch/zfs-dkms

https://www.freebsd.org/


I would suggest building a ZFS pool with two 8 TB mirrored drives.  When 
you want more space, add another mirrored pair.



Live compression and live de-duplication are useful features of ZFS, but 
the killer features are live snapshots and live replication.



David

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Michael Stone]

On Tue, Dec 26, 2017 at 05:21:10PM -0500, Roberto C. Sánchez wrote:

I second XFS for your application.  Another to consider might be JFS.
Either one of those would be very mature and suitable for the
enterprise.  I don't have any real experience with JFS


I can't think of any reason to go with JFS. Among other things, XFS is 
actively maintained...


Mike Stone

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Sven Hartge]

Roberto C. Sánchez  wrote:
> On Tue, Dec 26, 2017 at 09:48:09PM +0200, Eero Volotinen wrote:

>>use XFS, it's mature and suitable for big storage. (or gluster or
>>cehp?)

> I second XFS for your application.  Another to consider might be JFS.

I believe development of JFS has stopped several years ago and I don't
think it is suitable for new deployments into production.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Roberto C . Sánchez]

On Tue, Dec 26, 2017 at 09:48:09PM +0200, Eero Volotinen wrote:
>use XFS, it's mature and suitable for big storage. (or gluster or cehp?)

I second XFS for your application.  Another to consider might be JFS.
Either one of those would be very mature and suitable for the
enterprise.  I don't have any real experience with JFS, but I used XFS
for many years starting in 2002 or 2003.  These days the sorts of
applications I work with don't really call for delving deeply enough to
warrant worrying about the filesystem, but it sounds like something that
merits evaluation in your case.

In one of the early applications that I dealt with we had very large
files (on the order of 10s to 100s of GB, which was rather large in
those days.  On ext3, a file removal could take many minutes.  The
performance for ext2 was a bit better, but of course you take on added
risk with a non-journaled filesystem.  XFS, on the otherhand, could
delete a multi-100 GB file just quickly as it could delete a 1 KB file.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Andy Smith]

Hi Rick,

On Tue, Dec 26, 2017 at 11:37:32AM -0800, Rick Thomas wrote:
> Is btrfs mature enough to use in enterprise applications?

Not in my opinion. I've dabbled with it at home and based on those
experiences I will not be using it professionally any time soon.

> If you are using it, I’d like to hear from you about your experiences — good 
> or bad.

During the time of Debian wheezy I made use of btrfs for my home
fileserver, which is an HP Microserver with 4x 3.5" SATA drives and
an 8 bay disk chassis with 6 more 3.5" SATA HDDs in it, connected by
eSATA. It had previously been using LVM on top of Linux MD without
issue, but I'd become mindful of the amount of storage that was
being used without consistency checks (except for a weekly MD
scrub).

In order to do this I required a backports kernel and btrfs-tools
from git. I went for one of the more simple btrfs configurations
which is a raid1.

Over the next few years I didn't lose any data, but I did
experience:

- Out of space errors even when there was plenty of space

- Filesystems that went read-only on a device failure even though
  there was enough redundancy

- Filesystems that couldn't be remounted read-write after failed
  device replacement, even though the hardware is hot-swap, due to
  bugs in btrfs which required a kernel upgrade to fix (therefore a
  reboot, despite having the redundancy otherwise).

In summary, btrfs lowered the availability of the system due to
being buggy even in a relatively unexciting configuration. I could
not recommend it for serious use yet.

I am sure there will be plenty of people who've used it for years
without experiencing any issue. I am still subscribed to the btrfs
mailing list though, and unfortunately I still see people on there
reporting serious issues including data loss.

> My proposed application is for a small community radio station
> music library. We currently have about 5TB of data in a RAID10
> using four 3TB drives, with ext4 over the RAID.  So we’re about
> 75% full, growing at the rate of about 1TB/year, so we’ll run out
> of space by the end of 2018.

A year to solve this problem is nice to have, though. :)

> I’m proposing to go to three 6TB drives in a btrfs/RAID5 configuration.

If I were you I'd think very very carefully before using RAID-5 for
anything, btrfs or not.

- Four spindles to three means reduced performance.

- RAID-5 means parity means reduced performance.

- Lose one device and you're operating on just two spindles and
  recalculating parity. It will run like a dog and any further error
  means data loss, and array failure, which can be stressful and
  nerve-wracking to repair.

- I wouldn't like to chance my arm finding previously-unknown bad
  areas on two 6TB devices. When you have a three device RAID-5 and
  one device dies, you REQUIRE every sector on both the other
  devices to be readable in order to reconstruct the data onto the
  new device.

Personally I would not risk 3x6TB in any kind of RAID-5. HDDs are
pretty cheap so I really have to question the wisdom of cutting down
the number of spindles this far, and then using RAID-5.

RAID-10: okay, it "wastes" the most capacity in exchange for better
write performance. If this is a media library I get that maybe you
don't need the write performance (have you benchmarked your current
system??). RAID-10 is what you use when you can afford it, but if
you can't then compromises have to be made. In that case consider 4
or more spindles RAID-6. At least you stand a chance of being able
to replace a failed device before coming across a bad area on
another device.

Spread the extra cost of whatever you need to make it to four
devices in RAID-6 across the expected lifetime of your system (~6
years?) and does it still seem too much to pay?

Finally, the parity RAID levels in btrfs are newer than RAID-1 and
-10 and have seen a lot more bugs. Including really bad data loss
bugs.

One look at https://btrfs.wiki.kernel.org/index.php/RAID56 should be
enough.

> Would I be safer with ext4 over RAID5?

It's a bit of a frying pan / ground zero nuclear blast situation,
really.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

"I remember the first time I made love.  Perhaps it was not love exactly but I
 made it and it still works." — The League Against Tedium

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Jan Vales]

tl;dr:
save yourself the hassle and dont. go for md-raid5/6 + (luks +) XFS.

long version:

Just last week we migrated our soon to be production server (6 disks)
btrfs-raid10 to md-raid6+XFS, after btrfs managed to die twice in december.

So cool btrfs-raid/filesystem-level-raid sounds, so broken it seems atm :(
Not only did they not manage to use "common" definitions of raid - as
in: md-raid being de-facto-standard, they get to define certain aspects
of raid and others have to live by that ...

READ THEIR DOCS + MAILING LIST!

For example: when people talk about raid1 with say 4 disks, they expect
that all disks have the same contents... Therefore expecting that losing
3 disks means no data loss.
Well... btrfs decided to stick with some ancient definition of raid1
which is imho more like md-raid10, than md-raid1, as there are only 2
copies of data and you cant make btrfs to store more than 2 copies.
Therefore losing 2/4 disks -> btrfs irrecoverably broken.

btrfs-raid1 and btrfs-raid10 seem to be basically the same thing, with
some imho performance optimizations (not striping vs striping), which
should imho not even be user-settable as it makes no sense to go for
suboptimal performance, but then again, maybe i missed some of their
nearly inexistent documentation pointing out the good part of
btrfs-raid1 ...

Also btrfs-raid5/6 are broken and didnt even survive our in-vm-testing,
before getting a chance on bare-metal.


Also it seems way easier to go "full-raid-encryption" with luks + md-raid.
(Our intention is to be able to send in disks to get them replaced
without having to worry, that data could be easily extracted; there is
an usb-stick with the luks key sticking out of every machine...)

If you need some btrfs-features (snapshots <3), consider going
md-raid+luks+btrfs.
* Unsure if it still holds that btrfs will fail horribly if it sees its
uuid on more than one disk, possibly making the
full-disk-encryption-layer mandatory.

br,
Jan


On 12/26/17 20:37, Rick Thomas wrote:
> 
> Is btrfs mature enough to use in enterprise applications?
> 
> If you are using it, I’d like to hear from you about your experiences — good 
> or bad.
> 
> My proposed application is for a small community radio station music library.
> We currently have about 5TB of data in a RAID10 using four 3TB drives, with 
> ext4 over the RAID.  So we’re about 75% full, growing at the rate of about 
> 1TB/year, so we’ll run out of space by the end of 2018.
> 
> I’m proposing to go to three 6TB drives in a btrfs/RAID5 configuration.  This 
> would give us 12TB of usable data space and hold off til the end of 2024 
> before needing the next upgrade.
> 
> Will it work?  Would I be safer with ext4 over RAID5?
> 
> Thanks in advance!
> Rick
> 


-- 
lg
Jan Vales
--
I only read plaintext emails.

Someone @ irc://irc.fsinf.at:6667/tuwien
webIRC: https://frost.fsinf.at/iris/



signature.asc
Description: OpenPGP digital signature

Re: Experiences with BTRFS -- is it mature enough for enterprise use?

[Eero Volotinen]

use XFS, it's mature and suitable for big storage. (or gluster or cehp?)


Eero

26.12.2017 21.45 "Rick Thomas"  kirjoitti:

>
> Is btrfs mature enough to use in enterprise applications?
>
> If you are using it, I’d like to hear from you about your experiences —
> good or bad.
>
> My proposed application is for a small community radio station music
> library.
> We currently have about 5TB of data in a RAID10 using four 3TB drives,
> with ext4 over the RAID.  So we’re about 75% full, growing at the rate of
> about 1TB/year, so we’ll run out of space by the end of 2018.
>
> I’m proposing to go to three 6TB drives in a btrfs/RAID5 configuration.
> This would give us 12TB of usable data space and hold off til the end of
> 2024 before needing the next upgrade.
>
> Will it work?  Would I be safer with ext4 over RAID5?
>
> Thanks in advance!
> Rick
>

Experiences with BTRFS -- is it mature enough for enterprise use?

[Rick Thomas]

Is btrfs mature enough to use in enterprise applications?

If you are using it, I’d like to hear from you about your experiences — good or 
bad.

My proposed application is for a small community radio station music library.
We currently have about 5TB of data in a RAID10 using four 3TB drives, with 
ext4 over the RAID.  So we’re about 75% full, growing at the rate of about 
1TB/year, so we’ll run out of space by the end of 2018.

I’m proposing to go to three 6TB drives in a btrfs/RAID5 configuration.  This 
would give us 12TB of usable data space and hold off til the end of 2024 before 
needing the next upgrade.

Will it work?  Would I be safer with ext4 over RAID5?

Thanks in advance!
Rick

Re: Mixing and Matching DHCP and static IPs

[Dan Ritter]

On Mon, Dec 25, 2017 at 08:25:52PM -0600, Paul Johnson wrote:
> On Mon, Dec 25, 2017 at 10:49 AM, Marc Auslander 
> wrote:
> 
> > The safest way to fix an ip address in a dhcp served network is to tell
> > the dhcp server to associate that address with the mac of the unit.  The
> > address should be outside the dhcp range you set up.  I normall pin down
> > all my connected devices that way, leaving the dhcp assignment for
> > guests etc.  I've never seen a router which didn't support this.
> >
> >
> Or, just tell the DHCP server that you want a specific MAC address to
> always be assigned to a specific IP address.  It doesn't matter if it's in
> or out of the assignment range, then, or whether or not the unit in
> question understands DHCP or is configured manually on it's end; the DHCP
> server will not assign another client to that IP.  Though for ease of
> dealing with static assignments, I personally find it much simpler to do it
> all at the DHCP server end only if the client end speaks DHCP, just in the
> off chance I need to change the network configuration later.


Sample dhcpd config for a static IP assignment:

host thatonemachine {
 hardware ethernet d0:ee:fb:13:5e:a6;
 fixed-address 192.168.0.64;
}

You can read the ethernet MAC address on the machine in question
with 
ip l | grep ether

-dsr-

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

[deloptes]

Andrew W wrote:


> 
> 
> Does anyone have any ideas please?
> 

I had the same experience - I think (after trying this and that) the
solution was ntp (time was behind on the server), but I am not really 100%.
I was thinking first it has something to do with ipv6 or firewall, but after
updating the time, it disappeared.

perhaps it may help in your case to see if you sync up your machine time

regards

BIND DNS problem after upgrading from Wheezy to Squeeze

[Andrew Wood]

I have a server which acts as a DNS server for our LAN. All our internal 
servers have A records on it using a .local domain and it forwards all 
other requests out to the root servers using the in built list provided 
with BIND. All clients on the LAN have this machine set as their only 
DNS server.



It has worked fine for 6 years under Wheezy but I have just upgraded it 
to Stretch. I did an upgrade to Jessie first, rebooted checked 
everything was OK, and then immediately upgraded to Stretch.


Since then we keep getting intermittent DNS lookup failures for various 
domains on the internet, which will typically work if you click the 
refresh button in the browser a few times.


BIND seems to just log to syslog/systemd it doesnt appear to be 
configured to use its own log. If I run journalctl -xe | grep "named" I 
can get the log entries but none of them relate to the failed DNS 
lookup. If I do it immediately after a failure has occured nothing is 
logged so Im at a bit of a loss to work out what might be wrong.



Does anyone have any ideas please?


Thanks

Andrew

PS I should add that as far as I can tell it has never had a problem 
with resolving our internal .local domain it just seems to be real 
internet domains its having issues with.

BIND DNS problem after upgrading from Wheezy to Squeeze

[Andrew W]

I have a server which acts as a DNS server for our LAN. All our internal 
servers have A records on it using a .local domain and it forwards all 
other requests out to the root servers using the in built list provided 
with BIND. All clients on the LAN have this machine set as their only 
DNS server.



It has worked fine for 6 years under Wheezy but I have just upgraded it 
to Stretch. I did an upgrade to Jessie first, rebooted checked 
everything was OK, and then immediately upgraded to Stretch.


Since then we keep getting intermittent DNS lookup failures for various 
domains on the internet, which will typically work if you click the 
refresh button in the browser a few times.


BIND seems to just log to syslog/systemd it doesnt appear to be 
configured to use its own log. If I run journalctl -xe | grep "named" I 
can get the log entries but none of them relate to the failed DNS 
lookup. If I do it immediately after a failure has occured nothing is 
logged so Im at a bit of a loss to work out what might be wrong.



Does anyone have any ideas please?


Thanks

Andrew

PS I should add that as far as I can tell it has never had a problem 
with resolving our internal .local domain it just seems to be real 
internet domains its having issues with.

Re: OT: AOL fees (Re: Youtube - newbie guidance)

[Ric Moore]

On 12/23/2017 03:50 PM, rhkra...@gmail.com wrote:

On Saturday, December 23, 2017 03:31:31 PM Ric Moore wrote:

Bob's your uncle. BTW, Google is no where as obnoxious as AOL during the
old days when you could be paying hundreds a month for access to the web
and email. I'll take Google any day and thank them for the huge
freebies. Ric


This is OT, but I remember AOL as being expensive, but I didn't think it was
hundreds per month.



If you used it to any etent it was. I racked up several bills in the 
hundreds, doing what we take for granted nowadays. Luckily I had a 
moderator friend! Ric



--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

Re: Language of applications are not translated if the default language is changed

[john doe]

On 12/26/2017 5:04 PM, Teemu Likonen wrote:

john doe [2017-12-26 16:34:53+01] wrote:


The installed system is properly set to language 'a' (desktop manager,
Firefox, Thunderbird, Libreoffice, dictionaries ...).

In addition to language 'a', I want to add support for language 'b' so
the user could choose between language 'a' or 'b'. Doing
'dpkg-reconfigure locales' selecting language 'a' and 'b' is not
enough for Firefox, Thunderbird to be translated into language 'b'..
In console mode I can change the language using 'LANG*'. What should I
do to translate Firefox and Thunderbird to language 'b'?


The Debian package system has language "tasks" which can be installed
like packages. You can search your preferred languages with

 apt search task-LANGUAGE

where LANGUAGE is the name of the language (like task-finnish).
Graphical package manager programs can probably browse available tasks
too. I would recommend installing such tasks.

Also, some programs have their language-specific files in a separate
package: the name ends with -l10n- and a two-letter language code.



Thank you, I have something to read and try!!! :)

I really appriciate your input (I've been searching for a while without 
success).


--
John Doe

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 17:20, Michael Stone a écrit :

On Tue, Dec 26, 2017 at 05:04:34PM +0100, Pascal Hambourg wrote:
As any SOHO router, it is likely that the Airstation masquerades 
forwarded connections, so other nodes on its WAN side do no see the 
real 192.168.11.x addresses but only the WAN side address of the 
Airstation, 192.168.1.2.


Yes, double NAT is another even worse option. :)


I prefer to refer to this as "cascaded NAT", because "double NAT" could 
be confused with destination NAT and source NAT performed at the same 
time by a single device.

Re: Mixing and Matching DHCP and static IPs

[Michael Stone]

On Tue, Dec 26, 2017 at 05:04:34PM +0100, Pascal Hambourg wrote:
As any SOHO router, it is likely that the Airstation masquerades 
forwarded connections, so other nodes on its WAN side do no see the 
real 192.168.11.x addresses but only the WAN side address of the 
Airstation, 192.168.1.2.


Yes, double NAT is another even worse option. :)

Re: Language of applications are not translated if the default language is changed

[john doe]

On 12/26/2017 4:46 PM, Greg Wooledge wrote:

On Tue, Dec 26, 2017 at 04:34:53PM +0100, john doe wrote:

On 12/26/2017 2:27 PM, Greg Wooledge wrote:

 describes the basic concepts and
procedures for selecting your locale.



Thank you for this,

I guess what I'm asking is:

When I install Debian, at the beginning, I select language 'a' and proceed
with installation.
The installed system is properly set to language 'a' (desktop manager,
Firefox, Thunderbird, Libreoffice, dictionaries  ...).

In console mode I can change the language using 'LANG*'.
What should I do to translate Firefox and Thunderbird to language 'b'?


Are you currently using a Desktop Environment?  (If so, which one?)


Yes, I'm currently using Mate and Gnome.


If this is the case, then you typically need to select your language
within the Desktop Environment's control system.



That's a given.


If you aren't using a Desktop Environment, then how do you login?  On
the console and then 'startx', or through a Display Manager?  (If so,
which one?)

If you login via a DM, then your regular shell dot files are NOT read
during startup.  You would need to put your LANG=... in a different place
in order to be sure the DM reads it.

(And as we have learned the hard way on this mailing list, setting
variables won't help you AT ALL if you are using GNOME, because it
clobbers them and does its own thing.  You *really* need to use GNOME's
control system to set your language, if you use GNOME.  Which means you
are at the mercy of the GNOME control system, and all of its limitations.)



Not what I wanted to hear -- thanks


If this issue is really "I use foobardm; where do I put variables for
my login sessions" then see  for
suggestions.



I know that exporting shell variables 'LANG*' will not help for Gnome 
and Mate.


Apparently, I can't use the command line to set the languages in Gnome/Mate.
I have one computer (locally accessed) on which multiple users use 
different languages.

My goal is to avoied having to logged in to eatch user to set the language.

If I'm not clear enough or if what I want is not possible, an other 
approach along with some more testing will be needed.


--
John Doe

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 16:49, Michael Stone a écrit :


This is unnecessarily complicated, and will make your life harder than 
it needs to be. The best thing would be to not use the airstation as a 
router at all, just use it as a switch + wireless access point in a flat 
configuration, with the router plugged into the switch. Ignore the "wan" 
port on the airstation and turn off any dhcp or other services that it 
is providing.


The most important part is "turn off any DHCP service it provides". 
Othewise it will get in the way of the other DHCP server.


This will not work the way you think it will. Devices on the airstation 
will have packets go directly to 192.168.1.3 (because the airstation 
knows how to get to anything on 192.168.1.0/24) (you never actually 
specified the netmask for 192.168.1., hopefully that's correct). The 
packets returning from 192.168.1.3 will go to 192.168.1.1 because 
192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the 
default route instead.


As any SOHO router, it is likely that the Airstation masquerades 
forwarded connections, so other nodes on its WAN side do no see the real 
192.168.11.x addresses but only the WAN side address of the Airstation, 
192.168.1.2.


I guess that even the firewall does not have a special route for 
192.168.11.0/24, as it is not supposed to see that address range.

Re: Language of applications are not translated if the default language is changed

[Teemu Likonen]

john doe [2017-12-26 16:34:53+01] wrote:

> The installed system is properly set to language 'a' (desktop manager,
> Firefox, Thunderbird, Libreoffice, dictionaries ...).
>
> In addition to language 'a', I want to add support for language 'b' so
> the user could choose between language 'a' or 'b'. Doing
> 'dpkg-reconfigure locales' selecting language 'a' and 'b' is not
> enough for Firefox, Thunderbird to be translated into language 'b'..
> In console mode I can change the language using 'LANG*'. What should I
> do to translate Firefox and Thunderbird to language 'b'?

The Debian package system has language "tasks" which can be installed
like packages. You can search your preferred languages with

apt search task-LANGUAGE

where LANGUAGE is the name of the language (like task-finnish).
Graphical package manager programs can probably browse available tasks
too. I would recommend installing such tasks.

Also, some programs have their language-specific files in a separate
package: the name ends with -l10n- and a two-letter language code.

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: Mixing and Matching DHCP and static IPs

[Michael Stone]

On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:

I run a home network with what might be slightly unusual topology. At
the centre of it is a Buffalo Airstation which services a bunch of
iDevices, a couple of Androids, a Windoze laptop, 


It's bad enough having to read a really long post without having to also 
see juvenile things like "windoze" scattered throughout...



and a mini ITX machine
running Stretch, and its wired ethernet ports also service a NAS and my
main Debian Stretch desktop. Until very recently I ran a cable from the
AirStation's WAN port to another mini ITX PC, this one running LFS,
which acts as my firewall (I don't trust the firewall in the
AirStation). The firewall runs a DHCP server to supply the AirStation
with an IP address. The AirStation runs its own DHCP server on its LAN
side, giving out IP addresses in the range 192.168.11.0/24, which is how
all my machines except the firewall get their IP addresses. The firewall
gets its external-facing interface IP via DHCP from my ISP and is static
IP on its internal-facing side.


This is unnecessarily complicated, and will make your life harder than 
it needs to be. The best thing would be to not use the airstation as a 
router at all, just use it as a switch + wireless access point in a flat 
configuration, with the router plugged into the switch. Ignore the "wan" 
port on the airstation and turn off any dhcp or other services that it 
is providing.



Recently I threw together LFS on a Raspberry PI and decided to use it as
a caching DNS server. My plan is to run dnscache on it. The list may
remember a thread I started a few months ago about the best way to solve
DNS worries I had back then; I got some good advice at that time and
this is me implementing said advice -- at long last I have some time off
work and time to work on this.


Honestly, this will probably end up being slower overall than not having 
a caching DNS server, because the PI is slow and you're adding latency 
to all requests without significantly speeding up cached requests.



If the PI is going to be useful as a caching DNS server for my network, it
needs to not be in danger of having its IP address changed -- especially
since it is going to need to be sitting outside the AirStation's LAN
(since the AirStation insists it is the DNS server for its LAN, but
actually merely forwards on all DNS queries to whatever DNS server it
has been given in its WAN setup).


A DNS server will always have a range of IPs that it is configured to 
use, if you assign an IP statically outside that range there is no 
danger of "having its IP changed". You don't need to put a device on a 
new subnet to achieve that goal.



So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit
Switch to be precise -- and have configured the PI to have a static IP
on the same subnet as the firewall and the IP address given to the
AirStation by the firewall. To be concrete, the internal-facing firewall
interface is 192.168.1.1 (static, works), the DHCP server I set up on
the firewall gives out 192.168.1.2 to the AirStation (works), and I have
configured the PI to use 192.168.1.3 (static, partly works). So inside
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
192.168.1.1, .2 and .3 -- note the third octet difference for internal
and external. All 3 of AirStation WAN port, PI and firewall
internal-facing interface are plugged into the switch. I ran the switch
for a couple of days with just the firewall and the AirStation plugged
in (ie the switch was strictly unnecessary at that stage) and the
network suffered no apparent ill effects. So the switch appears to be in
good working order.


This will not work the way you think it will. Devices on the airstation 
will have packets go directly to 192.168.1.3 (because the airstation 
knows how to get to anything on 192.168.1.0/24) (you never actually 
specified the netmask for 192.168.1., hopefully that's correct). The 
packets returning from 192.168.1.3 will go to 192.168.1.1 because 
192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the 
default route instead. The firewall at 192.168.1.1 will drop those 
packets because they don't form a valid session. To make this work, 
192.168.1.3 (and any other device on 192.168.1.0/24) would need a static 
route to 192.168.11.0/24 via 192.168.1.2. This will be a pain to 
maintain, and offers no advantage over simply having a flat network and 
abandoning the routing functionality of the airstation.


Mike Stone

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 15:50, Dan Purgert a écrit :


Pascal Hambourg wrote:

Le 26/12/2017 à 12:33, Dan Purgert a écrit :

[...]
Sounds like perhaps the airstation is blocking client devices from
talking to "bogus" network addresses.  This is generally a feature of
consumer gear to stop you from trying to ask the internet for
information about a RFC1918 address (as they are private / not routable
on the internet).


What do you mean by "ask the internet for information about a RFC1918
address" ? Sending an IP packet is not asking the internet for any
information.


No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
192.168.11.0/24), you "ask" your gateway for assistance in getting the
packet to its intended destination.


The host does not really "ask" anything to the router ("gateway" is 
deprecated). It justs sends the packet to it. Also, from its routing 
table it knows how to get to the destination : through the router. What 
happens beyond the router is irrelevant to the host as long as the 
packet is forwarded to the destination in the end.


E.g. the following routing table :
default via 192.168.0.1 dev eth0  proto static
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.238

does not mean "I don't know how to route anything else than 
192.168.0.0/24". It means "192.168.0.0/24 is directly reachable, and all 
the rest is reachable through the router at 192.168.0.1.



Now, since RFC1918 space is not routable on the internet, and consumer
gear is meant to be "easy", some assumptions are made - such that "no,
they'll never want to use this to talk to an upstream RFC1918 network,
so we can safely block it and keep them from asking ISP gateways for
networks that don't actually exist".


This assumption seems wrong. ISP networks use RFC1918 addresses, and 
such devices may be used on private networks



Maybe I missed something but I read no evidence in the OP's posts that
the netmask on the Airstation WAN side is actually /24. If for instance
the mask was set to /30 instead, 192.168.1.3 would be considered by the
Airstation as a broadcast address and would explain why it does not work.


That could also be possible, but I made the assumption that it was the
"default(tm)" subnet from a generic residential gateway device.  Also,
since he can apparently ssh into the rpi from whatever the firewall
device is, it is not likely to be a broadcast address.


But the Air-station may be misled by a wrong DHCP netmask into believing 
that 192.168.1.3 is a broadcast address.

Re: Language of applications are not translated if the default language is changed

[Greg Wooledge]

On Tue, Dec 26, 2017 at 04:34:53PM +0100, john doe wrote:
> On 12/26/2017 2:27 PM, Greg Wooledge wrote:
> >  describes the basic concepts and
> > procedures for selecting your locale.

> Thank you for this,
> 
> I guess what I'm asking is:
> 
> When I install Debian, at the beginning, I select language 'a' and proceed
> with installation.
> The installed system is properly set to language 'a' (desktop manager,
> Firefox, Thunderbird, Libreoffice, dictionaries  ...).
> 
> In console mode I can change the language using 'LANG*'.
> What should I do to translate Firefox and Thunderbird to language 'b'?

Are you currently using a Desktop Environment?  (If so, which one?)
If this is the case, then you typically need to select your language
within the Desktop Environment's control system.

If you aren't using a Desktop Environment, then how do you login?  On
the console and then 'startx', or through a Display Manager?  (If so,
which one?)

If you login via a DM, then your regular shell dot files are NOT read
during startup.  You would need to put your LANG=... in a different place
in order to be sure the DM reads it.

(And as we have learned the hard way on this mailing list, setting
variables won't help you AT ALL if you are using GNOME, because it
clobbers them and does its own thing.  You *really* need to use GNOME's
control system to set your language, if you use GNOME.  Which means you
are at the mercy of the GNOME control system, and all of its limitations.)

If this issue is really "I use foobardm; where do I put variables for
my login sessions" then see  for
suggestions.

Re: Language of applications are not translated if the default language is changed

[john doe]

On 12/26/2017 2:27 PM, Greg Wooledge wrote:

On Sun, Dec 24, 2017 at 08:27:20AM +0100, Andre Majorel wrote:

On 2017-12-23 19:21 +0100, john doe wrote:


I have install Debian 9 using as the default language 'C'.
I want to add some new languages, and for this I do 'dpkg-reconfigure
locales'.
I'm currently using Gnome and Mate.

How can I add support for those new languages so all
applications will be translated in the desired language (using
command line is prefered)?


Have you tried setting LC_ALL appropriately (eg LC_ALL=fr_FR) in
your .profile then logging out & in again ?


Do not use LC_ALL for this purpose.  It should be reserved for emergency
overrides on a single command basis.

Use the LANG variable to set your default locale and character set.

 describes the basic concepts and
procedures for selecting your locale.

In order to receive output in your preferred language, each application
needs to have been configured for localization *and* have a translation
mapping for your language.  The more common/popular a program is, the
more likely this is to be true, at least for the more common languages.



Thank you for this,

I guess what I'm asking is:

When I install Debian, at the beginning, I select language 'a' and 
proceed with installation.
The installed system is properly set to language 'a' (desktop manager, 
Firefox, Thunderbird, Libreoffice, dictionaries  ...).


In addition to language 'a', I want to add support for language 'b' so 
the user could choose between language 'a' or 'b'.
Doing 'dpkg-reconfigure locales' selecting language 'a' and 'b' is not 
enough  for Firefox, Thunderbird to be translated into language 'b'..

In console mode I can change the language using 'LANG*'.
What should I do to translate Firefox and Thunderbird to language 'b'?

--
John Doe

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 16:05, Mark Fletcher a écrit :


At the risk of further advertising my ignorance, 3 as an 8-bit binary is
0011, and 252 in binary is 1100, so why doesn't that mask "fit"
with that address? (if you'll pardon my poor terminology) Put another
way, why do I need to zero out another bit of the mask to make .3 a
unicast address?


The IPv4 protocol specification gives a special meaning to the first and 
last addresses in a subnet. The first address is the "network address" 
and the last address is the "broadcast address". Both are reserved and 
cannot be used as unicast host address.


The only exception is for /31 prefixes on "point to point" links. Such 
networks contain only a pair of address, so the usual rule would reserve 
them as network and broadcast addresses and and leave no usable host 
address, making the prefix useless in practice. Instead, both addresses 
are used as host addresses for the nodes at each end of the point to 
point link, and there are no network and broadcast addresses (pointless 
on a point to point link). This exception was created to avoid the use 
of /30 prefixes on such point to point links which would waste half of 
the addresses. Note that old devices and systems may not support this.



But why do you bother with such narrow subnets and just don't use
255.255.255.0 (/24) ? It has been reported that some devices and OSes don't
behave well with "unusual" netmasks (having values other than 255 and 0).


Totally fair question. No good reason these days. I am happy to change
it.


IIUC, you declared subnet 192.168.1.0/30 or /29 in the DHCP server 
configuration. But what subnet or prefix lenght did you set up on the 
interface configuration of the firewall and server ?



Also, I recommend that you run a packet capture on the firewall and the
server to see what's going on when you try to communicate to the server from
the internal network.

tcpdump -nei 


Yes, this is going to be my next port of call (after I've opened up the
netmask to 255.255.255.0). Since both the PI and the firewall are LFS I
will probably have to build the tcpdump program for them both as there
is nothing installed on either of them that isn't strictly needed.


Sorry for the extra burden.
Running a packet sniffer on another (e.g. Debian) machine on the 
external subnet would only capture broadcast packets, except if your 
ethernet switch supports a "mirror port" feature which mirrors incoming 
traffic on all ports to a special port for monitoring purpose.
Using iptables LOG rules in raw/PREROUTING and mangle/POSTROUTING on the 
router and the server would log only IPv4 packets, not ARP packets which 
could provide valuable information. Maybe by combining the two you could 
gather enough data.

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 03:02:46PM -, Dan Purgert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> >> 
> > The netmask is 255.255.255.252. I just tried changing it to 248, ie 
> > zeroing out one more bit, but that did not help. (changed it by changing 
> > the netmask supplied by the firewall's DHCP server and then checking in 
> > the AirStation's web interface that the netmask had indeed changed).
> 
> This is the absolute most key piece of information that was required to
> help troubleshoot your problem ... 
> 
> 255.255.255.252 is /30, meaning you only had two usable addresses
> (192.168.1.1, and 192.168.1.2 -- 192.168.1.3 was the broadcast.  Strange
> that you could ssh from the firewall device to this IP address, but no
> matter).  
> 
> Switch everything - airstation, upstream firewall, rpi, anything else to
> /29 (255.255.255.248), and restart their relevant interfaces.  Don't
> forget to update any iptables rules, etc. that may have triggered on the
> netmask.
> 
> 
OK -- although to Pascal's point, I think I'll go with 255.255.255.0 -- 
no reason not to. But nonetheless that is what I will do next. Will 
advise (tomorrow -- it's past my bedtime now).

Mark

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 02:31:05PM -, Dan Purgert wrote:
> >> No, the airstation having been given an address 192.168.1.x/24 will know
> >> that it can directly reach any host 192.168.1.1 through 192.168.1.254
> >> inclusive.
> >>
> >
> > Except for some reason it doesn't seem to (or, rather, that is what
> > APPEARS to be the case but without answering some of Pascal's earlier
> > questions I can't say for certain that is what is going on). We know
> > that 1.1 c an reach 1.3, but 11.anything doesn't seem to be able to,
> > even though they can reach 1.1 . I just don.t know why yet.
> 
> Again, this points to the idea that perhaps the Airstation has a
> firewall preventing access to "bogus" networks. I assume that the
> Airstation does not have any capabilities to run ping / traceroute tests
> from somewhere in its administration menus?
> 
> If it DOES allow that, it may be helpful to try pinging directly from
> the airstation.

I don't think I'm gonna have much luck with that. The Web interface is 
fairly bog standard -- and what is there is in Japanese, which doesn't 
help... I can read Japanese, but slowly, with errors... With all that 
said, I have spent enough time squinting at that interface to be fairly 
sure it doesn't offer that functionality.

> 
> Also, since I probably missed it, what is the "firewall" device that's
> handing out the 1.0/24 network (make and model please)?
> 

Yeah that was in the TLDR original post. It's a mini-ITX PC running LFS. 
It came with Windows 10, and I ripped it out of Windows' evil clutches 
and installed LFS on it. Before bringing the PI into the picture, this 
box had been acting as my firewall, DHCP server for the AirStation, and 
occasional VPN server for me for about a year with no problems.

Mark

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 02:50:44PM -, Dan Purgert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Pascal Hambourg wrote:
> > Le 26/12/2017 à 12:33, Dan Purgert a écrit :
> >> [...]
> >> Sounds like perhaps the airstation is blocking client devices from
> >> talking to "bogus" network addresses.  This is generally a feature of
> >> consumer gear to stop you from trying to ask the internet for
> >> information about a RFC1918 address (as they are private / not routable
> >> on the internet).
> >
> > What do you mean by "ask the internet for information about a RFC1918 
> > address" ? Sending an IP packet is not asking the internet for any 
> > information.
> 
> No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
> 192.168.11.0/24), you "ask" your gateway for assistance in getting the
> packet to its intended destination.
> 
> Now, since RFC1918 space is not routable on the internet, and consumer
> gear is meant to be "easy", some assumptions are made - such that "no,
> they'll never want to use this to talk to an upstream RFC1918 network,
> so we can safely block it and keep them from asking ISP gateways for
> networks that don't actually exist".
> 
> This doesn't cause any problems in the setup for "getting to the
> internet" since the destination IP address is not RFC1918. 

This is a fascinating sub-thread of the discussion. What I think you are 
saying is that, as consumer gear, the AirStation is assuming that if it 
is asked to route to a "private" IP address, it essentially refuses, 
because that can't be right. I think the BUT here, though, is that I can 
ssh from a machine on the inner network (connected to a LAN port of the 
AirStation) to the firewall at the outermost edge of my network (that 
is, from 192.168.11.x to 192.168.1.1) and that works. From what you are 
saying, it shouldn't -- UNLESS, the AirStation makes an exception 
specifically for 192.168.1.1 because that is what it has been told its 
default gateway is.

Mark

Re: Mixing and Matching DHCP and static IPs

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark Fletcher wrote:
> On Tue, Dec 26, 2017 at 01:05:03PM +0100, Pascal Hambourg wrote:
>> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
>> > 
>> > > Now 192.168.1.1 is the default gateway the firewall supplies the
>> > > AirStation (ie it supplies itself as the gateway) when the AirStation
>> > > makes a DHCP request, and I'm guessing that is why I can reach
>> > > 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I
>> > > am wondering if the AirStation somehow doesn't know that it can reach
>> > > 192.168.1.3 directly, which I would expect it to since it is plugged
>> > > into the same switch as it and 192.168.1.1 -- and if so, how I would
>> > > persuade it to know that?
>> 
>> Being plugged to the same switch is not enough. The routing table must also
>> contain a direct route to the destination.
>
> Thank you for confirmation of this. I suspected as much, but didn't have 
> any facts, and if that is the case then this is almost certainly what is 
> wrong, because I recognise I did nothing to tell the AirStation about 
> this. Now I just need to figure out the best way to get that information 
> into the AirStation's routing tables, preferably in a way that will 
> survive reboots of the various machines involved -- perhaps the DHCP 
> settings changes I've already been pointed at will have the effect of 
> doing so. I've been battling a totally unrelated printing problem today 
> but will advise as soon as I have tried that.


If the airstation is getting its IP address via DHCP, you don't have to
give it any further routing information for the 192.168.1.0 subnet.  It
was provided all of that information by the DHCP server itself.

The airstation's routing table will look something like this:

0.0.0.0/0 via 192.168.1.1, via eth0 ("WAN", whatever)
192.168.1/0 is directly connected, eth0 ("WAN", whatever)
 
>> Maybe I missed something but I read no evidence in the OP's posts
>> that the netmask on the Airstation WAN side is actually /24. If for
>> instance the mask was set to /30 instead, 192.168.1.3 would be
>> considered by the Airstation as a broadcast address and would explain
>> why it does not work.
>> 
> The netmask is 255.255.255.252. I just tried changing it to 248, ie 
> zeroing out one more bit, but that did not help. (changed it by changing 
> the netmask supplied by the firewall's DHCP server and then checking in 
> the AirStation's web interface that the netmask had indeed changed).

This is the absolute most key piece of information that was required to
help troubleshoot your problem ... 

255.255.255.252 is /30, meaning you only had two usable addresses
(192.168.1.1, and 192.168.1.2 -- 192.168.1.3 was the broadcast.  Strange
that you could ssh from the firewall device to this IP address, but no
matter).  

Switch everything - airstation, upstream firewall, rpi, anything else to
/29 (255.255.255.248), and restart their relevant interfaces.  Don't
forget to update any iptables rules, etc. that may have triggered on the
netmask.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaQmR3AAoJEI4R3fMSeaKBBtEH/2leUCp7olulBfNWCFpdRxmB
vH7gwM3p79bPzrIc7lp4v18OHA3NYn2SNXEl6eSsj1pbbibDt+bkCzMiegDrtjg8
0NBrmr4PL/QbUBUzEkbbm6SeZazSRcu033uOHxLJu1JAUD/6C89c2DjhEzPMnvyP
FK6nTfTnfdLs65XTuH+O96R6WgIPRL8ijWTpl47LGPD7vrTwrb211GYCnfiqeKX+
lNarnIcKZFYdkMuP94I9lPVSe+7Tj6YIlRKmALfzaUTTpfLa7UyRO2j4cJ50caRS
UzBGsC+ITdiOVXw9U6vLm3r6DHQ8kGkBz9kGvyuD04T4vvJ6BHcHM4Gk3JnPkx4=
=WOxz
-END PGP SIGNATURE-

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 03:43:50PM +0100, Pascal Hambourg wrote:
> > > 
> 
> 
> > The firewall's routing rules are (amongst other rules
> > which I don't believe relevant -- and external interface name elided):
> > 
> > iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
> > iptables -A FORWARD ! -i  -m conntrack --ctstate NEW
> >-j ACCEPT
> > 
> > ...which I think should allow it to route from the inside interface to
> > the inside interface.
> 
> It should work with ICMP echo (ping) and UDP (used for DNS). But IIRC it
> would not work with TCP (used by SSH) because the firewall does not see the
> reply packets (including the SYN/ACK in the 3-way handshake) sent by the
> server directly to the client, so the subsequent packets from the client
> would be flagged in the INVALID state and not accepted by these rules.

Oh-ho. Well that is probably at play here then. I am getting excited, it 
feels like we may be closing in on the problem.

> > > 
> > The netmask is 255.255.255.252. I just tried changing it to 248, ie
> > zeroing out one more bit, but that did not help. (changed it by changing
> > the netmask supplied by the firewall's DHCP server and then checking in
> > the AirStation's web interface that the netmask had indeed changed).
> 
> Netmask 255.255.255.252 with network 192.168.1.0 (or 192.168.1.0/30) implies
> that 192.168.1.3 is a broadcast address and cannot be used as a unicast host
> address. Even though the Airstation accepted to forward packets sent to this
> address, the packets would be sent on the WAN link to the broadcast ethernet
> address (ff:ff:ff:ff:ff:ff) and discarded by the server for this reason (a
> packet must not have a unicast IP address and a broadcast ethernet address).
> 
> With netmask 255.255.255.248 (192.168.1.0/29), the broadcast address is
> 192.168.1.7 and 192.168.1.3 is considered as a unicast host address so the
> above issue should disappear.
> 

Unfortunately when I changed it to 248, and made sure the AirStation had 
updated, that made no difference.

At the risk of further advertising my ignorance, 3 as an 8-bit binary is 
0011, and 252 in binary is 1100, so why doesn't that mask "fit" 
with that address? (if you'll pardon my poor terminology) Put another 
way, why do I need to zero out another bit of the mask to make .3 a 
unicast address?

> But why do you bother with such narrow subnets and just don't use
> 255.255.255.0 (/24) ? It has been reported that some devices and OSes don't
> behave well with "unusual" netmasks (having values other than 255 and 0).
> 

Totally fair question. No good reason these days. I am happy to change 
it. In the early days of this setup (when I first built my firewall, so 
something like a year ago at least) I did this because I wanted to see 
if I had properly understood how a netmask worked. The goal at that time 
was 50% learn, 50% get a working setup. I was thinking, if I set it the 
way I had, and it worked the way I thought it did, it should work. It 
worked, and I concluded I understood it. I see now the flaw in that 
logic.

> Also, I recommend that you run a packet capture on the firewall and the
> server to see what's going on when you try to communicate to the server from
> the internal network.
> 
> tcpdump -nei 
> 

Yes, this is going to be my next port of call (after I've opened up the 
netmask to 255.255.255.0). Since both the PI and the firewall are LFS I 
will probably have to build the tcpdump program for them both as there 
is nothing installed on either of them that isn't strictly needed. I'll 
report back when I have done that, if I don't figure something else out 
in the meantime.

Mark

Re: Mixing and Matching DHCP and static IPs

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pascal Hambourg wrote:
> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
>> [...]
>> Sounds like perhaps the airstation is blocking client devices from
>> talking to "bogus" network addresses.  This is generally a feature of
>> consumer gear to stop you from trying to ask the internet for
>> information about a RFC1918 address (as they are private / not routable
>> on the internet).
>
> What do you mean by "ask the internet for information about a RFC1918 
> address" ? Sending an IP packet is not asking the internet for any 
> information.

No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
192.168.11.0/24), you "ask" your gateway for assistance in getting the
packet to its intended destination.

Now, since RFC1918 space is not routable on the internet, and consumer
gear is meant to be "easy", some assumptions are made - such that "no,
they'll never want to use this to talk to an upstream RFC1918 network,
so we can safely block it and keep them from asking ISP gateways for
networks that don't actually exist".

This doesn't cause any problems in the setup for "getting to the
internet" since the destination IP address is not RFC1918. 

> [...]
>> No, the airstation having been given an address 192.168.1.x/24 will know
>> that it can directly reach any host 192.168.1.1 through 192.168.1.254
>> inclusive.
>
> Maybe I missed something but I read no evidence in the OP's posts that 
> the netmask on the Airstation WAN side is actually /24. If for instance 
> the mask was set to /30 instead, 192.168.1.3 would be considered by the 
> Airstation as a broadcast address and would explain why it does not work.

That could also be possible, but I made the assumption that it was the
"default(tm)" subnet from a generic residential gateway device.  Also,
since he can apparently ssh into the rpi from whatever the firewall
device is, it is not likely to be a broadcast address.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaQmGlAAoJEI4R3fMSeaKBdlQH/jQBLzNvC2DQI7psM8c0Gz7T
uVpnxlkrpB5+A18iVwpevzlosswsE/5QwaBF5MTFWWBZ5l27f2q2qIs2r8qiwAZ6
poIT6cNa8FrP6Vk7N5K0E5/b3hYCtsv4f3YiReS6z5t7dWWJhsDRmXrb59InHS08
SJZDuV6/4d+8wUOzPpCLoLRVWDn3IhR9rljFcoVOLfHVs28PxdeHiH38YQw/D/b2
6yIy0OqRJZjP0QI+SV09liTJEKIoL9Lo57mmSmM7KnCciSRpgFZChb3wTQ1ajavq
ANQQ4bRFRNltHiUC69J4iuO2r3Ojw4azmOcRL6pNsOkEaQIeorm25e+xPtI/W/Q=
=fsYJ
-END PGP SIGNATURE-

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 14:55, Mark Fletcher a écrit :



I would also expect that if it did not know
that, it would send packets for 192.168.1.3 to 192.168.1.1 for
forwarding, just as it does every packet that is destined for the
internet -- and I would expect the firewall to be able to forward them,
since it can clearly see the PI.


A firewall usually has filtering rules. Do these rules allow packets to be
forwarded from the LAN interface back to the same interface ?
Also, this would cause asymmetric routing (the server would send reply
packets directly to the client), which may not work well with stateful
filtering as the firewall would see only one direction of the communication.


Fair question re routing rules.


Filtering rules, not routing rules.
Routing rules determine how a packet should be routed.
Filtering rules such as iptables rules determines whether a packet 
should be dropped or accepted.



The firewall's routing rules are (amongst other rules
which I don't believe relevant -- and external interface name elided):

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i  -m conntrack --ctstate NEW   
-j ACCEPT

...which I think should allow it to route from the inside interface to
the inside interface.


It should work with ICMP echo (ping) and UDP (used for DNS). But IIRC it 
would not work with TCP (used by SSH) because the firewall does not see 
the reply packets (including the SYN/ACK in the 3-way handshake) sent by 
the server directly to the client, so the subsequent packets from the 
client would be flagged in the INVALID state and not accepted by these 
rules.



No, the airstation having been given an address 192.168.1.x/24 will know
that it can directly reach any host 192.168.1.1 through 192.168.1.254
inclusive.


Maybe I missed something but I read no evidence in the OP's posts that the
netmask on the Airstation WAN side is actually /24. If for instance the mask
was set to /30 instead, 192.168.1.3 would be considered by the Airstation as
a broadcast address and would explain why it does not work.


The netmask is 255.255.255.252. I just tried changing it to 248, ie
zeroing out one more bit, but that did not help. (changed it by changing
the netmask supplied by the firewall's DHCP server and then checking in
the AirStation's web interface that the netmask had indeed changed).


Netmask 255.255.255.252 with network 192.168.1.0 (or 192.168.1.0/30) 
implies that 192.168.1.3 is a broadcast address and cannot be used as a 
unicast host address. Even though the Airstation accepted to forward 
packets sent to this address, the packets would be sent on the WAN link 
to the broadcast ethernet address (ff:ff:ff:ff:ff:ff) and discarded by 
the server for this reason (a packet must not have a unicast IP address 
and a broadcast ethernet address).


With netmask 255.255.255.248 (192.168.1.0/29), the broadcast address is 
192.168.1.7 and 192.168.1.3 is considered as a unicast host address so 
the above issue should disappear.


But why do you bother with such narrow subnets and just don't use 
255.255.255.0 (/24) ? It has been reported that some devices and OSes 
don't behave well with "unusual" netmasks (having values other than 255 
and 0).


Also, I recommend that you run a packet capture on the firewall and the 
server to see what's going on when you try to communicate to the server 
from the internal network.


tcpdump -nei 

Re: Mixing and Matching DHCP and static IPs

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark Fletcher wrote:
> --001a113ec1c0f4dccb05613d0b84
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Dec 26, 2017 at 20:40 Dan Purgert  wrote:
>
>>
>> Sounds like perhaps the airstation is blocking client devices from
>> talking to "bogus" network addresses.  This is generally a feature of
>> consumer gear to stop you from trying to ask the internet for
>> information about a RFC1918 address (as they are private / not routable
>> on the internet).
>>
>
> So the trick would be to discourage it from thinking of 192.168.1.3 as
> bogus... Do you think the earlier suggestion of having the IP address
> handed out by the DHCP server on the firewall but using DHCP
> reservation to make sure the PI gets a specific address would fix
> that?

Unlikely, since it is the Airstation's firewall making the determination
that the 1.0/24 network is bogus.

> [...]
>>
>> No, the airstation having been given an address 192.168.1.x/24 will know
>> that it can directly reach any host 192.168.1.1 through 192.168.1.254
>> inclusive.
>>
>
> Except for some reason it doesn't seem to (or, rather, that is what
> APPEARS to be the case but without answering some of Pascal's earlier
> questions I can't say for certain that is what is going on). We know
> that 1.1 c an reach 1.3, but 11.anything doesn't seem to be able to,
> even though they can reach 1.1 . I just don.t know why yet.

Again, this points to the idea that perhaps the Airstation has a
firewall preventing access to "bogus" networks. I assume that the
Airstation does not have any capabilities to run ping / traceroute tests
from somewhere in its administration menus?

If it DOES allow that, it may be helpful to try pinging directly from
the airstation.

Also, since I probably missed it, what is the "firewall" device that's
handing out the 1.0/24 network (make and model please)?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaQl0LAAoJEI4R3fMSeaKBSd8H/iQzt50XajYC6cKsTGQPxnd2
k2e2ww+A23El8IYUTyNq25XrT9jl3KTXgRyeu2FHZ6NhuWxJDMbrnzYalruopMnP
tV4URBcgbKA6rsa4SM5iqJdgpCtWQ+FtvnI7fJmuf5Mz9tgpV1M3oGdgyKh32kXd
kUO3Gye6iATL17Eb8IVet6D7HBHnZbODWNJSrMsH2iM0I6+obUqY7LYr7cVndPVi
+2+sYc76mhHX+nXLwH+0kPORBC36qO0z2LQQnjWyPiyn6NymMdFGLvgdxaZIWl1g
wWB0UHNwPMe1e/C1hvBU4vGc/xo5aRZ3jJTCI/ib2NPgePOlWhGWkJ7hD7lfiE0=
=S4d8
-END PGP SIGNATURE-

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: Mixing and Matching DHCP and static IPs

[deloptes]

Pascal Hambourg wrote:

> And lose the protection provided by the firewall to wireless devices ?
> Sounds like a great idea.
> 

It is more dangerous having the WLAN behind your firewall. I hope you
understand this.

>> or you can turn off the firewall there completely
> 
> And push your logic to the limit : remove the protection for all
> devices, not only wireless ones.

your firewall will protect you anyway - devices using WLAN should have
firewalls enabled anyway on their end.

If you think you are smarter, I don't mind, but you were the one that asked
the question.

regards

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 01:05:03PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
> > 
> > > Now 192.168.1.1 is the default gateway the firewall supplies the
> > > AirStation (ie it supplies itself as the gateway) when the AirStation
> > > makes a DHCP request, and I'm guessing that is why I can reach
> > > 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I
> > > am wondering if the AirStation somehow doesn't know that it can reach
> > > 192.168.1.3 directly, which I would expect it to since it is plugged
> > > into the same switch as it and 192.168.1.1 -- and if so, how I would
> > > persuade it to know that?
> 
> Being plugged to the same switch is not enough. The routing table must also
> contain a direct route to the destination.

Thank you for confirmation of this. I suspected as much, but didn't have 
any facts, and if that is the case then this is almost certainly what is 
wrong, because I recognise I did nothing to tell the AirStation about 
this. Now I just need to figure out the best way to get that information 
into the AirStation's routing tables, preferably in a way that will 
survive reboots of the various machines involved -- perhaps the DHCP 
settings changes I've already been pointed at will have the effect of 
doing so. I've been battling a totally unrelated printing problem today 
but will advise as soon as I have tried that.

> 
> > I would also expect that if it did not know
> > > that, it would send packets for 192.168.1.3 to 192.168.1.1 for
> > > forwarding, just as it does every packet that is destined for the
> > > internet -- and I would expect the firewall to be able to forward them,
> > > since it can clearly see the PI.
> 
> A firewall usually has filtering rules. Do these rules allow packets to be
> forwarded from the LAN interface back to the same interface ?
> Also, this would cause asymmetric routing (the server would send reply
> packets directly to the client), which may not work well with stateful
> filtering as the firewall would see only one direction of the communication.
> 

Fair question re routing rules. I asked myself the same question last 
night before the original post, and checked (because my memory isn't 
what it once was). The firewall's routing rules are (amongst other rules 
which I don't believe relevant -- and external interface name elided):

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i  -m conntrack --ctstate NEW   
-j ACCEPT

...which I think should allow it to route from the inside interface to 
the inside interface. It only refuses if the incoming interface is the 
external interface (the internet-facing one). I didn't exactly do that 
deliberately but the effect is the one I need here, I believe.

> > No, the airstation having been given an address 192.168.1.x/24 will know
> > that it can directly reach any host 192.168.1.1 through 192.168.1.254
> > inclusive.
> 
> Maybe I missed something but I read no evidence in the OP's posts that the
> netmask on the Airstation WAN side is actually /24. If for instance the mask
> was set to /30 instead, 192.168.1.3 would be considered by the Airstation as
> a broadcast address and would explain why it does not work.
> 
The netmask is 255.255.255.252. I just tried changing it to 248, ie 
zeroing out one more bit, but that did not help. (changed it by changing 
the netmask supplied by the firewall's DHCP server and then checking in 
the AirStation's web interface that the netmask had indeed changed).

Mark

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote:

[...]

> I read that some UEFI implementations allow the user to manage
> secure boot keys. Carefully choose your hardware.
> 
> Oh, by the way I forgot twice to mention another situation when an
> encrypted /boot would provide an advantage : when the machine has a
> platform firwmare which supports LUKS encryption, such as CoreBoot,
> then the on-disk boot components could be entirely encrypted.

Granted. But if I were *that* deep in the thicket, I'd either shell
out the 5K for a PowerPC workstation (which doesn't seem to have all
that ME stuff... or they don't tell you?) *or* wait for lowRISC or
similar. Doing encrypted-to-the-bottom in view of Intel ME or
AMD TrustZone has a bit of a futile taste to me.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCU5gACgkQBcgs9XrR2kbj9wCZAd7YWlsxOiJA5JlA0XBe3/D+
LQcAnjNhBcZ8HjM2Wm9rcpyVDSlM4iz4
=5ed9
-END PGP SIGNATURE-

Re: GRUB and boot partition

[Reco]

On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 13:58, Reco a écrit :
> > On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote:
> > > > > 
> > > > > Is there any inherent advantage to having /boot encrypted?
> > 
> > > The only things which might help against an evil maid attack [1] are:
> > > secure boot (tying your bootable to secure firmware) [3],
> > 
> > Restricted Boot (let's call the thing the way it should be called from
> > the start) could've solve this problem *if* it would be possible to
> > force it to verify the bootloader (or the kernel) signed with *user*
> > key.
> 
> I read that some UEFI implementations allow the user to manage secure boot
> keys. Carefully choose your hardware.

I'd use term 'elusive' to describe that kind of UEFI implementation.

Everything that can be bought here (I'm talking about x86 consumer-grade
hardware, of course) respects MSFT signing key only. If you're lucky,
your hardware has CSM (aka BIOS emulation mode).


> Oh, by the way I forgot twice to mention another situation when an encrypted
> /boot would provide an advantage : when the machine has a platform firwmare
> which supports LUKS encryption, such as CoreBoot, then the on-disk boot
> components could be entirely encrypted.

... and about the only trouble you have then is to locate that ThinkPad
x220 (the only relatively modern laptop model that supports CoreBoot
without a hassle I know of). Or a Chromebook if they still but SeaBIOS
inside those.

If you're preferring conventional desktop PC - you're out of luck with
CoreBoot.

Reco

Wanted -- installer meta-package(s)

[Richard Owlett]

I request readers take what I've written very literally. Thank you.


I have done an *EMPHATICALLY* minimal Stretch install (LT 800MB) to a 
partition.


I wish to use "apt-get install" to install *ONLY* packages that are 
required so that the installed system has EXACTLY one function - install 
Debian on another device or partition. An appropriate pool directory 
being provided elsewhere.


The initial desired result is that someone booting that system will be 
provided an almost identical experience to someone booting to DVD-1 of 
the Debian installer.


The "almost" in the previous paragraph is extremely important.
I have some strange views of what an OS for a very mall target audience 
should do. A very cumbersome preseed.cfg can approach many of my goals.

Re: Language of applications are not translated if the default language is changed

[Greg Wooledge]

On Sun, Dec 24, 2017 at 08:27:20AM +0100, Andre Majorel wrote:
> On 2017-12-23 19:21 +0100, john doe wrote:
> 
> > I have install Debian 9 using as the default language 'C'.
> > I want to add some new languages, and for this I do 'dpkg-reconfigure
> > locales'.
> > I'm currently using Gnome and Mate.
> > 
> > How can I add support for those new languages so all
> > applications will be translated in the desired language (using
> > command line is prefered)?
> 
> Have you tried setting LC_ALL appropriately (eg LC_ALL=fr_FR) in
> your .profile then logging out & in again ?

Do not use LC_ALL for this purpose.  It should be reserved for emergency
overrides on a single command basis.

Use the LANG variable to set your default locale and character set.

 describes the basic concepts and
procedures for selecting your locale.

In order to receive output in your preferred language, each application
needs to have been configured for localization *and* have a translation
mapping for your language.  The more common/popular a program is, the
more likely this is to be true, at least for the more common languages.

Re: GRUB and boot partition

[Pascal Hambourg]

Le 26/12/2017 à 13:58, Reco a écrit :

On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote:


Is there any inherent advantage to having /boot encrypted?



The only things which might help against an evil maid attack [1] are:
secure boot (tying your bootable to secure firmware) [3],


Restricted Boot (let's call the thing the way it should be called from
the start) could've solve this problem *if* it would be possible to
force it to verify the bootloader (or the kernel) signed with *user*
key.


I read that some UEFI implementations allow the user to manage secure 
boot keys. Carefully choose your hardware.


Oh, by the way I forgot twice to mention another situation when an 
encrypted /boot would provide an advantage : when the machine has a 
platform firwmare which supports LUKS encryption, such as CoreBoot, then 
the on-disk boot components could be entirely encrypted.

Re: GRUB and boot partition

[Reco]

On Tue, Dec 26, 2017 at 11:59:18AM +0100, to...@tuxteam.de wrote:
> On Tue, Dec 26, 2017 at 01:47:23PM +0300, Reco wrote:
> > Hi.
> > 
> > On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote:
> > > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> > > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit :
> > > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition
> > > > >ArchWiki has carried an introduction of GRUB , it offers a feature to 
> > > > >decrypt your partitions and you don't need to separate /boot . Debian 
> > > > >also uses GRUB as its boot loader ,but Debian still separates /boot 
> > > > >partition and leave it unencrypted
> > > 
> > > [...]
> > > 
> > > > Note however that in any case, the early part of GRUB cannot be
> > > > encrypted [...]
> > > 
> > > Is there any inherent advantage to having /boot encrypted?
> > 
> > Presumably it should help with scenario such as [1].
> 
> I don't see that: there must be an unencrypted bit at the beginning
> to boot and ask for the passphrase. Whether it's Grub's first stage
> (plus a bit) or it's a kernel plus initramfs, actually, shouldn't
> make a difference.

I don't see any difference too, hence I wrote 'presumably'.


> The only things which might help against an evil maid attack [1] are:
> secure boot (tying your bootable to secure firmware) [3],

There's this saying about curing a headache with an axe.
Restricted Boot (let's call the thing the way it should be called from
the start) could've solve this problem *if* it would be possible to
force it to verify the bootloader (or the kernel) signed with *user*
key.
But, the things being as they are, Restricted Boot is merely a tool to
achieve market dominance for a certain corporation.

Whenever Restricted Boot is broken or not is hardly relevant here.


> or carrying
> your boot media (e.g. SD card) with you, be it Grub+crypto, be it
> Grub+kernel+initramfs. Again, not much difference.

Indeed.

> 
> > But, as [2] shows us, the protection that's offered by encrypted boot is
> > incomplete as it relies on the fact that the bootloader (GRUB) was not
> > touched.
> 
> Seems we are in violent agreement, then :-)

True.


> [3] Given the games we've seen Intel play with their Management
>Engine lately...

I beg your pardon? Both Intel *and* AMD play this game for last eight
years since they invented TPM chip.

> would you trust them with that secure boot thing?
> I know wouldn't. And no, AMD ain't better.

It's really strange to answer such question here, at debian-user.
It's non-free software. Nobody sane should trust non-free software.

Reco

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 12:33, Dan Purgert a écrit :


Mark Fletcher wrote:

[...]
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
192.168.1.1, .2 and .3 -- note the third octet difference for internal


You seem to have set up a situation of double-NAT.  This means that
while 11.x can easily talk to a device on the 1.x network, the opposite
is not true.


Good thing, the OP just wants to talk to 192.168.1.x from 192.168.11.x, 
not the opposite.



Sounds like perhaps the airstation is blocking client devices from
talking to "bogus" network addresses.  This is generally a feature of
consumer gear to stop you from trying to ask the internet for
information about a RFC1918 address (as they are private / not routable
on the internet).


What do you mean by "ask the internet for information about a RFC1918 
address" ? Sending an IP packet is not asking the internet for any 
information.



Now 192.168.1.1 is the default gateway the firewall supplies the
AirStation (ie it supplies itself as the gateway) when the AirStation
makes a DHCP request, and I'm guessing that is why I can reach
192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I
am wondering if the AirStation somehow doesn't know that it can reach
192.168.1.3 directly, which I would expect it to since it is plugged
into the same switch as it and 192.168.1.1 -- and if so, how I would
persuade it to know that?


Being plugged to the same switch is not enough. The routing table must 
also contain a direct route to the destination.



I would also expect that if it did not know

that, it would send packets for 192.168.1.3 to 192.168.1.1 for
forwarding, just as it does every packet that is destined for the
internet -- and I would expect the firewall to be able to forward them,
since it can clearly see the PI.


A firewall usually has filtering rules. Do these rules allow packets to 
be forwarded from the LAN interface back to the same interface ?
Also, this would cause asymmetric routing (the server would send reply 
packets directly to the client), which may not work well with stateful 
filtering as the firewall would see only one direction of the communication.



No, the airstation having been given an address 192.168.1.x/24 will know
that it can directly reach any host 192.168.1.1 through 192.168.1.254
inclusive.


Maybe I missed something but I read no evidence in the OP's posts that 
the netmask on the Airstation WAN side is actually /24. If for instance 
the mask was set to /30 instead, 192.168.1.3 would be considered by the 
Airstation as a broadcast address and would explain why it does not work.

Re: Mixing and Matching DHCP and static IPs

[Mark Fletcher]

On Tue, Dec 26, 2017 at 20:40 Dan Purgert  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mark Fletcher wrote:
> > [...]
> > AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
> > 192.168.1.1, .2 and .3 -- note the third octet difference for internal
>
> You seem to have set up a situation of double-NAT.  This means that
> while 11.x can easily talk to a device on the 1.x network, the opposite
> is not true.


That’s what I expected, but that is not what I am getting — machines on
11.x can easily talk to 192.168.1.1 (and hence to the internet) but not to
192.168.1.3. There is no requirement for the PI to be able to initiate
connections back the other way.

>
> > Once I introduce the PI, (by plugging it into the switch, in case that
> > isn't obvious) I find I cannot reach it (by ping or by SSH) from inside
> > the LAN of my AirStation. For example, from my main Stretch desktop, I
> > cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to
> > the firewall at 192.168.1.1.
> >
> > If I SSH into the firewall, and then try to SSH from _there_ to
> > 192.168.1.3, I can connect no problem. And I log in to the PI to find it
> > bright eyed and bushy tailed, and able to connect to the internet (which
> > it must do through the firewall just as all traffic from the AirStation
> > does). But if I can't see it from the LAN, I can't use it for the
> > purpose I spent the last week of my life building it for... :(
>
> Sounds like perhaps the airstation is blocking client devices from
> talking to "bogus" network addresses.  This is generally a feature of
> consumer gear to stop you from trying to ask the internet for
> information about a RFC1918 address (as they are private / not routable
> on the internet).
>

So the trick would be to discourage it from thinking of 192.168.1.3 as
bogus... Do you think the earlier suggestion of having the PI’s IP address
handed out by the DHCP server on the firewall but using DHCP reservation to
make sure the PI gets a specific address would fix that?

Anyway I still have trying that ahead of me so will report back when I have.


> >
> > Now 192.168.1.1 is the default gateway the firewall supplies the
> > AirStation (ie it supplies itself as the gateway) when the AirStation
> > makes a DHCP request, and I'm guessing that is why I can reach
> > 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I
> > am wondering if the AirStation somehow doesn't know that it can reach
> > 192.168.1.3 directly, which I would expect it to since it is plugged
> > into the same switch as it and 192.168.1.1 -- and if so, how I would
> > persuade it to know that? I would also expect that if it did not know
> > that, it would send packets for 192.168.1.3 to 192.168.1.1 for
> > forwarding, just as it does every packet that is destined for the
> > internet -- and I would expect the firewall to be able to forward them,
> > since it can clearly see the PI.
>
>
> No, the airstation having been given an address 192.168.1.x/24 will know
> that it can directly reach any host 192.168.1.1 through 192.168.1.254
> inclusive.
>

Except for some reason it doesn’t seem to (or, rather, that is what APPEARS
to be the case but without answering some of Pascal’s earlier questions I
can’t say for certain that is what is going on). We know that 1.1 can reach
1.3, but 11.anything doesn’t seem to be able to, even though they can reach
1.1 . I just don’t know why yet.

Mark

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 12:33:36PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 12:24, to...@tuxteam.de a écrit :

[...]

> >In the days you measure (small) external media in gigabytes, this
> >argument has lost a lot of push.
> 
> What does storage size have to do with these situations ?

The other way around: if you keep the unencrypted bits in a separate
(or somehow specially secured) medium, a strict limitation on its
size might favour smaller (i.e. half a bootloader only) over fatter
(i.e. a whole bootloader plus a kernel plus an initramfs) solutions.

> >But yes, on some specialized hardware that might make a difference.
> >FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
> >the boot loader has become?
> 
> You can remove all the unneeded modules for features that you do not use.

Yes, yes, I know. Still... I don't like this overcomplex Grub. Scope
creep, if you ask me. Dealing with the "lower half" seems more than
enough. But there are tastes for everything :-)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCNiIACgkQBcgs9XrR2kYipQCfRSacDjIkHtzJj4h4wsQaz5VL
ju0An3UU+Pfuu5ogh8AdDKomtTKbV2Dt
=qoVI
-END PGP SIGNATURE-

Re: Mixing and Matching DHCP and static IPs

[Pascal Hambourg]

Le 26/12/2017 à 12:10, deloptes a écrit :


Looks like Airstation is WLAN router - I would put it infront of the
firewall and DMZ to the firewall


And lose the protection provided by the firewall to wireless devices ? 
Sounds like a great idea.



or you can turn off the firewall there completely


And push your logic to the limit : remove the protection for all 
devices, not only wireless ones.

Re: Mixing and Matching DHCP and static IPs

[Dan Purgert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark Fletcher wrote:
> [...]
> AirStation LAN is 192.168.11.0/24, outside AirStation LAN is 
> 192.168.1.1, .2 and .3 -- note the third octet difference for internal 

You seem to have set up a situation of double-NAT.  This means that
while 11.x can easily talk to a device on the 1.x network, the opposite
is not true.

> Once I introduce the PI, (by plugging it into the switch, in case that 
> isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
> the LAN of my AirStation. For example, from my main Stretch desktop, I 
> cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
> the firewall at 192.168.1.1.
>
> If I SSH into the firewall, and then try to SSH from _there_ to 
> 192.168.1.3, I can connect no problem. And I log in to the PI to find it 
> bright eyed and bushy tailed, and able to connect to the internet (which 
> it must do through the firewall just as all traffic from the AirStation 
> does). But if I can't see it from the LAN, I can't use it for the 
> purpose I spent the last week of my life building it for... :(

Sounds like perhaps the airstation is blocking client devices from
talking to "bogus" network addresses.  This is generally a feature of
consumer gear to stop you from trying to ask the internet for
information about a RFC1918 address (as they are private / not routable
on the internet).

>
> Now 192.168.1.1 is the default gateway the firewall supplies the 
> AirStation (ie it supplies itself as the gateway) when the AirStation 
> makes a DHCP request, and I'm guessing that is why I can reach 
> 192.168.1.1 from inside the LAN (ie the LAN side of the AirStation). I 
> am wondering if the AirStation somehow doesn't know that it can reach 
> 192.168.1.3 directly, which I would expect it to since it is plugged 
> into the same switch as it and 192.168.1.1 -- and if so, how I would 
> persuade it to know that? I would also expect that if it did not know 
> that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
> forwarding, just as it does every packet that is destined for the 
> internet -- and I would expect the firewall to be able to forward them, 
> since it can clearly see the PI.


No, the airstation having been given an address 192.168.1.x/24 will know
that it can directly reach any host 192.168.1.1 through 192.168.1.254
inclusive.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJaQjN0AAoJEI4R3fMSeaKBphsH/2LEj+7f49OPmcpz3HO/yjqU
bewELs1d0pWNWS6Tx92Wgy0RyL5j0NEqJIaz/FmmFu3gQ2wF2EZGwM7e1eUl3EJX
E0tdd1/pFDfBX54inKKWIwF1egj/vo4AVl8KzjXRRL7FWfp+pB0wm96f/yjj6qXV
knA6LuH6utJyI/jPqc3oyRUbB2KsTIvfLfyY5YhaN4uAZLWsk+ylKowYm13rys2d
8Lx7bi3ATRb6gR2UGQWY+6ddMOVtMp+b0FH0GUFp3NX3ppbqZkM2uTviBqxppzAZ
zLK5QewjMu99KhrVJcPAFTO/B8tfwUgP/cC0aCFJjkkkaqIOPVVKPp3g4V60mHE=
=0FzT
-END PGP SIGNATURE-

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: GRUB and boot partition

[Pascal Hambourg]

Le 26/12/2017 à 12:24, to...@tuxteam.de a écrit :


On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote:

Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit :


Is there any inherent advantage to having /boot encrypted?


I can imagine a few situations.

- When you can enforce the early stage of GRUB integrity by storing
it on removable or read-only boot media, checking it with trusted
computing, TPM...
You could extend this to the whole /boot directory contents instead
of encrypting it but parts of it such as the kernel image, initramfs
and grub.cfg change quite often, while GRUB itself seldom changes.
An alternative to /boot encryption is to sign its contents so that
GRUB early stage can check the files when loading them.

- When you need to store sensitive data in /boot, such as
passphrases for other encrypted volumes.


In the days you measure (small) external media in gigabytes, this
argument has lost a lot of push.


What does storage size have to do with these situations ?


But yes, on some specialized hardware that might make a difference.
FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
the boot loader has become?


You can remove all the unneeded modules for features that you do not use.

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 12:26:35PM +0100, Pascal Hambourg wrote:

[...]

> As explained in my previous reply, the difference is only in
> convenience. You need the boot media to be present and writable when
> updating when updating the kernel [...]

Yes, I see your point. Then, this one cuts both ways...

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCMu8ACgkQBcgs9XrR2kbDtQCfd8QyQBBPDEVRE0ytvuXtv9Mq
NJMAn3ZgzhugBAUCtX4C4+ihwO8TsBvX
=LO8n
-END PGP SIGNATURE-

Re: GRUB and boot partition

[Pascal Hambourg]

Le 26/12/2017 à 11:59, to...@tuxteam.de a écrit :


The only things which might help against an evil maid attack [1] are:
secure boot (tying your bootable to secure firmware)


Only if you replacy the default keys with your own key in the firmware. 
Any signed GRUB provided by Ubuntu, RedHat or openSUSE is accepted by 
UEFI secure boot with the default Microsoft key.



or carrying
your boot media (e.g. SD card) with you, be it Grub+crypto, be it
Grub+kernel+initramfs. Again, not much difference.


As explained in my previous reply, the difference is only in 
convenience. You need the boot media to be present and writable when 
updating when updating the kernel, initramfs and GRUB config file if 
/boot is stored on it. On the other hand, if /boot is stored (and 
encrypted) on the main disk, you do not need the boot media to be 
present and writable.

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit :
> >
> >On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> >>Note however that in any case, the early part of GRUB cannot be
> >>encrypted [...]
> >
> >Is there any inherent advantage to having /boot encrypted?
> 
> I can imagine a few situations.
> 
> - When you can enforce the early stage of GRUB integrity by storing
> it on removable or read-only boot media, checking it with trusted
> computing, TPM...
> You could extend this to the whole /boot directory contents instead
> of encrypting it but parts of it such as the kernel image, initramfs
> and grub.cfg change quite often, while GRUB itself seldom changes.
> An alternative to /boot encryption is to sign its contents so that
> GRUB early stage can check the files when loading them.
> 
> - When you need to store sensitive data in /boot, such as
> passphrases for other encrypted volumes.

In the days you measure (small) external media in gigabytes, this
argument has lost a lot of push. My whole boot at the moment is
37M, the smallest SD card I can come up at home is 256M, and we
kicked it out of our point-n-shoot camera because... 4G.

But yes, on some specialized hardware that might make a difference.
FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
the boot loader has become? How long until it needs dbus?), which
is an upper bound to the size of grub's "non-unencrypted" part
(dunno by how much).

Small embedded systems tend to have syslinux, though, or whatever
else you use on Arm ;-P

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCMYMACgkQBcgs9XrR2kYfNQCeLOeymSZxg4nghp+aEzUfmogJ
7HcAniw/ih+7TlWk5aNP21UQeJemAKoH
=Fvh7
-END PGP SIGNATURE-

Re: GRUB and boot partition

[Pascal Hambourg]

Le 26/12/2017 à 11:36, to...@tuxteam.de a écrit :


On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:

Note however that in any case, the early part of GRUB cannot be
encrypted [...]


Is there any inherent advantage to having /boot encrypted?


I can imagine a few situations.

- When you can enforce the early stage of GRUB integrity by storing it 
on removable or read-only boot media, checking it with trusted 
computing, TPM...
You could extend this to the whole /boot directory contents instead of 
encrypting it but parts of it such as the kernel image, initramfs and 
grub.cfg change quite often, while GRUB itself seldom changes. An 
alternative to /boot encryption is to sign its contents so that GRUB 
early stage can check the files when loading them.


- When you need to store sensitive data in /boot, such as passphrases 
for other encrypted volumes.

Re: Mixing and Matching DHCP and static IPs

[deloptes]

Mark Fletcher wrote:

> split -- there are essentially two splits because there are two
> firewalls -- one of which I want and one I can't turn off. The firewall
> I set up sits at the outermost edge of the network (obviously) and has 2
> interfaces. The other is at the AirStation, which regards its WAN port
> as the outside but that is actually connected to the inside of the real
> firewall.

Looks like Airstation is WLAN router - I would put it infront of the
firewall and DMZ to the firewall

something like this

[intranet] <---> eth1 [firewall] eth0 <> [extranet]
  ^--(DMZ)-> [AirStation/WLAN]

or you can turn off the firewall there completely 

AT home I have a router with WLAN from the Telco and my setup looks like
following

[intranet] <---> [firewall] <-- (DMZ) --> [Router + WLAN] <---> WAN
  ^---> WLAN

The DNS problem looks like you have to (again) work on the AirStation.

If you can not manage the AirStation - throw that crap away.

regards

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 01:47:23PM +0300, Reco wrote:
>   Hi.
> 
> On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote:
> > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit :
> > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition
> > > >ArchWiki has carried an introduction of GRUB , it offers a feature to 
> > > >decrypt your partitions and you don't need to separate /boot . Debian 
> > > >also uses GRUB as its boot loader ,but Debian still separates /boot 
> > > >partition and leave it unencrypted
> > 
> > [...]
> > 
> > > Note however that in any case, the early part of GRUB cannot be
> > > encrypted [...]
> > 
> > Is there any inherent advantage to having /boot encrypted?
> 
> Presumably it should help with scenario such as [1].

I don't see that: there must be an unencrypted bit at the beginning
to boot and ask for the passphrase. Whether it's Grub's first stage
(plus a bit) or it's a kernel plus initramfs, actually, shouldn't
make a difference.

The only things which might help against an evil maid attack [1] are:
secure boot (tying your bootable to secure firmware) [3], or carrying
your boot media (e.g. SD card) with you, be it Grub+crypto, be it
Grub+kernel+initramfs. Again, not much difference.

> But, as [2] shows us, the protection that's offered by encrypted boot is
> incomplete as it relies on the fact that the bootloader (GRUB) was not
> touched.

Seems we are in violent agreement, then :-)

I'm not really happy about the path the bootloader has taken, having to
understand different file systems, having a module system, etc.

Cheers

[1] http://searchsecurity.techtarget.com/definition/evil-maid-attack
[2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html
[3] Given the games we've seen Intel play with their Management
   Engine lately... would you trust them with that secure boot
   thing? I know wouldn't. And no, AMD ain't better.

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCK4YACgkQBcgs9XrR2kYWyQCeK01kZYgaeBxKDC9+0WQNpybr
Q1QAn3foaKmg4w4SqAqTmRP+ugX1OZsK
=0Qk0
-END PGP SIGNATURE-

Re: GRUB and boot partition

[Reco]

Hi.

On Tue, Dec 26, 2017 at 11:36:13AM +0100, to...@tuxteam.de wrote:
> On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> > Le 26/12/2017 à 02:47, microsoft gaofei a écrit :
> > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition
> > >ArchWiki has carried an introduction of GRUB , it offers a feature to 
> > >decrypt your partitions and you don't need to separate /boot . Debian also 
> > >uses GRUB as its boot loader ,but Debian still separates /boot partition 
> > >and leave it unencrypted
> 
> [...]
> 
> > Note however that in any case, the early part of GRUB cannot be
> > encrypted [...]
> 
> Is there any inherent advantage to having /boot encrypted?

Presumably it should help with scenario such as [1].
But, as [2] shows us, the protection that's offered by encrypted boot is
incomplete as it relies on the fact that the bootloader (GRUB) was not
touched.

[1] http://searchsecurity.techtarget.com/definition/evil-maid-attack
[2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html

Reco

Re: GRUB and boot partition

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 02:47, microsoft gaofei a écrit :
> >https://wiki.archlinux.org/index.php/GRUB#Boot_partition
> >ArchWiki has carried an introduction of GRUB , it offers a feature to 
> >decrypt your partitions and you don't need to separate /boot . Debian also 
> >uses GRUB as its boot loader ,but Debian still separates /boot partition and 
> >leave it unencrypted

[...]

> Note however that in any case, the early part of GRUB cannot be
> encrypted [...]

Is there any inherent advantage to having /boot encrypted?

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCJh0ACgkQBcgs9XrR2kaKHgCfd4gQR/kFEAuYIb+EHKgj/gzw
Lt4An2c+umNQMn8yDQ8GddyzO6WquVDM
=dHDa
-END PGP SIGNATURE-

Re: Out of root partition space

[Felix Miata]

Pascal Hambourg composed on 2017-12-26 10:20 (UTC+0100):

> Sarah Johnson composed:

>> so is it safe to resize debian root and other partitions using windows 
>> machine partitioning tool ?
...
> Before considering resizing partitions, the first step is to identify 
> what files and directories take space on the root partition and could be 
> removed.   

!!!

> Informations to gather :
> - partition layout
> fdisk -l
> - check free/used disk space
> df -hT
> - explore disk usage on the root filesystem
> du -hcxd1 / 

In addition, https://wiki.debian.org/FreeSpace is worth perusing before resizing
anything, particularly its package management cache references. If the
installation is more than a year old, package caching could account for half the
/ space consumed. Cleaning it could make further investigation, and to be sure
resizing, completely pointless.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: GRUB and boot partition

[Pascal Hambourg]

Le 26/12/2017 à 02:47, microsoft gaofei a écrit :

https://wiki.archlinux.org/index.php/GRUB#Boot_partition
ArchWiki has carried an introduction of GRUB , it offers a feature to decrypt 
your partitions and you don't need to separate /boot . Debian also uses GRUB as 
its boot loader ,but Debian still separates /boot partition and leave it 
unencrypted


Indeed the Debian installer does not allow an encrypted /boot partition. 
IMO it should be treated as a (strong) warning, not as a blocking error.


You can still manage to have /boot encrypted on Debian with extra manual 
steps. The Debian 8 installer had a flaw that could be exploited : it 
did not detect when /boot was an LVM logical volume in an encrypted PV. 
But this trick does not seem to work any more with the Debian 9 installer.


Note however that in any case, the early part of GRUB cannot be 
encrypted. It is that part which asks for the passphrase. If you use 
encryption only for confidentiality (in case of loss or theft of the 
computer), it probably does not matter that /boot is not encrypted, 
because it usually does not contain any sensitive data. But if you use 
encryption for tamper-proof, then encrypting /boot is not enough, 
because someone with physical access to the computer could tamper with 
the unencrypted part of GRUB and modify it to install a keylogger, 
rootkit...

Re: Out of root partition space

[Pascal Hambourg]

Le 26/12/2017 à 02:44, Sarah Johnson a écrit :

Hi,
I ran out of root partition disk space and can't install or remove any more 
packages or even login gui window manager anymore

i spent few good hours researching for solutions and found that i can resize 
root and home partitions using resize2fs and lvresize tools but they are not 
even installed on my system


resize2fs serves to resize an ext2/3/4 filesystem. It is part of the 
e2fsprogs package which is essential, so it must be installed. Anyway 
you can extend a filesystem only after extending its container 
(partition, logical volume or whatever).


lvresize serves to resize an LVM logical volume. It is part of the lvm2 
package which is automatically installed and required when you use LVM 
logical volumes during the system installation. If it is not installed, 
it means that the system does not have LVM logical volumes, so lvresize 
is useless.



so is it safe to resize debian root and other partitions using windows machine 
partitioning tool ?


No. Windows does not understand Linux filesystems.

Before considering resizing partitions, the first step is to identify 
what files and directories take space on the root partition and could be 
removed.


Informations to gather :
- partition layout
fdisk -l
- check free/used disk space
df -hT
- explore disk usage on the root filesystem
du -hcxd1 /