Re: 64bit ext4 and kernel version compatibility

[Klaus Singvogel]

R. Ramesh wrote:
> I want to make sure
> that my current kernel version does not have any limitation to support 64bit
> ext4.

Please consult the Kernel Wiki regarding Ext4:

https://ext4.wiki.kernel.org/index.php/Main_Page

You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
which was released a quiet long time ago (around 2009). As your
distribution is running 3.13.0-132-generic, the support of ext4 should be
no problem (never tested it to be 100% sure).

Another important information I was missing of: the machine architecture
of your processor; whether you're running a 64bit kernel or 32bit kernel.

"uname -m" will tell you, if you have 64bit, like in "x86_64", or not.

I'm very unsure, if your processor is able to address such files. PAE
extension (32 bit) of Intel architecture supports it, but not sure about
other archs, like Raspberry Pi v1 has.

Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if
this machine connects or is connectable from the internet, due to security
reasons.

Regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: web server for development

[Tixy]

On Thu, 2020-01-09 at 06:16 +, Russell L. Harris wrote:
> For development of a web pages, I installed Apache2 on another machine
> in the LAN so that I can FTP web pages from the development machine to
> the web server and view the pages from the development machine.

Do your pages use any server side facilities like PHP or server side
includes? If not, and your pages have purely static content, you can
just view your pages as plain files on your local machine, no need for
a web server.

-- 
Tixy

Re: Print Settings issue

[Klaus Singvogel]

kaye n wrote:
> The built-in Xsane scanner seemed to work at first, but now when I open it,
> I get:
> 
> Error during CMS conversion:
> Could not open scanner ICM profile.

https://www.google.com/search?q=scanner+ICM+profile

VG,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: 64bit ext4 and kernel version compatibility

[Tixy]

On Thu, 2020-01-09 at 09:02 +0100, Klaus Singvogel wrote:
> R. Ramesh wrote:
> > I want to make sure
> > that my current kernel version does not have any limitation to support 64bit
> > ext4.
> 
> Please consult the Kernel Wiki regarding Ext4:
> 
>   https://ext4.wiki.kernel.org/index.php/Main_Page
> 
> You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
> which was released a quiet long time ago (around 2009). As your
> distribution is running 3.13.0-132-generic, the support of ext4 should be
> no problem (never tested it to be 100% sure).

But features keep getting added to filesystems as time goes by and it's
quite possible that support for 64-bit block numbers wasn't included
from the start. The man page for e2fsprogs says this about the '64bit'
option: "Note that some older kernels and older versions of e2fsprogs
will not support file systems with this ext4 feature enabled"

-- 
Tixy

Re: apple mini

[Andy Smith]

Hello,

On Thu, Jan 09, 2020 at 12:11:54PM +1300, Ben Caradoc-Davies wrote:
> If you need to protect against an attacker willing to examine your HDD with
> magnetic force microscopy, there is no substitute for physical destruction
> of the media.

Even then it's unnecessary! No has ever recovered usable data from a
modern (less than 15 years old) used HDD after a single pass of
writes. A study was done with 2006-era drives and magnetic force
microscopy (MFM) between 2006 and 2008:

https://www.vidarholen.net/~vidar/overwriting_hard_drive_data.pdf

"4   Conclusion

The purpose of this paper was a categorical settlement to the
controversy surrounding the  misconceptions involving  the
belief  that  data  can  be  recovered following  a  wipe
procedure.  This  study  has  demonstrated that  correctly
wiped  data  cannot  reasonably  be  retrieved even  if  it  is
of  a  small  size  or  found  only  over small  parts  of  the
hard  drive. Not even with the use of a MFM or other known
methods. The belief that a tool can be developed to retrieve
gigabytes or terabytes of information from a wiped drive is in
error.

Although there is a good chance of recovery for any individual
bit from a drive, the chances of recovery of any amount of data
from a drive using an electron microscope are negligible. Even
speculating on the possible recovery of an old drive, there is
no likelihood  that  any data  would  be  recoverable  from  the
drive.  The  forensic recovery  of data using electron
microscopy is infeasible. This was true both on old drives and
has become more difficult over time. Further, there is a need
for the data to have been written and then wiped on a raw unused
drive for there to be any hope of any level of recovery even at
the bit level, which does not reflect real situations. It is
unlikely that a recovered drive will have not been used for a
period of time and the interaction of defragmentation,  file
copies  and  general  use  that overwrites  data  areas  negates
any  chance of data recovery. The fallacy that data can be
forensically recovered using an electron microscope or related
means needs to be put to rest."

So, for the main data areas of the HDD, one pass of writes is always
enough and anything more is just a meaningless ritual.

Some will argue that a better-funded attacker may somehow have
better microscopes even to the point that they have technological
breakthroughs not known to the wider world. However, the paper also
makes clear that the limit is not the sensitivity of the microscope,
but the fact that any drive that has been in use for a while has too
much noise for the data immediately prior to the wipe to be
distinguishable from that.

Cheers,
Andy

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

Re: apple mini

[Rick Thomas]

On Wed, Jan 8, 2020, at 6:57 PM, ghe wrote:
> 
> 
> > On Jan 8, 2020, at 07:46 PM, Michael Stone  wrote:
> > 
> >> If you need to protect against an attacker willing to examine your HDD 
> >> with magnetic force microscopy, there is no substitute for physical 
> >> destruction of the media.
> > 
> > Yes--if single-pass all-zeros erase isn't sufficient, the next step up is 
> > physical destruction, not multi-pass pattern mumbo-jumbo.
> 
> Back in the analog days, I worked at a college radio station that sent 
> out radio programs on tape. There was a big box that we passed a reel 
> of tape over to erase it. That box might do disks too :-)
> 
> Unless there was some magnetic magic written on the disk for the firmware.
> 
> -- 
> Glenn English

Yup!  Disk drives need (at least) some pre-formatting information on the media 
so the drive firmware can tell if it's on the right track.  In the old days, 
you could re-write that information by "formatting" the disk.  But these days 
that's all done at the factory and they don't want the consumer to even know 
about the existence of such things.

Bottom line:  If you tried the "big electromagnet" trick with a modern disk 
drive, you would render it useless.  I doubt that's what the OP wanted.

Rick

Re: Print Settings issue

[kaye n]

On Thu, Jan 9, 2020 at 4:17 PM Klaus Singvogel 
wrote:

> kaye n wrote:
> > The built-in Xsane scanner seemed to work at first, but now when I open
> it,
> > I get:
> >
> > Error during CMS conversion:
> > Could not open scanner ICM profile.
>
> https://www.google.com/search?q=scanner+ICM+profile
>
> VG,
> Klaus.
> --
> Klaus Singvogel
> GnuPG-Key-ID: 1024R/5068792D  1994-06-27
>

Thank you Klaus, this worked for me:
https://unix.stackexchange.com/questions/499249/error-during-cms-conversion-could-not-open-scanner-icm-profile

Good night!

Re: apple mini

[Michael Stone]

On Thu, Jan 09, 2020 at 10:11:15AM +, Andy Smith wrote:

Hello,

On Thu, Jan 09, 2020 at 12:11:54PM +1300, Ben Caradoc-Davies wrote:

If you need to protect against an attacker willing to examine your HDD with
magnetic force microscopy, there is no substitute for physical destruction
of the media.


Even then it's unnecessary! No has ever recovered usable data from a
modern (less than 15 years old) used HDD after a single pass of
writes.

[...]

So, for the main data areas of the HDD, one pass of writes is always
enough and anything more is just a meaningless ritual.

Some will argue that a better-funded attacker may somehow have
better microscopes even to the point that they have technological
breakthroughs not known to the wider world. However, the paper also
makes clear that the limit is not the sensitivity of the microscope,
but the fact that any drive that has been in use for a while has too
much noise for the data immediately prior to the wipe to be
distinguishable from that.


Physical destruction is recommended in three cases:

1) the drive is broken. overwriting a broken drive is hard.

3) the data is high value and needs to be protected "forever". this 
probably doesn't apply to you, but if it does it would be irresponsible 
to not destroy the drive. the liklihood of future advances making it 
possible to recover overwritten data may be low, but if the cost of 
destroying the drive is basically the value of an EOL drive (near zero) 
and the potential cost of the data being compromised is high, it makes 
no sense to not simply destroy the drive.


3) you need to wipe and verify that the data has been wiped on a large 
number of EOL hard drives. in many cases it is sufficient to sample hard 
drives after a wiping process, but for high value data if 100% wiping 
and verification is warranted it's probably more cost effective to shred 
the drives than pay for the labor to overwrite and verify the 
overwriting.

Re: 64bit ext4 and kernel version compatibility

[Reco]

Hi.

On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> Before I get the source and build and update e2fsprogs and then the
> file system, I want to make sure that my current kernel version does
> not have any limitation to support 64bit ext4.

You kernel should support the feature, as it was introduced back at the
version 3.6 of the kernel - [1].

Reco

[1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

Re: apple mini

[Michael Stone]

On Thu, Jan 09, 2020 at 09:22:09AM +0200, Andrei POPESCU wrote:

On Jo, 09 ian 20, 17:03:57, Ben Caradoc-Davies wrote:

On 09/01/2020 16:45, David Wright wrote:
> No, don't mix degaussers and disks. If you want to reuse them, they're
> likely too damaged. If you're concerned about data recovery, then they're
> unlikely to be erased enough to prevent it.

:

"For certain forms of computer data storage, however, such as modern hard
disk drives and some tape drives, degaussing renders the magnetic media
completely unusable and damages the storage system.


"unusable" is not the same as "all data is completely erased".


An old school tape deguasser (long conveyer belt with magnets 
underneath) may not have a sufficiently strong magnetic field to affect 
a modern hard drive at all. Or, it may prevent the drive from starting 
up due to destruction of the outermost tracks but not destroy data on 
inner tracks. There are products with much stronger magnetic fields 
which are specifically designed to destroy hard drive data. They're 
pretty quick and easy to use--much more so than hooking drives up and 
overwriting them. The biggest drawback is the difficulty in verifying 
that all data is destroyed. The most useful niche I can think of for 
them these days is if you need to return a broken hard drive that's been 
replaced under warranty and want to erase the data. In many (most?) 
cases it's likely that the "keep the drive" warranty option and physical 
destruction is cheaper and easier to verify.

Re: apple mini

[Jonathan Dowland]

On Wed, Jan 08, 2020 at 09:39:59PM -0500, Michael Stone wrote:
With a large block size dd will be limited by disk bandwidth for this 
use case. cp may hit the disk bandwidth limit or may not, depending on 
various factors which may not be obvious. Plus, dd is well understood 
for this purpose, and can be configured with nifty progress updates.  
:)


Yes. `dd` is a funny tool, since it's very "un-UNIXy" in some ways 
(weird command line foo=bar syntax). I *think* `cp` (at least GNU cp)

will adjust buffer sizes etc to be as optimal as possible. But come
to think of it, unless you specify (bad) values for `dd`, there's no
reason it couldn't also do that. My preference for `cp` for this purpose 
is reminding myself that the "everything is a file" design philosophy is 
still true, sometimes.


But perhaps there's value in having `dd` as "the tool you zero disks 
with". It means, when reaching for `dd`, you engage the mental mode of 
"careful to pick the right disk". Using plain `cp`, you would not 
necessarily do that.


--

Jonathan Dowland

Re: web server for development

[Greg Wooledge]

On Thu, Jan 09, 2020 at 06:16:51AM +, Russell L. Harris wrote:
> For development of a web pages, I installed Apache2 on another machine
> in the LAN so that I can FTP web pages from the development machine to
> the web server and view the pages from the development machine.
> 
> But the installation of Apache2 on Buster serves documents from
> /var/www/html/, which is owned by root, so as a normal user I cannot
> FTP into that directory.
> 
> The web server is not exposed outside the LAN, so security is not an
> issue.
> 
> What is the proper approach?

There is no single "proper" approach.  There are many approaches that
will work.  However, there are some steps you have to take first.

Step one: stop using FTP.

Step two: SERIOUSLY.  STOP USING FTP.

Step three: I REALLY REALLY MEAN IT.  IF YOU KEEP USING FTP, WE'RE DONE.


Approach one: You could just install apache2 on the development machine.
There's really no need to transfer the content to a second host, just
to bounce it back to the original host via HTTP.  Point the apache
configs at wherever your in-development content resides.

(For this approach and for all the other approaches, it doesn't *have*
to be apache2.  You could use nginx, or lighttpd, or any other web
server.)

Approach two: You could configure the web server on the second machine
to serve your content via a virtual host that's rooted somewhere other
than /var/www/html.  Then rsync your content to that location, using
whatever user account you've configured to have write access to that
location.

Approach three: You could give your user account ownership of, or
group write access to, /var/www/html on the second machine and rsync
your content there, if you are not using virtual hosts for some reason.

Re: apple mini

[John Hasler]

Jonathan writes:
> Yes. `dd` is a funny tool, since it's very "un-UNIXy" in some ways
> (weird command line foo=bar syntax).

That's because it is older than Unix.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: No sound with Pulseaudio

[Yoann LE BARS]

Hello everybody out there!

My apologies for having been silent so long, I have had some other
obligations. Anyway.

Le 06/01/2020 à 11:44, Selim T. Erdoğan a écrit :
> Try "systemctl stop timidity.service"

Well, I have done this and it seems Timidity has indeed stopped:

# lsof | grep /dev/snd/
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
alsactl573   root4r  CHR
116,7   0t0  17199 /dev/snd/controlC0

But the soundcard still does not appear in Pavucontrol. Therefore, I am
not so certain the problem comes from Timidity.

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Re: 64bit ext4 and kernel version compatibility

[Tixy]

On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > Before I get the source and build and update e2fsprogs and then the
> > file system, I want to make sure that my current kernel version does
> > not have any limitation to support 64bit ext4.
> 
> You kernel should support the feature, as it was introduced back at the
> version 3.6 of the kernel - [1].
> 
> Reco
> 
> [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

That web page is talking about metadata checksums I can't see anything
about '64-bit'. What I'm assuming the OP is interested is 64-bit block
numbers because they said they want to "convert ext4 fs on this server
to 64bit so that I can grow it past 16TB limit". Note from me, 4kB
sized blocks * 2^32 = 16TB, so block numbers whould need to be more
than 32-bit for bigger drives.

-- 
Tixy

Success of udev rule depends on if user has local or NIS account

[Christoph Pleger]

Hello,

I wrote the following udev rule:

ACTION=="add", SUBSYSTEM=="block", ATTRS{removable}=="1", 
PROGRAM="/lib/udev/foreground-user", RESULT!="root",MODE="0600", 
OWNER="$result"


The goal of this rule is to give a user who attaches a USB storage 
device while being logged on in the graphical environment exclusive 
access rights for the corresponding device nodes /dev/sd[a-z]* .


That was working as desired for some time, but now I discovered that is 
does not work correctly any more on some machines, on Debian 10 as well 
as in Ubuntu 18.04. Searching for the reason gave the result that the 
success of the udev rule depends on the kernel version (it worked in 
Ubuntu 18.04 with Kernel 4.15.0-50-generic, but does not work with 
Kernel 4.15.0-74-generic) as well as on if the user has a local or a NIS 
account, that is, it works with local accounts, but not with NIS 
accounts.


Does anybody know what happened in newer kernels that makes 
OWNER="$result" fail for NIS accounts?


Regards
  Christoph

Re: 64bit ext4 and kernel version compatibility

[Reco]

On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote:
> On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > > Before I get the source and build and update e2fsprogs and then the
> > > file system, I want to make sure that my current kernel version does
> > > not have any limitation to support 64bit ext4.
> > 
> > You kernel should support the feature, as it was introduced back at the
> > version 3.6 of the kernel - [1].
> > 
> > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
> 
> That web page is talking about metadata checksums I can't see anything
> about '64-bit'.

Let me read it for you (note kernel version):

Install Linux 3.6+ and e2fsprogs 1.43-WIP.
modprobe crc32c-intel
mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk


To enable "metadata_csum" in its full glory one needs to enable "64bit"
fs feature:

In a perfect world, one could simply enable metadata checksums ...
Therefore, it is best to start by formatting a fresh
filesystem with 64-bit support enabled ...


>What I'm assuming the OP is interested is 64-bit block numbers because
>they said they want to "convert ext4 fs on this server to 64bit so that
>I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 =
>16TB, so block numbers whould need to be more than 32-bit for bigger
>drives.

Same page says:

Therefore, it is best to start by formatting a fresh filesystem with
64-bit support enabled, since it is not possible to upgrade a 32-bit
filesystem to a 64-bit filesystem.


So if "convert" = "mkfs", then OP is fully set.
But then again, it's nothing that can't be solved by pre-existing
backup.

Reco

Re: Success of udev rule depends on if user has local or NIS account

[Greg Wooledge]

On Thu, Jan 09, 2020 at 05:56:53PM +0100, Christoph Pleger wrote:
> Does anybody know what happened in newer kernels that makes OWNER="$result"
> fail for NIS accounts?

At a guess, it's bug #878625 again.

Does it start working again if you install nscd, or one of its
alternatives?  Or if you override the IPAddressDeny=any in the
systemd-udevd.service unit?

Re: web server for development

[Greg Wooledge]

On Thu, Jan 09, 2020 at 06:29:57PM +, Russell L. Harris wrote:
> But I do have a web hosting account with Hostgator which provides
> shared hosting; and I am not aware of a mechanism other than FTP to
> get web content from here to that remote server.

If a web/storage provider doesn't offer at *least* SFTP access in 2020,
it's time to find a new provider.

Re: web server for development

[Dan Ritter]

Greg Wooledge wrote: 
> On Thu, Jan 09, 2020 at 06:29:57PM +, Russell L. Harris wrote:
> > But I do have a web hosting account with Hostgator which provides
> > shared hosting; and I am not aware of a mechanism other than FTP to
> > get web content from here to that remote server.
> 
> If a web/storage provider doesn't offer at *least* SFTP access in 2020,
> it's time to find a new provider.

https://www.hostgator.com/help/article/secure-ftp-sftp-and-ftps

TL;DR: they support SFTP, which is appropriate.


-dsr-

Re: Print Settings issue

[kaye n]

Hey Doug McGarrett

You're using a different distro so I'm not sure if I can help you, but I
would just like everyone to know that I think I've got it.  I am now able
to print over wifi, and scan with both Xsane and Image Scan over wifi.

If you search for your printer here,
http://download.ebz.epson.net/dsc/search/01/search/
 in my experience, if it doesn't say that it requires lsb, then you can
install it just fine.

If it says it requires lsb, then look at the Product Name, for example here:
http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=EN&CN2=&DSCMI=18787&DSCCHK=cd4ad419e3805cfac26d6492d12e38fc7da11822

you can see that the driver is shared among several printer models.  Go to
Print Settings, add printer and if you're printer model is not listed
there, choose a model that uses the same driver as YOUR printer, and
install it.

Same technique for the scanner driver.
Thanks!

On Thu, Jan 9, 2020 at 2:03 PM Doug McGarrett 
wrote:

>
>
> On 1/9/20 12:49 AM, kaye n wrote:
> > Hello Friends,
> >
> > I've given up on using imagescan. I was able to install it, but it just
> > could not detect the wifi printer, so I uninstalled it.
> >
> > The built-in Xsane scanner seemed to work at first, but now when I open
> > it, I get:
> >
> > Error during CMS conversion:
> > Could not open scanner ICM profile.
> >
> >
> >
> I'm running a different distro--OpenSUSE Tumbleweed--and I am having a
> lot or trouble tying to get to an Epson all-use printer, scanner, fax.
> I had used XSane Scanner on a different Linux which has been severely
> ruined (PCLOS) and it worked fine but I could never get it to scan with
> TW, and now I can't seem to get it to print either. Why is printing and
> scanning so difficult? VueScan doesn't find the scanner either.
>
> --doug
>

Re: web server for development

[Russell L. Harris]

On Thu, Jan 09, 2020 at 01:40:49PM -0500, Dan Ritter wrote:

Greg Wooledge wrote:

If a web/storage provider doesn't offer at *least* SFTP access in 2020,
it's time to find a new provider.



https://www.hostgator.com/help/article/secure-ftp-sftp-and-ftps
TL;DR: they support SFTP, which is appropriate.


I was using FTP in the generic sense.  In the past I have used the
Debian packages lftp and vsftp, but thanks for the exhortation to use
the SFTP protocol. 


RLH

iptables DROP before PREROUTING

[Jim Popovitch]

Hello!

Is there a way to have iptables DROP before PREROUTING.

Consider this bit of rules on a home firewall, where 24.126.xx.yy is my
home external IP address.

-
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -s 23.132.208.0/24 -j DROP

# DNAT inbound SSH to home PC
iptables  -A FORWARD -i eth0 -d 192.168.1.10 -m state --state 
NEW,ESTABLISHED,RELATED -j ACCEPT
iptables  -t nat -A PREROUTING -p tcp -d 24.126.xx.yy --dport 12345 -j DNAT 
--to-destination 192.168.1.10
iptables  -t nat -A POSTROUTING -s 192.168.1.10 ! -d 192.168.1.0/24 -j SNAT 
--to 24.126.xx.yy

iptables -A INPUT -j DROP


What I want to do is prevent 23.132.208.0/24 from accessing a service
(port 12345) on my home PC.  The problem is, the REROUTING rules preceed
the DROP rule, so the connections get through.  Thanks for any
suggestions/help.


-Jim P.

Re: iptables DROP before PREROUTING

[Reco]

Hi.

On Thu, Jan 09, 2020 at 02:46:25PM -0500, Jim Popovitch wrote:
> Is there a way to have iptables DROP before PREROUTING.

What you meant is "before PREROUTING in nat". It's an important bit, see
below.

> What I want to do is prevent 23.132.208.0/24 from accessing a service
> (port 12345) on my home PC.  The problem is, the REROUTING rules preceed
> the DROP rule, so the connections get through.  Thanks for any
> suggestions/help.

Try it (raw table is called before nat one):

iptables -t raw -A PREROUTING -s 23.132.208.0/24 -j DROP

Reco

Re: web server for development

[Russell L. Harris]

In this message, I respond to several suggestions:

On Thu, Jan 09, 2020 at 08:37:12AM -0500, Greg Wooledge & others wrote:

One way would be:
https://httpd.apache.org/docs/2.4/mod/mod_userdir.html


I thank you for the link.



More as an alternative to apache on an another host:
- using the built-in webserver in 'hugo'
- Python http.server


Thanks; I forgot about those.  My aspirations are for a simple static
web site, and I looked at hugo, jekyll, pelican, and other generators;
but I did not find one which suits my primary need, which is to work
hand-in-hand with LaTeX markup.  But that is a separate matter...



Do your pages use any server side facilities like PHP or server side
includes? If not, and your pages have purely static content, you can
just view your pages as plain files on your local machine, no need for
a web server.


I understand; that would work.  But I have a computer sitting unused,
and this gives me an excuse to install and get familiar with Buster
before switching this, my main machine, from Stretch to Buster.



Step one: stop using FTP.
Step two: SERIOUSLY.  STOP USING FTP.
Step three: I REALLY REALLY MEAN IT.  IF YOU KEEP USING FTP, WE'RE DONE.


You have my attention; I am all ears.

But I do have a web hosting account with Hostgator which provides
shared hosting; and I am not aware of a mechanism other than FTP to
get web content from here to that remote server.  That being the case,
I had no concern with using FTP within the confines of my LAN, which
is comprised of two computers, together with a firewall (ipFire).



Approach one: You could just install apache2 on the development machine.
There's really no need to transfer the content to a second host, just
to bounce it back to the original host via HTTP.  Point the apache
configs at wherever your in-development content resides.


I currently am doing that.


(For this approach and for all the other approaches, it doesn't *have*
to be apache2.  You could use nginx, or lighttpd, or any other web
server.)


I understand.



Approach two: You could configure the web server on the second machine
to serve your content via a virtual host that's rooted somewhere other
than /var/www/html.  Then rsync your content to that location, using
whatever user account you've configured to have write access to that
location.


This, I think, is the approach suggested by the first response.



Approach three: You could give your user account ownership of, or
group write access to, /var/www/html on the second machine and rsync
your content there, if you are not using virtual hosts for some
reason.


This is my first encounter with the term "virtual host"; but my first
inclination was to change ownership of /var/www/html, or to make use
of groups.


But now it seems that my first concern should be with FTP to the
server of Hostgator.  And in the case of a remote shared server, I
question whether rsync is an option.

RLH

Re: iptables DROP before PREROUTING

[Alexander V. Makartsev]

On 10.01.2020 00:46, Jim Popovitch wrote:
> Hello!
>
> Is there a way to have iptables DROP before PREROUTING.
>
> Consider this bit of rules on a home firewall, where 24.126.xx.yy is my
> home external IP address.
>
> -
> iptables -P INPUT DROP
> iptables -P OUTPUT ACCEPT
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
>
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> iptables -A INPUT -s 23.132.208.0/24 -j DROP
>
> # DNAT inbound SSH to home PC
> iptables  -A FORWARD -i eth0 -d 192.168.1.10 -m state --state 
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables  -t nat -A PREROUTING -p tcp -d 24.126.xx.yy --dport 12345 -j DNAT 
> --to-destination 192.168.1.10
> iptables  -t nat -A POSTROUTING -s 192.168.1.10 ! -d 192.168.1.0/24 -j SNAT 
> --to 24.126.xx.yy
>
> iptables -A INPUT -j DROP
> 
>
> What I want to do is prevent 23.132.208.0/24 from accessing a service
> (port 12345) on my home PC.  The problem is, the REROUTING rules preceed
> the DROP rule, so the connections get through.  Thanks for any
> suggestions/help.
>
>
> -Jim P.
>
>
>
>
I recommend you to look at this article. [1] It provides pretty good
explanations and complete iptables flow chart.
It will help you to understand how iptables work internally, so you will
have better understanding of where to place your rules and what those
rules should be.

The answer to your question, I believe, should look like this:
"iptables -I FORWARD -s 23.132.208.0/24 -j DROP"
This rule will be placed at first line in Forward chain of Filter table
and will Drop all traffic that comes from 23.132.208.0/24 subnet, after
it leaves Prerouting chain of Nat table.


[1]
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄ 

Re: No sound with Pulseaudio

[Georgi Naplatanov]

On 1/9/20 6:56 PM, Yoann LE BARS wrote:
> 
> Hello everybody out there!
> 
>   My apologies for having been silent so long, I have had some other
> obligations. Anyway.
> 
> Le 06/01/2020 à 11:44, Selim T. Erdoğan a écrit :
>> Try "systemctl stop timidity.service"
> 
>   Well, I have done this and it seems Timidity has indeed stopped:
> 
> # lsof | grep /dev/snd/
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
>   Output information may be incomplete.
> alsactl573   root4r  CHR
> 116,7   0t0  17199 /dev/snd/controlC0
> 
>   But the soundcard still does not appear in Pavucontrol. Therefore, I am
> not so certain the problem comes from Timidity.
> 

Hi,

something is wrong on that computer. This is output of mine:


$ fuser -v /dev/snd/*
 USERPID ACCESS COMMAND
/dev/snd/controlC0:  gosho  2067 F pulseaudio
/dev/snd/controlC1:  gosho  2067 F pulseaudio
/dev/snd/controlC2:  gosho  2067 F pulseaudio
/dev/snd/pcmC1D0p:   gosho  2067 F...m pulseaudio

Try this:
 - run as root
# alsactl init
 - restart the computer
 - then start alsamixer as ordinary user and tune all channels

HTH

Kind regards
Georgi

Re: iptables DROP before PREROUTING

[Jim Popovitch]

On Fri, 2020-01-10 at 01:52 +0500, Alexander V. Makartsev wrote:
> 
> The answer to your question, I believe, should look like this:
> "iptables -I FORWARD -s 23.132.208.0/24 -j DROP"

Thanks! That is what I am looking for.

To be clear, I'm doing something much more complex, but the underlying
issue is that blocked IPs (via ipsets and text file lists) were properly
DROPped by INPUT rules but were circumventing via the FORWARD and NAT
rules. 

-Jim P.

Re: Re: 64bit ext4 and kernel version compatibility

[R. Ramesh]

On Thu, Jan 09, 2020 at 05:06:29PM +, Tixy wrote:
> On Thu, 2020-01-09 at 14:35 +0300, Reco wrote:
> > On Wed, Jan 08, 2020 at 06:08:16PM -0600, R. Ramesh wrote:
> > > Before I get the source and build and update e2fsprogs and then the
> > > file system, I want to make sure that my current kernel version does
> > > not have any limitation to support 64bit ext4.
> > 
> > You kernel should support the feature, as it was introduced back at the

> > version 3.6 of the kernel - [1].
> > 
> > [1] https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
> 
> That web page is talking about metadata checksums I can't see anything

> about '64-bit'.

Let me read it for you (note kernel version):

Install Linux 3.6+ and e2fsprogs 1.43-WIP.
modprobe crc32c-intel
mkfs.ext4 -O metadata_csum,64bit /dev/path/to/disk


To enable "metadata_csum" in its full glory one needs to enable "64bit"
fs feature:

In a perfect world, one could simply enable metadata checksums ...
Therefore, it is best to start by formatting a fresh
filesystem with 64-bit support enabled ...


>What I'm assuming the OP is interested is 64-bit block numbers because
>they said they want to "convert ext4 fs on this server to 64bit so that
>I can grow it past 16TB limit". Note from me, 4kB sized blocks * 2^32 =
>16TB, so block numbers whould need to be more than 32-bit for bigger
>drives.

Same page says:

Therefore, it is best to start by formatting a fresh filesystem with
64-bit support enabled, since it is not possible to upgrade a 32-bit
filesystem to a 64-bit filesystem.


So if "convert" = "mkfs", then OP is fully set.
But then again, it's nothing that can't be solved by pre-existing
backup.

Reco


Reco,

  Thanks for the details. I do not know why, for a moment I thought 3.6 
> 3.13 (must have been treating version numbers as floating point 
numbers :-)


  No I do not plan to convert/grow in place. I have 2x8tb disks (and 
several other 4TB disks) for making backup. I will back up each md that 
is less than 16TB (separately) and make them 64bit first. After that I 
will grow them as needed.


Regards
Ramesh

Re: 64bit ext4 and kernel version compatibility

[R. Ramesh]

On 1/9/20 2:02 AM, Klaus Singvogel wrote:

R. Ramesh wrote:

I want to make sure
that my current kernel version does not have any limitation to support 64bit
ext4.

Please consult the Kernel Wiki regarding Ext4:

https://ext4.wiki.kernel.org/index.php/Main_Page

You will notice that Linux 2.6.28 was the first suppored kernel with ext4,
which was released a quiet long time ago (around 2009). As your
distribution is running 3.13.0-132-generic, the support of ext4 should be
no problem (never tested it to be 100% sure).

Another important information I was missing of: the machine architecture
of your processor; whether you're running a 64bit kernel or 32bit kernel.

"uname -m" will tell you, if you have 64bit, like in "x86_64", or not.

I'm very unsure, if your processor is able to address such files. PAE
extension (32 bit) of Intel architecture supports it, but not sure about
other archs, like Raspberry Pi v1 has.

Nevertheless, I stronlgy recommend to upgrade to 16.04 LTS or better, if
this machine connects or is connectable from the internet, due to security
reasons.

Regards,
Klaus.

Klaus,

  Thanks for your help. The last time I tried to upgrade to 16.04, my 
mythtv broke. I am sure I made some mistakes. I will ry once 20.04 is 
released to do a fresh install rather than upgrade from 14.04. That way 
I will manually install mythtv and do a database backup and restore. I 
have been lazy and not doing it right. This time I will be more thorough.


  May be I should delay 64bit conversion until then. Let me see, if I 
can manage delaying it till summer.


Regards
Ramesh

RE: Para Empleados en el 2020

[Sandra Munguia Reyes]

Te mando un saludo grande, les dejo un comunicado para los encargados de los 
comunicados en la Organización.

COMUNICACIÓN INTERNA e
IDENTIDAD CORPORATIVA
al estilo DISNEY

Ciudad de México / 24 de Enero 2020
Monterrey, N.L. / 31 de Enero 2020
Guadalajara, Jal. / 07 de Febrero 2020


CONOCE EL PROGRAMA MÁS DIVERTIDO, INNOVADOR Y DINÁMICO PARA CAMBIARLE EL CHIP A 
TU ORGANIZACIÓN.

¡Empieza a CREAR TU PROPIA MAGIA!


DESCARGAR FOLLETO COMPLETO

O solicita el folleto a través de WhatsApp en: Deseo información vía WhatsApp


O si usted lo prefiere comuníquese directamente con alguno de nuestros 
ejecutivos al:

800-890-86-65
55 24-50-61-87
33 36-32-63-11
(Contamos con más de 12 líneas a su servicio)























Este boletín informativo tiene como objetivo crear valor en usted y en su 
Organización. Si desea dejar de recibir este tipo de información
conteste con la palabra BAJADISNEY293. O en su defecto haciendo click en el 
siguiente enlace: unsubscribe from this list

Re: web server for development

[Nate Bargmann]

* On 2020 09 Jan 14:29 -0600, Russell L. Harris wrote:
> But now it seems that my first concern should be with FTP to the
> server of Hostgator.  And in the case of a remote shared server, I
> question whether rsync is an option.

I would ask if their Web host supports Secure FTP, which is FTP using
SSL, AIUI.  I use it for my Web Host updates, in fact it was recommended
by the host owner/operator.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

after installing viber, nowhere to be found?

[kaye n]

Hello friends,

My system is:
Host: laptop
Kernel: 4.19.0-6-amd64 x86_64
bits: 64
Desktop: Xfce 4.12.4
Distro: Debian GNU/Linux 10 (buster)

Following the instructions on this web page:
https://snapcraft.io/install/viber-unofficial/debian

I installed viber with these commands:
sudo apt update
sudo apt install snapd
sudo snap install viber-unofficial

It seemed successful, but I can't find it anywhere in the system.
Opening Application Finder and typing viber does nothing, neither in the
terminal.

Thank you!

Re: after installing viber, nowhere to be found?

[ghe]

> On Jan 9, 2020, at 10:28 PM, kaye n  wrote:
> 
> Hello friends,
> 
> My system is:
> Host: laptop 
> Kernel: 4.19.0-6-amd64 x86_64 
> bits: 64 
> Desktop: Xfce 4.12.4 
> Distro: Debian GNU/Linux 10 (buster)
> 
> Following the instructions on this web page:
> https://snapcraft.io/install/viber-unofficial/debian
> 
> I installed viber with these commands:
> sudo apt update
> sudo apt install snapd
> sudo snap install viber-unofficial
> 
> It seemed successful, but I can't find it anywhere in the system.
> Opening Application Finder and typing viber does nothing, neither in the 
> terminal.
> 
> Thank you!

Try 'sudo whereis viber' at the CLI? I have no explanation for its not showing 
up in the menu, but I'm pretty sure somebody else on this list has a great and 
accurate explanation :-)

-- 
Glenn English

Re: after installing viber, nowhere to be found?

[kaye n]

On Fri, Jan 10, 2020 at 1:45 PM ghe  wrote:

>
>
> > On Jan 9, 2020, at 10:28 PM, kaye n  wrote:
> >
> > Hello friends,
> >
> > My system is:
> > Host: laptop
> > Kernel: 4.19.0-6-amd64 x86_64
> > bits: 64
> > Desktop: Xfce 4.12.4
> > Distro: Debian GNU/Linux 10 (buster)
> >
> > Following the instructions on this web page:
> > https://snapcraft.io/install/viber-unofficial/debian
> >
> > I installed viber with these commands:
> > sudo apt update
> > sudo apt install snapd
> > sudo snap install viber-unofficial
> >
> > It seemed successful, but I can't find it anywhere in the system.
> > Opening Application Finder and typing viber does nothing, neither in the
> terminal.
> >
> > Thank you!
>
> Try 'sudo whereis viber' at the CLI? I have no explanation for its not
> showing up in the menu, but I'm pretty sure somebody else on this list has
> a great and accurate explanation :-)
>
> --
> Glenn English
>

Here it is.

kaye@laptop:~$ sudo whereis viber
[sudo] password for kaye:
viber:
kaye@laptop:~$

p7zip-full seems to be a built-in app for debian, but cannot be opened?

[kaye n]

Hello friends!

Searching for p7zip-full in synaptic, I can see that it is installed.

However I can't find it anywhere.

In the terminal:

kaye@laptop:~$ sudo whereis p7zip
[sudo] password for kaye:
p7zip: /usr/bin/p7zip /usr/lib/p7zip /usr/share/man/man1/p7zip.1.gz

but is that the full version? and how can I execute it?

Thank you for your time.
Kaye

Re: after installing viber, nowhere to be found?

[ghe]

> On Jan 9, 2020, at 10:57 PM, kaye n  wrote:
> 
> Here it is.
> 
> kaye@laptop:~$ sudo whereis viber
> [sudo] password for kaye: 
> viber:

It's not on the machine. That explains q lot.

A new install might be in order. Try aptitude or maybe synaptic -- something 
that talks a little more than apt-get.

Hmm. On my box (Buster) aptitude claims there is nothing called 
viber- at any of my mirrors. I think you need more help than I can 
provide. Can anybody help OP?

-- 
Glenn English

Re: p7zip-full seems to be a built-in app for debian, but cannot be opened?

[tomas]

On Fri, Jan 10, 2020 at 02:15:21PM +0800, kaye n wrote:
> Hello friends!
> 
> Searching for p7zip-full in synaptic, I can see that it is installed.
> 
> However I can't find it anywhere.
> 
> In the terminal:
> 
> kaye@laptop:~$ sudo whereis p7zip
> [sudo] password for kaye:
> p7zip: /usr/bin/p7zip /usr/lib/p7zip /usr/share/man/man1/p7zip.1.gz

I don't think you need 'sudo' for whereis.

> but is that the full version? and how can I execute it?

Try (in the shell):

  apt search p7zip

It'll show you the packages matching p7zip and whether they're installed.

Cheers
-- tomás


signature.asc
Description: Digital signature