Re: mailing list vs "the futur"

[Dan Purgert]

Michael Stone wrote:
> On Wed, Aug 29, 2018 at 12:18:59AM +0100, Mark Rousell wrote:
> [...]
> FWIW, I think SMTP (and IMAP) is on its way out as well.

What would SMTP get replaced with?  I mean, email is still kind of a big
thing (at least in business).


-- 
|_|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: mailing list vs "the futur"

[Michael Stone]

On Wed, Aug 29, 2018 at 12:18:59AM +0100, Mark Rousell wrote:

I have at no stage advocated a "generic architecture of NNTP transit servers".

I have at no stage advocated any NNTP servers being "open to arbitrary groups",
other than those created by group owners.


[snip long list of other things you haven't said]

You're right; the problem is that you haven't said much at all of any 
substance, so I find myself trying to guess how the vague things you do
say could possibly map to anything in the real world. I'll stop doing 
that.



Fine, so you prefer web UIs, if I understand you correctly.


No, I hate them. But I'm a realist and I understand why things are 
evolving the way they are.



   So the "broad client support" in question would be a web browser and that
   basically includes everything. Welcome to the 21st century!


Except that web browsers accessing web forums in the 21st Century don't do
everything. They can't. Other tools do some things better. That's rather the
point. There are other tools that bring other capabilities to the table. For
example, some of these tools are the NNTP and SMTP and IMAP protocols


FWIW, I think SMTP (and IMAP) is on its way out as well. I expect that 
in 20 years HTTP will still be going strong but SMTP will be a legacy 
protocol with dwindling recognition (the way NNTP is today). The 
theories about the superiority of NNTP and SMTP and IMAP are less 
compelling than the reality that the class of protocols designed for the 
internet of the 1980s are too susceptible to abuse for use on the modern 
internet. If SMTP does have a strong presence in 20 years it will 
probably be in a form that isn't interoperable with a 2018 SMTP 
implementation. (Which is not entirely impossible; unlike NNTP, SMTP 
isn't too moribund to evolve. I think it's just unlikely to evolve 
enough.)


Most people currently under the age of 20 probably won't notice that it's gone.

Re: mailing list vs "the futur"

[Miles Fidelman]

On 8/28/18 5:24 PM, Mark Rousell wrote:

I was going to say that you and I have started going round in circles 
and should just agree to disagree about certain things but this is a 
different strand of the discussion that still seems to be advancing.


On 28/08/2018 20:01, Michael Stone wrote:

On Tue, Aug 28, 2018 at 04:46:15PM +0100, Mark Rousell wrote:
web forums, app-based, IM-style, etc.) but none of that, to my mind, 
lessens
NNTP's ideal applicability to getting private discussion group 
messages from

place to place (the front end UI/UX being a different thing again).


Ignoring the changes to user requirements for UI/UX is at least part 
of why NNTP is no longer a major factor in internet usage.


Last time I looked, Thunderbird & Exchange both support news - a 
newsgroup looks just like another email account.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Ben Finney]

Francesco Porro  writes:

> Sorry, I forgot to mention that I dont't want to run a mail server by
> myself.
>
> Only *free* mail services, please.

In that case, I recommend against all such services.

The cost of running a mail server that anyone can join for no fee,
practically requires that the operators must make lots of money
exploiting the email users.

So your options are:

* Pay for the valuable service of running an email system, with you as
  the customer, and with a direct interest in not screwing you over.

* Find someone you trust to never screw you over (maybe this is
  yourself), and get that person to put in lots of time and expertise
  operating a mail system indefinitely for you.

* Use a zero-fee email service that is practically guaranteed to exploit
  its users in many ways.

I strongly recommend against the third option.

-- 
 \  “I got an answering machine for my phone. Now when someone |
  `\  calls me up and I'm not home, they get a recording of a busy |
_o__)  signal.” —Steven Wright |
Ben Finney

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 23:25, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 10:24:51PM +0100, Mark Rousell wrote:
>>If you have a bunch of users on remote SMTP and NNTP servers then
>> it's
>>always a wash. (MUAs don't typically download the entire message body
>>unless asked to, just as news readers don't typically download the
>> entire
>>message body unless asked to.) Basically, the efficiency argument
>> is bogus.
>>
>>
>> I can only say that I disagree that the bandwidth efficiency is bogus
>> overall.
>>
>> If by "remote [...] NNTP servers" you mean other NNTP servers that are
>> federated with your own, then this is surely a bandwidth saving
>> compared to
>> email. I.e. The data only needs to be sent once to the remote NNTP
>> servers for
>> local distribution to users who connect to those servers, thus reducing
>> bandwidth usage overall.
>
> No, because the idea of having ISPs set up NNTP transit servers for
> individual small discussion groups is...unlikely at best.

Well, I expect you're not going to like me saying this but isn't
expecting ISPs to do this more Usenet-style thinking? People don't
expect ISPs to run forum servers or mail list servers, so why should
they expect them to run NNTP servers for private discussions groups?

> so stop talking about 'a generic architecture of NNTP transit servers
> that isn't usenet but is still open to arbitrary groups and users but
> doesn't have any of the problems of usenet because it's carefully
> controlled and thus doesn't have abuse issues but isn't prohibitively
> resource intensive and people will set up serves and join the network
> because nobody likes stupid old HTTP anyway'

I have at no stage advocated a "generic architecture of NNTP transit
servers".

I have at no stage advocated any NNTP servers being "open to arbitrary
groups", other than those created by group owners.

I have at no stage suggested that it wouldn't have abuse issues, only
that abuse issues can be handled just as they are right now on any
non-federated NNTP server, on any mail list, on any web forum, or similar.

Indeed, NNTP is not prohibitively resource intensive when used as a
private discussion group protocol. You got that bit right.

I have at no stage suggested that people necessarily would want to set
up their own servers (although in principle they could). This sort of
thing is more likely to be run as a service, just as mail servers, mail
list services, and web forums often are at present.

And I have at no stage suggested that people don't like HTTP.

What I have been talking about (since I mentioned I'll be working on
NNTP) is implementing NNTP as an alternative access methodology to
message resources accessible via other means as well. There's more to
the project than that but this is the aspect that seem related to this
thread.

> and instead start talking about something that's likely to be
> implemented: centralized NNTP gateways to the services most people
> will use via SMTP or HTTP, with NNTP client access to the gateway.

This sounds a bit like trying to reinvent Usenet. It's not going to
happen that way.

> You might see people create private transit servers for local access,
> but the number of clients using such servers instead of the primary
> one would suggest de minimis bandwidth savings. If anything, the
> private transit servers would end up like most private debian archive
> mirrors and consume more bandwidth than they save (because most of the
> transferred files never get used). And in this model, any putative
> "transfer efficiency of NNTP" is simply not compelling.

Quite possibly. Although we've discussed the bandwidth efficiency of
NNTP at excessive length, it's admittedly not the primary driving
motivation for this work.

But, all the same, if bandwidth efficiency is an issue then I'd say that
NNTP is good for this scenario. YMMV of course, and that's fine.

>
> It's so incredibly uncommon to find a REST based discussion forum that
> doesn't come with its own HTML UI that I don't consider it worth
> considering.

Fine, so you prefer web UIs, if I understand you correctly.

> So the "broad client support" in question would be a web browser and
> that basically includes everything. Welcome to the 21st century!

Except that web browsers accessing web forums in the 21st Century don't
do everything. They can't. Other tools do some things better. That's
rather the point. There are other tools that bring other capabilities to
the table. For example, some of these tools are the NNTP and SMTP and
IMAP protocols, and these can be accessed by mail clients and NNTP
clients. These protocols and clients facilitate users who prefer these
tools to do things like choose their own client apps, control how their
UI appears, manage who they view and store data, and so on. These
approaches provide way more capability and are way more flexible than
any web forum's HTML UI.

Earlier in this very thread, Rich Kulawiec posted this extensive list of

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Stefan Krusche]

Am Mittwoch, 29. August 2018 schrieb Dominic Knight:
> > > have to log in via their website interface to free them out of the
> > > spam
> > > folder to be able to download them with my precious email client.
> > > I've
>
> That's the fault of your email client or methodology, rather than GMX.
> Mine has the spam folder available on the client where they can be
> viewed, moved or deleted - Evolution/IMAP

Right, I could configure my client to use IMAP.

Thanks,
Stefan

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 10:24:51PM +0100, Mark Rousell wrote:

   If you have a bunch of users on remote SMTP and NNTP servers then it's
   always a wash. (MUAs don't typically download the entire message body
   unless asked to, just as news readers don't typically download the entire
   message body unless asked to.) Basically, the efficiency argument is bogus.


I can only say that I disagree that the bandwidth efficiency is bogus overall.

If by "remote [...] NNTP servers" you mean other NNTP servers that are
federated with your own, then this is surely a bandwidth saving compared to
email. I.e. The data only needs to be sent once to the remote NNTP servers for
local distribution to users who connect to those servers, thus reducing
bandwidth usage overall.


No, because the idea of having ISPs set up NNTP transit servers for 
individual small discussion groups is...unlikely at best. You've already 
stipulated that you don't want to talk about usenet, so stop talking 
about 'a generic architecture of NNTP transit servers that isn't usenet 
but is still open to arbitrary groups and users but doesn't have any of 
the problems of usenet because it's carefully controlled and thus 
doesn't have abuse issues but isn't prohibitively resource intensive 
and people will set up serves and join the network because nobody likes 
stupid old HTTP anyway' and instead start talking about something that's likely 
to be implemented: centralized NNTP gateways to the services most people 
will use via SMTP or HTTP, with NNTP client access to the gateway. You 
might see people create private transit servers for local access, but 
the number of clients using such servers instead of the primary one 
would suggest de minimis bandwidth savings. If anything, the private 
transit servers would end up like most private debian archive mirrors 
and consume more bandwidth than they save (because most of the 
transferred files never get used). And in this model, any putative 
"transfer efficiency of NNTP" is simply not compelling.



I know you know this but I'll say it anyway: REST isn't a single protocol, it's
just a type of protocol. There are loads of REST-based protocols around. Which
one do you choose? There are no standardised REST protocols for message
distribution that I am aware of. There's nothing REST-based that is like SMTP,
or POP3, or IMAP, or NNTP, or anything else that has broad client support
across a range of device types in this context.


It's so incredibly uncommon to find a REST based discussion forum that 
doesn't come with its own HTML UI that I don't consider it worth 
considering. So the "broad client support" in question would be a web 
browser and that basically includes everything. Welcome to the 21st 
century! Then, if your content is compelling enough, people will use 
whatever wacky REST API they need to get your content if they want to go 
beyond the HTML UI. I'd guess that the number of people using google 
APIs (for example) today, whether knowingly or unknowingly, exceeds the 
total number of people that ever used NNTP, even if those people just 
don't understand how things would be better if they were using NNTP 
instead. If you meant to talk only about dedicated protocol-specific 
thick clients, then yeah, there probably aren't as many for specific web 
forums as there are clients for SMTP, POP3, IMAP, or NNTP. But most 
people don't really care. (Yes, I've gathered by this point that your 
number one requirement is the ability to use an NNTP client--I'm 
referring to the other people.)



hopefully inoffensive manner.


Sorry, no. 

But anyway, I get that you really really like NNTP. Have fun, don't 
expect a lot of converts.

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Dominic Knight]

On Tue, 2018-08-28 at 21:33 +0100, Brad Rogers wrote:
> On Tue, 28 Aug 2018 22:23:46 +0200
> Stefan Krusche  wrote:
> 
> Hello Stefan,
> 
> > have to log in via their website interface to free them out of the
> > spam
> > folder to be able to download them with my precious email client.
> > I've
> 
That's the fault of your email client or methodology, rather than GMX.
Mine has the spam folder available on the client where they can be
viewed, moved or deleted - Evolution/IMAP

> Is it not possible to whitelist the addresses?
> 
> > recently started to think this provider *wants* me to have to log
> > in
> > and use the website 
> 
> Of course they do.
> 
I've only had to log in once this year and that was for an upload into
my music folder. While I'm sure they would love you to log in and see
the 'adds' they provide, they never _require_ me to do so.

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Stefan Krusche]

Am Dienstag, 28. August 2018 schrieb Brad Rogers:
> On Tue, 28 Aug 2018 22:23:46 +0200
> Stefan Krusche  wrote:

> >have to log in via their website interface to free them out of the spam
> >folder to be able to download them with my precious email client. I've
>
> Is it not possible to whitelist the addresses?

Yes, it is, and being done automatically when you move mails out of the spam 
folder, I think, it's just always another sender which gets sorted out as spam. 
I never saw this happening until about a year ago or so. They probably changed 
their configuration or policy of treating free mail accounts, I think.

Cheers!

default grub config location for PXE UEFI boot

[rbraun204]

Hey guys,  I'm trying to setup isc-dhcp-server/tftpd-hpa for PXE UEFI
netboot installs.  I have a working config for bios PXE installs,  but
am trying to convert it over to allow for UEFI installs aswell.
Currently,  I can PXE boot UEFI clients,  but end up with a bare grub
prompt.   I'm just not sure where and what the default grub config
file is supposed to go.

Also,  we have a mix of bios/UEFI machines,  would I need to maintain
a separate boot config file for both bios/uefi pxe mode?  Or can I
just symlink it once I get the proper location determined?  I've found
some config snippets for the dhcp service to serve both bios and uefi
payloads at the same time,  but haven't got there yet.

My tftp root looks like so.

lrwxrwxrwx 1 root root37 Aug 22 17:23 bootnetx64.efi ->
debian-installer/amd64/bootnetx64.efi
drwxrwxr-x 3 tftp tftp  4096 Jul 11 03:19 debian-installer
lrwxrwxrwx 1 tftp tftp47 Jul 11 03:19 ldlinux.c32 ->
debian-installer/amd64/boot-screens/ldlinux.c32
-rw-r--r-- 1 tftp tftp 26664 Jul 27 19:37 memdisk
lrwxrwxrwx 1 tftp tftp33 Jul 11 03:19 pxelinux.0 ->
debian-installer/amd64/pxelinux.0
lrwxrwxrwx 1 tftp tftp35 Jul 11 03:19 pxelinux.cfg ->
debian-installer/amd64/pxelinux.cfg
-rw-r--r-- 1 tftp tftp 21198 Aug  7 16:21 stretch-pxe.cfg
-rw-rw-r-- 1 tftp tftp62 Jul 11 03:19 version.info

Some googling led me to believe the config file for UEFI pxe booting
is called efidefault.  I've tried dropping that config in several
directories without much luck.  Tried turning verbosity up in tftpd-ha
to determine what file is trying to be pulled,   but the tftp logs
only show a transfer of bootnetx64.efi and no other attempts at a
config file.

Thanks for the help.

Re: mailing list vs "the futur"

[Mark Rousell]

I was going to say that you and I have started going round in circles
and should just agree to disagree about certain things but this is a
different strand of the discussion that still seems to be advancing.

On 28/08/2018 20:01, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 04:46:15PM +0100, Mark Rousell wrote:
>> web forums, app-based, IM-style, etc.) but none of that, to my mind,
>> lessens
>> NNTP's ideal applicability to getting private discussion group
>> messages from
>> place to place (the front end UI/UX being a different thing again).
>
> Ignoring the changes to user requirements for UI/UX is at least part
> of why NNTP is no longer a major factor in internet usage.

I agree to a considerable extent and I don't think I advocated ignoring
changes to user requirements for UI/UX. When I say "the front end UI/UX
being a different thing again" I mean that it's a different discussion,
not that a designer should ignore it.

And making NNTP available as an access method (certainly not a sole
access method) is not ignoring it.

>
>> The key advantage of NNTP over email/SMTP in terms of bandwidth
>> efficiency is
>> that, with NNTP, messages are only sent to users when they explicitly
>> ask for
>> them. This is more bandwidth-efficient than an email-based list since
>> the
>> email-based list must send out messages to each and every user
>> whether or not
>> they want them.
>
> It's more efficient at the provider level until someone decides they
> want all of the messages local, either as an archive or to run local
> search tools, etc. At that point you're transferring all of the
> messages just as you would via SMTP and it's basically a wash.

That's fine. Not everyone wants that but, for those who do, it's
certainly no worse than email. So I don't see it as a problem.

> If you have a bunch of users on remote SMTP and NNTP servers then it's
> always a wash. (MUAs don't typically download the entire message body
> unless asked to, just as news readers don't typically download the
> entire message body unless asked to.) Basically, the efficiency
> argument is bogus.

I can only say that I disagree that the bandwidth efficiency is bogus
overall.

If by "remote [...] NNTP servers" you mean other NNTP servers that are
federated with your own, then this is surely a bandwidth saving compared
to email. I.e. The data only needs to be sent once to the remote NNTP
servers for local distribution to users who connect to those servers,
thus reducing bandwidth usage overall.

> the bandwidth in question is so small as to not matter anyway.(We call
> this "premature optimization"; there are other concerns that are far
> more significant--like the UI/UX.) The entire 25 year archive of
> debian lists is probably on the order of one or two netflix movies.

Whilst I agree that UI/UX are important to users (which of course is
exactly why many prefer to receive their message via NNTP, so that they
can control their UI/UX), it is not necessarily the case that bandwidth
is always small. A static archive is not the bandwidth.

>
>> To my mind, a REST protocol has a different (but overlapping) use
>> case to NNTP
>> or email lists. I know of no standard, open REST protocol that
>> replaces either
>> NNTP or email discussion lists, for example.
>
> But there are a heck of a lot more deployed REST clients than NNTP
> clients.

I know you know this but I'll say it anyway: REST isn't a single
protocol, it's just a type of protocol. There are loads of REST-based
protocols around. Which one do you choose? There are no standardised
REST protocols for message distribution that I am aware of. There's
nothing REST-based that is like SMTP, or POP3, or IMAP, or NNTP, or
anything else that has broad client support across a range of device
types in this context.

Or is there? Have I overlooked anything?

Furthermore, there's no point saying that there are other protocols when
those other protocols do not and cannot address the use case that one
particular protocol, NNTP in this case, can and does address.

I am not saying that REST does not have its place. It's just that NNTP
(alongside other protocols and types of protocol, both standardised and
proprietary) is something that fulfils a currently commonly unfilled use
case, one that in fact does have demand.

> You can shake your fist at the cloud all you want, but reality is what
> it is. Consequently, a good experience for HTTP consumers is going to
> be a higher priority than NNTP users.

There are many possible priorities and different businesses and services
providers have different customer bases who have different sets of
priorities. I've not said that a web browser-based UI is unimportant (in
fact I think you'll note I've said that it is important for most users)
but that doesn't mean that a variety of access methodologies are not
also important.

> The numbers are so skewed as to raise valid questions about whether
> the small number of NNTP users is worth committing development 

Re: Re : Répertoire avec des noms étranges à la racine : -ffffffffffffffff-0000000000

[Belaïd]

Bonsoir,

Selon le résultat "SMART overall-health self-assessment test result:
PASSED" l'auto-evaluation de la santé du disque n'a pas donné de mauvais
résultats.  Tu peux utiliser l'utilitaire Disks pour une évaluation en mode
graphique



Le mar. 28 août 2018 21:11, bidons59  a écrit :

>
>
> Le 28/08/2018 à 18:46, nicolas.patr...@gmail.com a écrit :
> > Le 28/08/2018 17:02:39, Fabrice Delvallée a écrit :
> >
> >> Je viens de trouver de deux répertoires aux noms étranges à la racine
> >> de ma Debian stretch :
> >
> > […]
> >
> >> Bien sur j'ai aucune idée de ce que je faisait le 15 août vers
> >> 11h18...
> >
> >> Est-ce grave docteur ?
> >
> > Vérifie ton disque avec gsmartcontrol.
> >
> > nicolas patrois : pts noir asocial
> >
> J'avoue ne pas être un spécialiste de smart. J'ai effectué un test
> 'Short offline' puis un 'Extended Slef-test'
>
> Je pollue la liste avec la sortie:
>
> smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.17.0-0.bpo.1-amd64] (local
> build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Model Family: Samsung based SSDs
> Device Model: Samsung SSD 840 PRO Series
> Serial Number:S1ANNEAD626089P
> LU WWN Device Id: 5 002538 5503a72e3
> Firmware Version: DXM05B0Q
> User Capacity:128,035,676,160 bytes [128 GB]
> Sector Size:  512 bytes logical/physical
> Rotation Rate:Solid State Device
> Device is:In smartctl database [for details use: -P show]
> ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
> SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
> Local Time is:Tue Aug 28 21:07:56 2018 CEST
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> SMART overall-health self-assessment test result: PASSED
>
> General SMART Values:
> Offline data collection status:  (0x00) Offline data collection activity
> was never started.
> Auto Offline Data Collection:
> Disabled.
> Self-test execution status:  (   0) The previous self-test routine
> completed
> without error or no self-test has
> ever
> been run.
> Total time to complete Offline
> data collection:(0) seconds.
> Offline data collection
> capabilities:(0x53) SMART execute Offline immediate.
> Auto Offline data collection
> on/off support.
> Suspend Offline collection upon new
> command.
> No Offline surface scan supported.
> Self-test supported.
> No Conveyance Self-test supported.
> Selective Self-test supported.
> SMART capabilities:(0x0003) Saves SMART data before entering
> power-saving mode.
> Supports SMART auto save timer.
> Error logging capability:(0x01) Error logging supported.
> General Purpose Logging supported.
> Short self-test routine
> recommended polling time:(   2) minutes.
> Extended self-test routine
> recommended polling time:(  15) minutes.
> SCT capabilities:  (0x003d) SCT Status supported.
> SCT Error Recovery Control
> supported.
> SCT Feature Control supported.
> SCT Data Table supported.
>
> SMART Attributes Data Structure revision number: 1
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE
> UPDATED  WHEN_FAILED RAW_VALUE
>5 Reallocated_Sector_Ct   0x0033   100   100   010Pre-fail
> Always   -   0
>9 Power_On_Hours  0x0032   097   097   000Old_age
> Always   -   12772
>   12 Power_Cycle_Count   0x0032   098   098   000Old_age
> Always   -   1810
> 177 Wear_Leveling_Count 0x0013   097   097   000Pre-fail  Always
>-   78
> 179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010Pre-fail  Always
>-   0
> 181 Program_Fail_Cnt_Total  0x0032   100   100   010Old_age   Always
>-   0
> 182 Erase_Fail_Count_Total  0x0032   100   100   010Old_age   Always
>-   0
> 183 Runtime_Bad_Block   0x0013   100   100   010Pre-fail  Always
>-   0
> 187 Uncorrectable_Error_Cnt 0x0032   100   100   000Old_age   Always
>-   0
> 190 Airflow_Temperature_Cel 0x0032   061   055   000Old_age   Always
>-   39
> 195 ECC_Error_Rate  

systemctl can not start X, but startx can.

[Chris Capon]

Hi.
During a recent update to xorg 1:7.7+19 my graphical environment stopped
initializing on reboot.

sudo systemctl isolate graphical.target
fails to initialize the graphics card with these messages:

[   340.372] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at
PCI:5:0:0.  Please
[   340.372] (EE) NVIDIA(GPU-0): check your system's kernel log for
additional error
[   340.372] (EE) NVIDIA(GPU-0): messages and refer to Chapter 8:
Common Problems in the
[   340.372] (EE) NVIDIA(GPU-0): README for additional information.
[   340.372] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics
device!
[   340.372] (EE) NVIDIA(0): Failing initialization of X screen 0


on the other hand:
startx
initializes it with no problems.

[   150.685] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:5:0:0
[   150.685] (--) NVIDIA(0): CRT-0
[   150.685] (--) NVIDIA(0): CRT-1
[   150.685] (--) NVIDIA(0): DFP-0 (boot)
[   150.685] (--) NVIDIA(0): DFP-1
[   150.685] (--) NVIDIA(0): DFP-2
[   150.687] (II) NVIDIA(0): NVIDIA GPU GeForce GT 430 (GF108) at PCI:5:0:0
(GPU-0)
[   150.687] (--) NVIDIA(0): Memory: 1048576 kBytes
[   150.687] (--) NVIDIA(0): VideoBIOS: 70.08.29.00.30
[   150.687] (II) NVIDIA(0): Detected PCI Express Link width: 16X


I haven't been able to find additional info on what the problem is.

Attached are the two complete Xorg.log files.

Can anyone help?
Thanks.


Xorg.0.log.isolate
Description: Binary data


Xorg.0.log.startx
Description: Binary data

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Brad Rogers]

On Tue, 28 Aug 2018 22:23:46 +0200
Stefan Krusche  wrote:

Hello Stefan,

>have to log in via their website interface to free them out of the spam
>folder to be able to download them with my precious email client. I've

Is it not possible to whitelist the addresses?

>recently started to think this provider *wants* me to have to log in
>and use the website 

Of course they do.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Everything in life should be free, except the bits that belong to me
Selfish Rubbish - Public Image Ltd


pgpBwcFGeHQ4x.pgp
Description: OpenPGP digital signature

Re: mailing list vs "the futur"

[John Hasler]

As a totally theoretical aside, it should be noted that NNTP is a peer
to peer protocol.  At one time news servers and spools were so
heavyweight that they required a VAX (leading to the client-server model
of news that is the only way most people think it can work), but by
modern standards the servers require negligible resources and a spool
(especially if it only handles a few private newsgoups such as the
Debian lists) is small potatoes.  Every debian-user subscriber could run
a local server for as many of the Debian lists as they chose to
subscribe to at a lower cost in resources than running their own mail
server.

Will never happen, of course.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Stefan Krusche]

Am Dienstag, 28. August 2018 schrieb Francesco Porro:
> Ciao,
>
> As a member of this mailing list, I have a little (OT) question for you:
> which is the best free email service around to receive mailing lists?
>
> I mean, somethihng that has a good Imap server, good enough to be
> accessed by a MUA like Thunderbird without issues, and good spam filter
> which won't bother me with false-positives?.
>
> Now, i'm using a free account on yahoo, as you can see, but I get some
> of email bounces and moreover spam filters are really awful: they mark
> as spam a lot of non-spam, genuine mails coming from i.e. the
> Gnome/Evolution mailing list. Some months ago I was subscribed on my
> primary account which is a Gmail one, but then I wanted to separate
> mailing lists from the rest (so I moved those to yahoo).
>
> What do you think about GMX?? Is it a good solution for that purpose?
> I've already one signed up so i'd would be trivial to set this apart and
> move to the @gmx.com one.
>
> Thank you!

Hi Francesco,

I'm on gmx.net since long and they frequently give me false positives even with 
addresses which I've been receiving for years or seemingly random messages from 
this or other mailing lists. Everytime I see those in the daily spam report I 
have to log in via their website interface to free them out of the spam folder 
to be able to download them with my precious email client. I've recently 
started to think this provider *wants* me to have to log in and use the website 
with all the horrible ads and articles... and so have been considering, as 
recommended by John Hasler, to switch to a paid email service provider, which 
I'm gonna do soon.

My two cents...

Kind regards,
Stefan

Re: A reliable SIP registrar?

[James Cloos]

> peter   writes:

> Can anyone recommend a SIP registrar for general use

(I presume you mean ones which are free and thus do not offer
psnt access.)

I had this list, but have not recently confirmed they are working:

ekiga.net
ostel.co
sip2sip.info (proxy.sipthor.net)
sip.iptel.org
sip.linphone.org
sipgate.de

ostel may have disappeared.  I've also seen some complaints about
linphone on their lists over the last year or so.

For sip2sip, check out http://wiki.sip2sip.info.

I'd start with iptel.org.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: iproute, NM and ifupdown

[David Wright]

On Tue 28 Aug 2018 at 14:57:58 (-0400), Gene Heskett wrote:
> On Tuesday 28 August 2018 14:16:15 David Wright wrote:
> 
> > On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> > > On Monday 27 August 2018 15:59:09 David Wright wrote:
> > > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > > > Most recently on a stretch install on a rock64 I had to
> > > > > > > erect immutable attributes to resolv.conf after making it a
> > > > > > > real file, and e-n-i to make networking Just Work.
> > > > > >
> > > > > > /etc/resolv.conf is a rather different topic, because it is
> > > > > > not related to a specific interface and may be written by
> > > > > > several pieces of software, including but not limited to
> > > > > > NetworkManager when configuring *any* interface. I would
> > > > > > suggest using resolvconf but I suspect you would not like it
> > > > > > either.

Reread what you wrote:

> > > > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > > > >
> > > > > What we do have is missing (wheezy) or horribly incomplete
> > > > > (jessie).
> > > > >
> > > > > But I'll have to take that back, my apologies. I just read the
> > > > > stretch version on that rock64.  And as man pages go, its
> > > > > decent. And I'll have to do some experimenting as its possible I
> > > > > can train it to behave.
> > > > >
> > > > > And curious I blink compared the jessie vs stretch versions,
> > > > > stretch's is both longer AND more complete, and two different
> > > > > authors and formatted completely different. And wheezy doesn't
> > > > > even have the man page. I don't even know if it should, maybe
> > > > > not for wheezy, lots of water has been recycled since those
> > > > > installs were made, so I'll plead oldtimers.

That's about the *man pages* for resolvconf.

> > > > This is very strange. I just did (in 80 column xterms):
> >
> > [snipped various properties of resolvconf's man page on
> > wheezy/jessie/stretch.]
> >
> > > > So one can't help wondering exactly what is installed on your
> > > > machines if things don't match. Note that there are significant
> > > > differences between the different versions, so following the
> > > > stretch/jessie man page could give you problems on a wheezy
> > > > machine. (I haven't checked out backports.)
> > >
> > > What is installed on 4 of the 6 boxes here, is a wheezy install
> > > thats been tweaked to A: put a realtime kernel on it so it can run
> > > linuxcnc on real hardware. The stretch I'll install here after my
> > > new drive cage arrives, and I found today that newegg's fedex is a
> > > week for delivery, its not expected to arrive here before Thursday
> > > evening, has also been tweaked to run LinuxCNC, probably by a real
> > > time kernel replacement..
> >
> > Which kernel you run should have no connection with the contents of
> > Debian's resolvconf packages. You should still have these three:
> >
> >  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
> >  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
> >  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz

Those are the man pages (your "docs") for wheezy/jessie/stretch.
They should be on your various systems according to Debian codename.

> not on any wheezy sourced from the linuxcnc install iso, David

Well, look again. In /usr/share/man/man8/, not /etc/.

> My /etc/resolv.conf is a real file and looks something like this:
> 
> nameserver 192.168.71.1
> search hosts nameserver
> 
> And it Just Works.

Yes, /etc/resolv.conf is not a man page. And I don't suppose your
/etc/resolv.conf is missing from wheezy or horribly incomplete in
jessie, which is what you were claiming for the *docs*.

And note that none of this is about the man page for resolv.conf which
is in section (5) rather than (8) as it's about a file, not a command.
If you read the latter, you'll see that your line "search hosts nameserver"
doesn't make a lot of sense.

But that's a conversation we had last year.
https://lists.debian.org/debian-user/2017/08/msg01432.html

Cheers,
David.

Re: Problema resolución DNS

[remgasis remgasis]

Gracias felix. Lo he reportado con el propietario de ese bloque:

Dear C Networks team,

In this time, we are having some issues with the DNS resolution to some
domains as gob.ve, e.g.

www.seniat.gob.ve, please, you observe the following test from my DNS
server at 170.83.78.202, deducing that

the tracert to www.seniat.gob.ve from 170.83.78.202 finalize at the IP
63.245.45.174 which belong you

according https://myip.es/63.245.45.174.

If you have some doubt about this issue, please, you able contact me
through my e-mail acount

traceroute www.seniat.gob.ve
traceroute to www.seniat.gob.ve (200.11.221.10), 30 hops max, 60 byte
packets
 1  170.83.78.201 (170.83.78.201)  9.351 ms  9.720 ms  10.885 ms
 2  100.100.100.21 (100.100.100.21)  9.306 ms  10.850 ms *
 3  10.10.10.1 (10.10.10.1)  9.242 ms *  9.229 ms
 4  * 190.217.4.241 (190.217.4.241)  14.822 ms *
 5  * * *
 6  * * *
 7  mai-b1-link.telia.net (213.248.84.80)  49.570 ms  49.556 ms  49.474 ms
 8  mai-b3-link.telia.net (62.115.136.165)  48.300 ms  48.289 ms  47.089 ms
 9  asur-ic-301282-mai-b2.c.telia.net (62.115.14.6)  47.147 ms  47.145 ms
47.121 ms
10  ge-5-0-0.0-boca-raton.fl.us.nmi-edge02.cwc.com (63.245.107.73)  57.625
ms ge-1-1-0.0-boca-

raton.fl.us.brx-edge02.cwc.com (63.245.5.77)  46.820 ms
ge-5-0-0.0-boca-raton.fl.us.nmi-edge02.cwc.com

(63.245.107.73)  55.224 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  63.245.45.174 (63.245.45.174)  106.414 ms !X * *


ping www.seniat.gob.ve
PING www.seniat.gob.ve (200.11.221.10) 56(84) bytes of data.
>From 63.245.45.174 icmp_seq=3 Packet filtered


El mar., 28 ago. 2018 a las 14:51, Felix Perez ()
escribió:

> El mar., 28 de ago. de 2018 a la(s) 14:02, remgasis remgasis
> (remga...@gmail.com) escribió:
> >
> > Muchas gracias por tu tiempo Matias. Tomaré nota de lo que me has
> comentado.
> >
> > El mar., 28 ago. 2018 a las 12:59, Matias Mucciolo (<
> mmucci...@suteba.org.ar>) escribió:
> >>
> >>
> >> On Tuesday, August 28, 2018 11:17:56 AM -03 remgasis remgasis wrote:
> >> > Estimada lista,
> >> >
> >> > un cordial saludo. En esta oportunidad les escribo porque
> recientemente he
> >> > cambiado la IP de mi servidor DNS y desde ese momento he presentado
> >> > problemas en la resolución DNS de algunas páginas con el dominio .
> com.ve.
> >> >
> >> > Destaco que teniendo configurada la DNS 8.8.8.8 en mi pc cuando hago
> >> > algunas consultas con nslookup, muchos dominios .gob.ve aparecen con
> la IP
> >> > 185.53.178.24, la cual no corresponde a cada dirección consultada
> sino a
> >> > Team Internet AG y ya la he reportado en abuse. Ahora, cuando hago
> nslookup
> >> > desde mi DNS server si aparece la IP que corresponde, por ejemplo,
> >> > www.seniat.gob.ve - 200.11.221.10.
> >> >
> >> > En ambos casos no carga el portal www.seniat.gob.ve.
> >> >
> >> > *Por ejemplo, desde una pc cualquiera:*
> >> >
> >> > nslookup www.seniat.gob.ve
> >> > Servidor:  google-public-dns-a.google.com
> >> > Address:  8.8.8.8
> >> >
> >> > Respuesta no autoritativa:
> >> > Nombre:  www.seniat.gob.ve.*com.ve *
> >> > Address:  185.53.178.24 (ESTA IP NO CORRESPONDE)
> >> >
> >> > *Desde el DNS server:*
> >> >
> >> > nslookup www.seniat.gob.ve 8.8.8.8
> >> > Server: 8.8.8.8
> >> > Address:8.8.8.8#53
> >> >
> >> > Non-authoritative answer:
> >> > Name:   www.seniat.gob.ve
> >> > Address: 200.11.221.10
> >> >
> >> >
> >>
> >> Buenas
> >> no hice muchas pruebas..pero si me da la ip correcta :
> >>
> >> $ nslookup www.seniat.gob.ve 8.8.8.8
> >> Server: 8.8.8.8
> >> Address:8.8.8.8#53
> >>
> >> Non-authoritative answer:
> >> Name:   www.seniat.gob.ve
> >> Address: 200.11.221.10
> >>
> >>
> >> $ nslookup www.seniat.gob.ve
> >> Server: 192.168.0.1
> >> Address:192.168.0.1#53
> >>
> >> Non-authoritative answer:
> >> Name:   www.seniat.gob.ve
> >> Address: 200.11.221.10
> >>
> >> con mi server dns privado y con el de google
> >>
> >> lo que puede ser que este pasando(en "pc cualquiera") que todas las
> consultas
> >> de dns lo manden a un servidor X es decir nunca estas consultado al
> servidor
> >> de google porque hacen un reenvio o DNAT a X..etc..como quieras
> llamarlo.
> >> quizas la isp de esa pc hace esto por X motivos..
> >>
> >> en definitiva deberias ponerte en contacto con tu proveedor de internet
> >> y averiguar que esta pasando.
> >>
> >> seguro van a decir que es un servidor cache y es para mejorar la
> performance..
> >> mientras miran a que paginas queres acceder (?)..
> >>
> >> saludos
> >> Matias.-
> >>
>
> La página no esta respondiendo, por http o con https dice  "La
> conexión ha caducado"
>
> Un ping muestra lo que está abajo:
>
> PING www.seniat.gob.ve (200.11.221.10) 56(84) bytes of data.
> >From 63.245.45.174 icmp_seq=14 Packet filtered
> >From 63.245.45.174 icmp_seq=29 Packet filtered
> >From 63.245.45.174 

Re: Inloggen op Active directory

[Paul van der Vlis]

Hoi Bas en anderen,

Op 28-08-18 om 15:35 schreef Bas Neve:
> Inloggen op een active directory domein vanuit Debian95 lukt niet.

9.5 en geen 95!

> Voor diverse Unix varianten zijn er tools hiervoor beschikbaar zoals
> auth-config op Redhat, Ubuntu heeft pam-auth-update Suse yast. Een
> confiuratie tool voor Debian heb ik echter nog iet gevonden.
> 
> Iemand een idee ? 

Je zult /etc/samba/smb.conf juist moeten configureren, en wellicht
/etc/krb5.conf.

/usr/sbin/pam-auth-update staat standaard op een Debian installatie, ik
ken het echter niet.

Wellicht heb je hier iets aan?
https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member

Groeten,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Re : Répertoire avec des noms étranges à la racine : -ffffffffffffffff-0000000000

[bidons59]

Le 28/08/2018 à 18:46, nicolas.patr...@gmail.com a écrit :

Le 28/08/2018 17:02:39, Fabrice Delvallée a écrit :


Je viens de trouver de deux répertoires aux noms étranges à la racine
de ma Debian stretch :


[…]


Bien sur j'ai aucune idée de ce que je faisait le 15 août vers
11h18...



Est-ce grave docteur ?


Vérifie ton disque avec gsmartcontrol.

nicolas patrois : pts noir asocial

J'avoue ne pas être un spécialiste de smart. J'ai effectué un test 
'Short offline' puis un 'Extended Slef-test'


Je pollue la liste avec la sortie:

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.17.0-0.bpo.1-amd64] (local 
build)

Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 840 PRO Series
Serial Number:S1ANNEAD626089P
LU WWN Device Id: 5 002538 5503a72e3
Firmware Version: DXM05B0Q
User Capacity:128,035,676,160 bytes [128 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:Solid State Device
Device is:In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:Tue Aug 28 21:07:56 2018 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status:  (   0)	The previous self-test routine 
completed

without error or no self-test has ever
been run.
Total time to complete Offline
data collection:(0) seconds.
Offline data collection
capabilities:(0x53) SMART execute Offline immediate.
Auto Offline data collection on/off 
support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities:(0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability:(0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time:(   2) minutes.
Extended self-test routine
recommended polling time:(  15) minutes.
SCT capabilities:  (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE 
UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010Pre-fail 
Always   -   0
  9 Power_On_Hours  0x0032   097   097   000Old_age 
Always   -   12772
 12 Power_Cycle_Count   0x0032   098   098   000Old_age 
Always   -   1810
177 Wear_Leveling_Count 0x0013   097   097   000Pre-fail  Always 
  -   78
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010Pre-fail  Always 
  -   0
181 Program_Fail_Cnt_Total  0x0032   100   100   010Old_age   Always 
  -   0
182 Erase_Fail_Count_Total  0x0032   100   100   010Old_age   Always 
  -   0
183 Runtime_Bad_Block   0x0013   100   100   010Pre-fail  Always 
  -   0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000Old_age   Always 
  -   0
190 Airflow_Temperature_Cel 0x0032   061   055   000Old_age   Always 
  -   39
195 ECC_Error_Rate  0x001a   200   200   000Old_age   Always 
  -   0
199 CRC_Error_Count 0x003e   100   100   000Old_age   Always 
  -   0
235 POR_Recovery_Count  0x0012   099   099   000Old_age   Always 
  -   88
241 Total_LBAs_Written  0x0032   099   099   000Old_age   Always 
  -   5865312734


SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining 
LifeTime(hours)  

Re: iproute, NM and ifupdown

[Timothy M Butterworth]

On 8/28/18, Gene Heskett  wrote:
> On Tuesday 28 August 2018 14:16:15 David Wright wrote:
>
>> On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
>> > On Monday 27 August 2018 15:59:09 David Wright wrote:
>> > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
>> > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
>> > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
>> > > > > > Most recently on a stretch install on a rock64 I had to
>> > > > > > erect immutable attributes to resolv.conf after making it a
>> > > > > > real file, and e-n-i to make networking Just Work.
>> > > > >
>> > > > > /etc/resolv.conf is a rather different topic, because it is
>> > > > > not related to a specific interface and may be written by
>> > > > > several pieces of software, including but not limited to
>> > > > > NetworkManager when configuring *any* interface. I would
>> > > > > suggest using resolvconf but I suspect you would not like it
>> > > > > either.
>> > > >
>> > > > Ohkaay, but where's the docs on this mysterious resolvconf?
>> > > >
>> > > > What we do have is missing (wheezy) or horribly incomplete
>> > > > (jessie).
>> > > >
>> > > > But I'll have to take that back, my apologies. I just read the
>> > > > stretch version on that rock64.  And as man pages go, its
>> > > > decent. And I'll have to do some experimenting as its possible I
>> > > > can train it to behave.
>> > > >
>> > > > And curious I blink compared the jessie vs stretch versions,
>> > > > stretch's is both longer AND more complete, and two different
>> > > > authors and formatted completely different. And wheezy doesn't
>> > > > even have the man page. I don't even know if it should, maybe
>> > > > not for wheezy, lots of water has been recycled since those
>> > > > installs were made, so I'll plead oldtimers.
>> > >
>> > > This is very strange. I just did (in 80 column xterms):
>>
>> [snipped various properties of resolvconf's man page on
>> wheezy/jessie/stretch.]
>>
>> > > So one can't help wondering exactly what is installed on your
>> > > machines if things don't match. Note that there are significant
>> > > differences between the different versions, so following the
>> > > stretch/jessie man page could give you problems on a wheezy
>> > > machine. (I haven't checked out backports.)
>> >
>> > What is installed on 4 of the 6 boxes here, is a wheezy install
>> > thats been tweaked to A: put a realtime kernel on it so it can run
>> > linuxcnc on real hardware. The stretch I'll install here after my
>> > new drive cage arrives, and I found today that newegg's fedex is a
>> > week for delivery, its not expected to arrive here before Thursday
>> > evening, has also been tweaked to run LinuxCNC, probably by a real
>> > time kernel replacement..
>>
>> Which kernel you run should have no connection with the contents of
>> Debian's resolvconf packages. You should still have these three:
>>
>>  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
>>  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
>>  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz
>>
> not on any wheezy sourced from the linuxcnc install iso, David
>
> My /etc/resolv.conf is a real file and looks something like this:
>
> nameserver 192.168.71.1
> search hosts nameserver
>
> And it Just Works.
>
>> Cheers,
>> David.
>
>
>
> --
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>

Mine is immutable as well. I have Google DNS Configured.

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4888:3b:ff00:3c2:d::
nameserver 2001:4888:32:ff00:3c1:d::

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 04:46:15PM +0100, Mark Rousell wrote:

web forums, app-based, IM-style, etc.) but none of that, to my mind, lessens
NNTP's ideal applicability to getting private discussion group messages from
place to place (the front end UI/UX being a different thing again).


Ignoring the changes to user requirements for UI/UX is at least part of 
why NNTP is no longer a major factor in internet usage.



The key advantage of NNTP over email/SMTP in terms of bandwidth efficiency is
that, with NNTP, messages are only sent to users when they explicitly ask for
them. This is more bandwidth-efficient than an email-based list since the
email-based list must send out messages to each and every user whether or not
they want them.


It's more efficient at the provider level until someone decides they 
want all of the messages local, either as an archive or to run local 
search tools, etc. At that point you're transferring all of the messages 
just as you would via SMTP and it's basically a wash. If you have a 
bunch of users on remote SMTP and NNTP servers then it's always a 
wash. (MUAs don't typically download the entire message body unless 
asked to, just as news readers don't typically download the entire 
message body unless asked to.) Basically, the efficiency argument is 
bogus.


And even if it weren't bogus, the bandwidth in question is so small as 
to not matter anyway. (We call this "premature optimization"; there are 
other concerns that are far more significant--like the UI/UX.) The 
entire 25 year archive of debian lists is probably on the order of one 
or two netflix movies.



To my mind, a REST protocol has a different (but overlapping) use case to NNTP
or email lists. I know of no standard, open REST protocol that replaces either
NNTP or email discussion lists, for example.


But there are a heck of a lot more deployed REST clients than NNTP 
clients. You can shake your fist at the cloud all you want, but reality 
is what it is. Consequently, a good experience for HTTP consumers is 
going to be a higher priority than NNTP users. The numbers are so skewed 
as to raise valid questions about whether the small number of NNTP users 
is worth committing development and operational resources to. Many of 
the forums I can think of that supported HTTP + NNTP 10 or 15 years ago 
have long since decided that the answer was no.



I am not "offering a closed environment with close to zero users as a
counterexample". It (i.e. NNTP in private discussion groups) is not a counter
example of or to anything. It is, in fact, the specific issue under discussion!


It's always amusing when someone decides to state what "the proper topic 
of the email thread" is. You want to talk about one thing. The person 
who started the thread wanted to talk about a completely different 
thing. But I guess you get to decide what's on-topic because reasons?


More specifically, the point at which I started talking about usenet was 
in response to two people who weren't you talking about ISP-level NNTP 
transit servers. If you define the use case to exclude ISP-level NNTP 
servers then you can certainly argue that the only wide scale 
implementation of ISP-level NNTP transit servers (usenet) is irrelevant, 
but it takes a large amount of hubris to declare that one particular 
branch of the thread is more irrelevant than your preferred branch of 
the thread.



   You've asserted it many times, but you haven't actually shown with numbers
   how it's more efficient in practice to any degree that matters in the real
   world.


I have in fact (a) pointed out specifics of how NNTP works better in the
context at hand


You still haven't provided numbers that show that your argument matters 
for real-world implementations. I'll simply agree to disagree that 
you've provided specifics rather than assertions or personal preferences.



and (b) pointed out how your negative view of NNTP in this
context was based upon an erroneous conflation with the problems of Usenet that
were not caused by NNTP.


I think that the only one who's concerned I have a conflation of usenet 
and NNTP is you. If you want to continue stating that, I guess it's a 
free internet. (Though, I might start some kind of drinking game based on 
how many times you say "conflation of usenet and NNTP" or 
equivalent--it's gotten kinda amusing, if repetitive.) You also seem to 
have been the one to start making other unfounded assertions about my 
background and why I have the opinions I have. Honestly, I'd prefer if 
you just stick to stuff that's somehow relevant to the discussion and 
avoid erroneous ad hominems.


FWIW, another possibility for why the discussion doesn't match your 
desires (one that doesn't require me to have a misguided agenda of 
conflating usenet and NNTP based on some shadowy usenet training 20 
years in the past) is that threads wander and that people talk about 
what they want to talk about. Also, more than one person may have 
something 

Re: iproute, NM and ifupdown

[Gene Heskett]

On Tuesday 28 August 2018 14:16:15 David Wright wrote:

> On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> > On Monday 27 August 2018 15:59:09 David Wright wrote:
> > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > > Most recently on a stretch install on a rock64 I had to
> > > > > > erect immutable attributes to resolv.conf after making it a
> > > > > > real file, and e-n-i to make networking Just Work.
> > > > >
> > > > > /etc/resolv.conf is a rather different topic, because it is
> > > > > not related to a specific interface and may be written by
> > > > > several pieces of software, including but not limited to
> > > > > NetworkManager when configuring *any* interface. I would
> > > > > suggest using resolvconf but I suspect you would not like it
> > > > > either.
> > > >
> > > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > > >
> > > > What we do have is missing (wheezy) or horribly incomplete
> > > > (jessie).
> > > >
> > > > But I'll have to take that back, my apologies. I just read the
> > > > stretch version on that rock64.  And as man pages go, its
> > > > decent. And I'll have to do some experimenting as its possible I
> > > > can train it to behave.
> > > >
> > > > And curious I blink compared the jessie vs stretch versions,
> > > > stretch's is both longer AND more complete, and two different
> > > > authors and formatted completely different. And wheezy doesn't
> > > > even have the man page. I don't even know if it should, maybe
> > > > not for wheezy, lots of water has been recycled since those
> > > > installs were made, so I'll plead oldtimers.
> > >
> > > This is very strange. I just did (in 80 column xterms):
>
> [snipped various properties of resolvconf's man page on
> wheezy/jessie/stretch.]
>
> > > So one can't help wondering exactly what is installed on your
> > > machines if things don't match. Note that there are significant
> > > differences between the different versions, so following the
> > > stretch/jessie man page could give you problems on a wheezy
> > > machine. (I haven't checked out backports.)
> >
> > What is installed on 4 of the 6 boxes here, is a wheezy install
> > thats been tweaked to A: put a realtime kernel on it so it can run
> > linuxcnc on real hardware. The stretch I'll install here after my
> > new drive cage arrives, and I found today that newegg's fedex is a
> > week for delivery, its not expected to arrive here before Thursday
> > evening, has also been tweaked to run LinuxCNC, probably by a real
> > time kernel replacement..
>
> Which kernel you run should have no connection with the contents of
> Debian's resolvconf packages. You should still have these three:
>
>  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
>  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
>  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz
>
not on any wheezy sourced from the linuxcnc install iso, David

My /etc/resolv.conf is a real file and looks something like this:

nameserver 192.168.71.1
search hosts nameserver

And it Just Works.

> Cheers,
> David.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Problema resolución DNS

[Felix Perez]

El mar., 28 de ago. de 2018 a la(s) 14:02, remgasis remgasis
(remga...@gmail.com) escribió:
>
> Muchas gracias por tu tiempo Matias. Tomaré nota de lo que me has comentado.
>
> El mar., 28 ago. 2018 a las 12:59, Matias Mucciolo 
> () escribió:
>>
>>
>> On Tuesday, August 28, 2018 11:17:56 AM -03 remgasis remgasis wrote:
>> > Estimada lista,
>> >
>> > un cordial saludo. En esta oportunidad les escribo porque recientemente he
>> > cambiado la IP de mi servidor DNS y desde ese momento he presentado
>> > problemas en la resolución DNS de algunas páginas con el dominio .com.ve.
>> >
>> > Destaco que teniendo configurada la DNS 8.8.8.8 en mi pc cuando hago
>> > algunas consultas con nslookup, muchos dominios .gob.ve aparecen con la IP
>> > 185.53.178.24, la cual no corresponde a cada dirección consultada sino a
>> > Team Internet AG y ya la he reportado en abuse. Ahora, cuando hago nslookup
>> > desde mi DNS server si aparece la IP que corresponde, por ejemplo,
>> > www.seniat.gob.ve - 200.11.221.10.
>> >
>> > En ambos casos no carga el portal www.seniat.gob.ve.
>> >
>> > *Por ejemplo, desde una pc cualquiera:*
>> >
>> > nslookup www.seniat.gob.ve
>> > Servidor:  google-public-dns-a.google.com
>> > Address:  8.8.8.8
>> >
>> > Respuesta no autoritativa:
>> > Nombre:  www.seniat.gob.ve.*com.ve *
>> > Address:  185.53.178.24 (ESTA IP NO CORRESPONDE)
>> >
>> > *Desde el DNS server:*
>> >
>> > nslookup www.seniat.gob.ve 8.8.8.8
>> > Server: 8.8.8.8
>> > Address:8.8.8.8#53
>> >
>> > Non-authoritative answer:
>> > Name:   www.seniat.gob.ve
>> > Address: 200.11.221.10
>> >
>> >
>>
>> Buenas
>> no hice muchas pruebas..pero si me da la ip correcta :
>>
>> $ nslookup www.seniat.gob.ve 8.8.8.8
>> Server: 8.8.8.8
>> Address:8.8.8.8#53
>>
>> Non-authoritative answer:
>> Name:   www.seniat.gob.ve
>> Address: 200.11.221.10
>>
>>
>> $ nslookup www.seniat.gob.ve
>> Server: 192.168.0.1
>> Address:192.168.0.1#53
>>
>> Non-authoritative answer:
>> Name:   www.seniat.gob.ve
>> Address: 200.11.221.10
>>
>> con mi server dns privado y con el de google
>>
>> lo que puede ser que este pasando(en "pc cualquiera") que todas las consultas
>> de dns lo manden a un servidor X es decir nunca estas consultado al servidor
>> de google porque hacen un reenvio o DNAT a X..etc..como quieras llamarlo.
>> quizas la isp de esa pc hace esto por X motivos..
>>
>> en definitiva deberias ponerte en contacto con tu proveedor de internet
>> y averiguar que esta pasando.
>>
>> seguro van a decir que es un servidor cache y es para mejorar la 
>> performance..
>> mientras miran a que paginas queres acceder (?)..
>>
>> saludos
>> Matias.-
>>

La página no esta respondiendo, por http o con https dice  "La
conexión ha caducado"

Un ping muestra lo que está abajo:

PING www.seniat.gob.ve (200.11.221.10) 56(84) bytes of data.
>From 63.245.45.174 icmp_seq=14 Packet filtered
>From 63.245.45.174 icmp_seq=29 Packet filtered
>From 63.245.45.174 icmp_seq=30 Packet filtered
>From 63.245.45.174 icmp_seq=57 Packet filtered
>From 63.245.45.174 icmp_seq=69 Packet filtered
>From 63.245.45.174 icmp_seq=102 Packet filtered
>From 63.245.45.174 icmp_seq=108 Packet filtered

Con los dns de opendns y tambien con los que provee mi ISP.  Desde Chile.

La IP 63.245.45.174 es una IP de Miami.

Espero te sirvan estos datos.

-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 19:33, Mark Rousell wrote:
> And ISPs' historical problems Usenet's massive bandwidth due to
> binaries does not change the fact that NNTP is very good for message
> distribution.

Missing "with" in the above.

-- 
Mark Rousell
 
 
 

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Mark Rousell]

On 28/08/2018 19:08, Miles Fidelman wrote:
> I would suggest looking for somebody who runs Sympa.
>
> Open source, well supported, more "industrial strength" than Mailman
> (designed for universities, supporting lots of lists).
>
> I've been running it on our servers, for at least a decade (who's
> counting) - it's rock solid, well supported by both a core team (at
> Renater - the French Research & Education Network), and a larger
> community.  (For example, a patch for DMARC came out almost
> immediately.  It took a lot longer for a mailman patch to show up, and
> even longer for it to make into the standard release).  Also, Sympa is
> built around a database, mailman isn't - makes a difference for folks
> running multiple lists.  Lots more things that can be customized.
>
> There's a list of hosting providers at
> https://www.sympa.org/users/custom - but they're mostly in France. 
> You might have to do a little hunting - or post on the sympa users list.
>
> There's also Groupserver (http://groupserver.org) - a rather
> interesting package that does a good job of melding traditional lists,
> with a web-based forum interface.  It's open source, with hosting
> available - from a small group in New Zealand.  It has a bit of
> traction in the "electronic democracy" community.

If I understand correctly, I think that Francesco was asking for a good
(free) email service provider at which he could receive emails from mail
lists, rather than a mail list provider.

Nevertheless, thanks for your mail list software suggestions. I've heard
of Sympa but never seen them described in the manner you did here. And I
am sorry to say that I had never heard of GroupServer before. Thanks for
the useful information.


-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 19:23, Miles Fidelman wrote:
> On 8/28/18 1:48 PM, Michael Stone wrote:
>
>> On Tue, Aug 28, 2018 at 05:02:08PM +0100, Mark Rousell wrote:
>>> Lots of people download files from FTP servers but that's a wholly
>>> different
>>> culture and use case than Usenet provided for in practice. And who
>>> said that
>>> binaries (whether legal or illegal) was not a big part of Usenet at
>>> its height?
>>
>> Anyone who argues that NNTP is the most efficient thing around? I
>> guarantee that for large files FTP is more efficient, and that when
>> one person is sending a file to a small number of other peopl, FTP is
>> dramatically more efficient. I guess NNTP binary distribution is more
>> efficient in some theoretical world where exactly the right
>> subscriptions are distributed to exactly the right people via local
>> transit servers, with no reposts. We can probably just write the
>> volume of such transfers off as noise in the real world.
>
> NNTP is exceptionally efficient for large scale message distribution -
> when compared to, say, a mailing list server that sends a message per
> subscriber.

Indeed.

And ISPs' historical problems Usenet's massive bandwidth due to binaries
does not change the fact that NNTP is very good for message distribution.


-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 18:48, Michael Stone wrote:
> I guarantee that for large files FTP is more efficient, and that when
> one person is sending a file to a small number of other peopl, FTP is
> dramatically more efficient.

I am sure. But it still doesn't make FTP meaningfully comparable to
Usenet or NNTP in the context of this sub-thread discussion.

> I guess NNTP binary distribution is more efficient in some theoretical
> world where exactly the right subscriptions are distributed to exactly
> the right people

I can only point you to the world as it actually stood where binary
distribution (for certain types of binary for a certain type of user
base) via Usenet was outstandingly common at one time (which you of
course know). FTP just wasn't a feasible candidate protocol for that
particular use case. As such, yes, NNTP was efficient enough. As I said
when I entered this sub-thread (with added comment in square brackets):

NNTP was inefficient in this regard compared to what other protocol
or protocols, exactly?

Compared to email? Well, email suffered from very similar issues
transferring binaries.

Compared to DCC over IRC? (DCC being a then-popular one-to-one
alternative to Usenet's one-to-many distribution model). I must
admit that I've never examined the details of the DCC protocol but
it is certainly inefficient in terms of /user experience/ compared
to Usenet over NNTP: In practice DCC was essentially synchronous,
one at a time, needing continuous user management whereas Usenet
facilitated a time-efficient asynchronous access mechanism for the
end user without continuous management.

So what one-to-many distribution platforms or protocols existed in
this timeframe against which to compare NNTP (or Usenet)?

I perhaps should have asked "NNTP was inefficient in this regard
compared to what other *relevant *protocol or protocols, exactly?".

You have observed, quite correctly of course, that FTP is a more
bandwidth-efficient protocol that was available in the timeframe under
discussion for binary file transfers but the fact nonetheless remains
that FTP did not and does not fulfil the particular mass volume and mass
user numbers one-to-many use case to which Usenet was put at that time.
FTP did not and does not have the federated, distributed, public access
nature that Usenet provided and that led to its success in this context.

Sure, Usenet became impossible to cope with for ISPs due to the volume
of binaries groups. But, from a user experience perspective, it was very
efficient indeed (for reasons I enumerated in other messages) for the
job it ended up being used for. And it was not significantly more
bandwidth-inefficient than any other suitable or relevant system or
protocol because, at the time, there were no other systems or protocols
that could really fulfil the Usenet use case.

FTP, despite more bandwidth-efficiently allowing binary transfers of
course, still did not fulfil the same use case.

Anyway, this part of the discussion is just more about Usenet history.
It has nothing to do with NNTP in a discussion group context which is
why I initially commented in this thread.

> via local transit servers, with no reposts. We can probably just write
> the volume of such transfers off as noise in the real world.

You seem to be again conflating Usenet's issues relating to huge
bandwidth due to mass distribution of binaries with the completely
different use case of NNTP that is the subject of this thread.



-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Miles Fidelman]

On 8/28/18 1:44 PM, Michael Stone wrote:

On Tue, Aug 28, 2018 at 04:50:27PM +0100, Mark Rousell wrote:
Additionally, both FTP and HTTP were not and are not federated, 
one-to-many

services or systems in the way that Usenet was


I guess this is where I say "But why would you expect it to be?" and 
ignore the rest of the argument.


But one might want it to be - as compared to something centralized, like 
a list server or forum.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: mailing list vs "the futur"

[Miles Fidelman]

On 8/28/18 1:48 PM, Michael Stone wrote:


On Tue, Aug 28, 2018 at 05:02:08PM +0100, Mark Rousell wrote:
Lots of people download files from FTP servers but that's a wholly 
different
culture and use case than Usenet provided for in practice. And who 
said that
binaries (whether legal or illegal) was not a big part of Usenet at 
its height?


Anyone who argues that NNTP is the most efficient thing around? I 
guarantee that for large files FTP is more efficient, and that when 
one person is sending a file to a small number of other peopl, FTP is 
dramatically more efficient. I guess NNTP binary distribution is more 
efficient in some theoretical world where exactly the right 
subscriptions are distributed to exactly the right people via local 
transit servers, with no reposts. We can probably just write the 
volume of such transfers off as noise in the real world.


NNTP is exceptionally efficient for large scale message distribution - 
when compared to, say, a mailing list server that sends a message per 
subscriber.


For binary files, something like bit torrent is clearly more efficient.  
Though, a while back, somebody implemented a rather efficient mechanism 
that used NNTP for distributing header information, and a distributed 
hash table for the files themselves. Saved a lot of bandwidth.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: iproute, NM and ifupdown

[David Wright]

On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> On Monday 27 August 2018 15:59:09 David Wright wrote:
> > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > Most recently on a stretch install on a rock64 I had to erect
> > > > > immutable attributes to resolv.conf after making it a real file,
> > > > > and e-n-i to make networking Just Work.
> > > >
> > > > /etc/resolv.conf is a rather different topic, because it is not
> > > > related to a specific interface and may be written by several
> > > > pieces of software, including but not limited to NetworkManager
> > > > when configuring *any* interface. I would suggest using resolvconf
> > > > but I suspect you would not like it either.
> > >
> > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > >
> > > What we do have is missing (wheezy) or horribly incomplete (jessie).
> > >
> > > But I'll have to take that back, my apologies. I just read the
> > > stretch version on that rock64.  And as man pages go, its decent.
> > > And I'll have to do some experimenting as its possible I can train
> > > it to behave.
> > >
> > > And curious I blink compared the jessie vs stretch versions,
> > > stretch's is both longer AND more complete, and two different
> > > authors and formatted completely different. And wheezy doesn't even
> > > have the man page. I don't even know if it should, maybe not for
> > > wheezy, lots of water has been recycled since those installs were
> > > made, so I'll plead oldtimers.
> >
> > This is very strange. I just did (in 80 column xterms):

[snipped various properties of resolvconf's man page on wheezy/jessie/stretch.]

> > So one can't help wondering exactly what is installed on your machines
> > if things don't match. Note that there are significant differences
> > between the different versions, so following the stretch/jessie man
> > page could give you problems on a wheezy machine. (I haven't checked
> > out backports.)
> 
> What is installed on 4 of the 6 boxes here, is a wheezy install thats 
> been tweaked to A: put a realtime kernel on it so it can run linuxcnc on 
> real hardware. The stretch I'll install here after my new drive cage 
> arrives, and I found today that newegg's fedex is a week for delivery, 
> its not expected to arrive here before Thursday evening, has also been 
> tweaked to run LinuxCNC, probably by a real time kernel replacement..

Which kernel you run should have no connection with the contents of
Debian's resolvconf packages. You should still have these three:

 4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
 4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
 4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz

Cheers,
David.

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Miles Fidelman]

I would suggest looking for somebody who runs Sympa.

Open source, well supported, more "industrial strength" than Mailman 
(designed for universities, supporting lots of lists).


I've been running it on our servers, for at least a decade (who's 
counting) - it's rock solid, well supported by both a core team (at 
Renater - the French Research & Education Network), and a larger 
community.  (For example, a patch for DMARC came out almost 
immediately.  It took a lot longer for a mailman patch to show up, and 
even longer for it to make into the standard release).  Also, Sympa is 
built around a database, mailman isn't - makes a difference for folks 
running multiple lists.  Lots more things that can be customized.


There's a list of hosting providers at 
https://www.sympa.org/users/custom - but they're mostly in France.  You 
might have to do a little hunting - or post on the sympa users list.


There's also Groupserver (http://groupserver.org) - a rather interesting 
package that does a good job of melding traditional lists, with a 
web-based forum interface.  It's open source, with hosting available - 
from a small group in New Zealand.  It has a bit of traction in the 
"electronic democracy" community.


Miles Fidelman


On 8/28/18 12:25 PM, Mark Rousell wrote:

On 28/08/2018 17:12, Francesco Porro wrote:

Ciao,

As a member of this mailing list, I have a little (OT) question for you:
which is the best free email service around to receive mailing lists?


I cannot personally recommend any free, proprietary email service 
providers.


Instead I'd say that running your own mail server would be best for 
this, assuming you have some kind of always-on connection with a 
static IP you can utilise.


Although incoming spam is a potential problem the real difficulties 
with running your own mail server in my opinion are (a) maintaining 
deliverability of outgoing mail and (b) making sure you're not 
relaying spam. Keeping software and configuration up to date is 
important. However, in the sort of scenario you describe, you might 
not need to use your mail server for outgoing mail which could 
simplify things. Ideally you could use your ISP's or domain provider's 
mail server for outgoing mail whilst directing incoming mail for your 
domain to your own server. (I should add that using your own domain is 
always wise, rather than relying on service providers' email addresses).


Learning how to do all this could involve a learning curve but it's 
entirely feasible.


--
Mark Rousell
  
  
  


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: mailing list vs "the futur"

[Gene Heskett]

On Tuesday 28 August 2018 10:22:34 Dan Purgert wrote:

> Gene Heskett wrote:
> > On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote:
> >> On 28/08/2018 12:42, Michael Stone wrote:
> >> > Yes and no. NNTP is inherently open to abuse because it wasn't
> >> > designed with mechanisms to account for the cost of a
> >> > transaction. (This is true of all the early internet protocols,
> >> > not just NNTP, which is why we have, e.g., such a spam problem on
> >> > SMTP.)
> >>
> >> Isn't this true of, say, HTTP too?
> >
> > [...] I had a long talk with
> > him just last week about how they are doing this new protocol where
> > they A: don't bother to verify me when I get redirected to their
> > servers for a one time code pad number to verify the authorization
> > of my purchase.
>
> him who?  your bank?
yes, the IT guy=him.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 05:02:08PM +0100, Mark Rousell wrote:

Lots of people download files from FTP servers but that's a wholly different
culture and use case than Usenet provided for in practice. And who said that
binaries (whether legal or illegal) was not a big part of Usenet at its height?


Anyone who argues that NNTP is the most efficient thing around? I 
guarantee that for large files FTP is more efficient, and that when one 
person is sending a file to a small number of other peopl, FTP is 
dramatically more efficient. I guess NNTP binary distribution is more 
efficient in some theoretical world where exactly the right 
subscriptions are distributed to exactly the right people via local 
transit servers, with no reposts. We can probably just write the volume 
of such transfers off as noise in the real world.

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 04:50:27PM +0100, Mark Rousell wrote:

Additionally, both FTP and HTTP were not and are not federated, one-to-many
services or systems in the way that Usenet was


I guess this is where I say "But why would you expect it to be?" and 
ignore the rest of the argument.

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Francesco Porro]

Il 28/08/2018 18:25, Mark Rousell ha scritto:
> Instead I'd say that running your own mail server would be best for this

Sorry, I forgot to mention that I dont't want to run a mail server by
myself.

Il 28/08/2018 18:39, John Hasler ha scritto:
> I can personally recommend a paid email service: newsguy.com.

Only *free* mail services, please.

Thanx.

-- 
fp

Re: Problema resolución DNS

[remgasis remgasis]

Muchas gracias por tu tiempo Matias. Tomaré nota de lo que me has comentado.

El mar., 28 ago. 2018 a las 12:59, Matias Mucciolo ()
escribió:

>
> On Tuesday, August 28, 2018 11:17:56 AM -03 remgasis remgasis wrote:
> > Estimada lista,
> >
> > un cordial saludo. En esta oportunidad les escribo porque recientemente
> he
> > cambiado la IP de mi servidor DNS y desde ese momento he presentado
> > problemas en la resolución DNS de algunas páginas con el dominio .com.ve
> .
> >
> > Destaco que teniendo configurada la DNS 8.8.8.8 en mi pc cuando hago
> > algunas consultas con nslookup, muchos dominios .gob.ve aparecen con la
> IP
> > 185.53.178.24, la cual no corresponde a cada dirección consultada sino a
> > Team Internet AG y ya la he reportado en abuse. Ahora, cuando hago
> nslookup
> > desde mi DNS server si aparece la IP que corresponde, por ejemplo,
> > www.seniat.gob.ve - 200.11.221.10.
> >
> > En ambos casos no carga el portal www.seniat.gob.ve.
> >
> > *Por ejemplo, desde una pc cualquiera:*
> >
> > nslookup www.seniat.gob.ve
> > Servidor:  google-public-dns-a.google.com
> > Address:  8.8.8.8
> >
> > Respuesta no autoritativa:
> > Nombre:  www.seniat.gob.ve.*com.ve *
> > Address:  185.53.178.24 (ESTA IP NO CORRESPONDE)
> >
> > *Desde el DNS server:*
> >
> > nslookup www.seniat.gob.ve 8.8.8.8
> > Server: 8.8.8.8
> > Address:8.8.8.8#53
> >
> > Non-authoritative answer:
> > Name:   www.seniat.gob.ve
> > Address: 200.11.221.10
> >
> >
>
> Buenas
> no hice muchas pruebas..pero si me da la ip correcta :
>
> $ nslookup www.seniat.gob.ve 8.8.8.8
>
>
> Server: 8.8.8.8
>
>
> Address:8.8.8.8#53
>
>
>
> Non-authoritative answer:
>
>
> Name:   www.seniat.gob.ve
>
>
> Address: 200.11.221.10
>
>
> $ nslookup www.seniat.gob.ve
> Server: 192.168.0.1
>
>
> Address:192.168.0.1#53
>
>
>
> Non-authoritative answer:
>
>
> Name:   www.seniat.gob.ve
>
>
> Address: 200.11.221.10
>
> con mi server dns privado y con el de google
>
> lo que puede ser que este pasando(en "pc cualquiera") que todas las
> consultas
> de dns lo manden a un servidor X es decir nunca estas consultado al
> servidor
> de google porque hacen un reenvio o DNAT a X..etc..como quieras llamarlo.
> quizas la isp de esa pc hace esto por X motivos..
>
> en definitiva deberias ponerte en contacto con tu proveedor de internet
> y averiguar que esta pasando.
>
> seguro van a decir que es un servidor cache y es para mejorar la
> performance..
> mientras miran a que paginas queres acceder (?)..
>
> saludos
> Matias.-
>
>
>
>

Re: Problema resolución DNS

[Matias Mucciolo]

On Tuesday, August 28, 2018 11:17:56 AM -03 remgasis remgasis wrote:
> Estimada lista,
> 
> un cordial saludo. En esta oportunidad les escribo porque recientemente he
> cambiado la IP de mi servidor DNS y desde ese momento he presentado
> problemas en la resolución DNS de algunas páginas con el dominio .com.ve.
> 
> Destaco que teniendo configurada la DNS 8.8.8.8 en mi pc cuando hago
> algunas consultas con nslookup, muchos dominios .gob.ve aparecen con la IP
> 185.53.178.24, la cual no corresponde a cada dirección consultada sino a
> Team Internet AG y ya la he reportado en abuse. Ahora, cuando hago nslookup
> desde mi DNS server si aparece la IP que corresponde, por ejemplo,
> www.seniat.gob.ve - 200.11.221.10.
> 
> En ambos casos no carga el portal www.seniat.gob.ve.
> 
> *Por ejemplo, desde una pc cualquiera:*
> 
> nslookup www.seniat.gob.ve
> Servidor:  google-public-dns-a.google.com
> Address:  8.8.8.8
> 
> Respuesta no autoritativa:
> Nombre:  www.seniat.gob.ve.*com.ve *
> Address:  185.53.178.24 (ESTA IP NO CORRESPONDE)
> 
> *Desde el DNS server:*
> 
> nslookup www.seniat.gob.ve 8.8.8.8
> Server: 8.8.8.8
> Address:8.8.8.8#53
> 
> Non-authoritative answer:
> Name:   www.seniat.gob.ve
> Address: 200.11.221.10
> 
> 

Buenas
no hice muchas pruebas..pero si me da la ip correcta :

$ nslookup www.seniat.gob.ve 8.8.8.8

  
Server: 8.8.8.8 

 
Address:8.8.8.8#53  

 


 
Non-authoritative answer:   

 
Name:   www.seniat.gob.ve   

 
Address: 200.11.221.10


$ nslookup www.seniat.gob.ve
Server: 192.168.0.1 

 
Address:192.168.0.1#53  

 


 
Non-authoritative answer:   

 
Name:   www.seniat.gob.ve   

 
Address: 200.11.221.10 

con mi server dns privado y con el de google

lo que puede ser que este pasando(en "pc cualquiera") que todas las consultas 
de dns lo manden a un servidor X es decir nunca estas consultado al servidor
de google porque hacen un reenvio o DNAT a X..etc..como quieras llamarlo.
quizas la isp de esa pc hace esto por X motivos..

en definitiva deberias ponerte en contacto con tu proveedor de internet
y averiguar que esta pasando.

seguro van a decir que es un servidor cache y es para mejorar la performance..
mientras miran a que paginas queres acceder (?)..

saludos
Matias.-

Re : Répertoire avec des noms étranges à la racine : -ffffffffffffffff-0000000000

[nicolas . patrois]

Le 28/08/2018 17:02:39, Fabrice Delvallée a écrit :

> Je viens de trouver de deux répertoires aux noms étranges à la racine
> de ma Debian stretch :

[…]

> Bien sur j'ai aucune idée de ce que je faisait le 15 août vers
> 11h18...

> Est-ce grave docteur ?

Vérifie ton disque avec gsmartcontrol.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: sobre direccionamiento de sitios web

[remgasis remgasis]

acl NewYork src 1.1.0.0/14
acl Miami   src 2.2.0.0/14

tcp_outgoing_address 10.2.3.4 NewYork   -> Todo el tráfico de
la red 1.1.0.0/14 sale por 10.2.3.4
tcp_outgoing_address 11.2.3.4 Miami-> Todo el tráfico
de la red 2.2.0.0/14 sale por 11.2.3.4

-

Esto debería funcionar:

acl org  dstdomain "/etc/squid/domains.org"
acl net  dstdomain "/etc/squid/domains.net"

tcp_outgoing_address 10.2.3.4 org   -> Todo el tráfico
de los dominios del archivo domains.org salen por 10.2.3.4
tcp_outgoing_address 11.2.3.4 net-> Todo el tráfico
de los dominios del archivo domains.net salen por 11.2.3.4

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[John Hasler]

Francesco Porro wrote:
> As a member of this mailing list, I have a little (OT) question for you:
> which is the best free email service around to receive mailing lists?

Mark writes:
> I cannot personally recommend any free, proprietary email service
> providers.

I can personally recommend a paid email service: newsguy.com.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: [OT] Best (o better than yahoo) mail provider for malinglists

[Mark Rousell]

On 28/08/2018 17:12, Francesco Porro wrote:
> Ciao,
>
> As a member of this mailing list, I have a little (OT) question for you:
> which is the best free email service around to receive mailing lists?

I cannot personally recommend any free, proprietary email service providers.

Instead I'd say that running your own mail server would be best for
this, assuming you have some kind of always-on connection with a static
IP you can utilise.

Although incoming spam is a potential problem the real difficulties with
running your own mail server in my opinion are (a) maintaining
deliverability of outgoing mail and (b) making sure you're not relaying
spam. Keeping software and configuration up to date is important.
However, in the sort of scenario you describe, you might not need to use
your mail server for outgoing mail which could simplify things. Ideally
you could use your ISP's or domain provider's mail server for outgoing
mail whilst directing incoming mail for your domain to your own server.
(I should add that using your own domain is always wise, rather than
relying on service providers' email addresses).

Learning how to do all this could involve a learning curve but it's
entirely feasible.

-- 
Mark Rousell
 
 
 

sobre direccionamiento de sitios web

[Armando Victor Corona Ramos]

saludos colegas
vengo solicitar ayuda para que me indiquen a resolver este problema:
sucede que tengo una red con mas de 50 pc, un proxy squid3 no transparente,
para las conexiones a internet pero necesito saber como porder redirigir
las peticiones que lleguen, al proxy, para a determinados dominios, como
por ejemplo: .org, .net
para que este los envie a otra pc con windows conectada tambien al router

no se si me explico bien, pero esa es la esencia:
que lo que me llegue al proxy con los dominios anters mencionados, éste me
los envie a otra pc y esta se encargue de mandarlos al router.
estoy conectado a una vpn, me dieron in IP para salida a internet y otro
para acceso a estos dominios.


desde ya muchas gracias

[OT] Best (o better than yahoo) mail provider for malinglists

[Francesco Porro]

Ciao,

As a member of this mailing list, I have a little (OT) question for you:
which is the best free email service around to receive mailing lists?

I mean, somethihng that has a good Imap server, good enough to be
accessed by a MUA like Thunderbird without issues, and good spam filter
which won't bother me with false-positives?.

Now, i'm using a free account on yahoo, as you can see, but I get some
of email bounces and moreover spam filters are really awful: they mark
as spam a lot of non-spam, genuine mails coming from i.e. the
Gnome/Evolution mailing list. Some months ago I was subscribed on my
primary account which is a Gmail one, but then I wanted to separate
mailing lists from the rest (so I moved those to yahoo).

What do you think about GMX?? Is it a good solution for that purpose?
I've already one signed up so i'd would be trivial to set this apart and
move to the @gmx.com one.

Thank you!

-- 
fp

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 15:27, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 02:52:36PM +0100, Mark Rousell wrote:
>> Except for perhaps hacked servers in some cases, FTP never did have
>> much of a
>> part to play in binaries distribution from what I could see.
>
> I guess you didn't use debian? Or are we only talking about the
> illegal content that I thought wasn't the reason usenet is important.
> It's so hard to keep track of what the point was supposed to be.

Oops, I meant to reply to this part.

Lots of people download files from FTP servers but that's a wholly
different culture and use case than Usenet provided for in practice. And
who said that binaries (whether legal or illegal) was not a big part of
Usenet at its height? I certainly said no such thing and nor did you, as
far as I could see.


-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 15:27, Michael Stone wrote:
> I will not bother to reply to the rest of the long discussion of
> usenet, since I don't want to be accused (again) of "incorrectly"
> talking about usenet instead of NNTP by someone who wrote a long
> message about usenet.

Note that I could not refute your apparent conflation of Usenet and NNTP
without writing about Usenet. Admittedly, I also got drawn into a
side-discussion of Usenet history with you.

Anyway, I agree that it is difficult to remember who said what (or,
perhaps more importantly, *why* they said it) when a thread gets as
convoluted as this one.

We can agree to agree about that which we agree about, and to disagree
about that which we disagree about. :-)

-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 14:52, Mark Rousell wrote:
> Additionally, both FTP and HTTP are not federated, many-to-many
> services or systems. I say again that Usenet was unique in this
> timeframe for the use case of public access, one-to-many, binary
> distribution.

The above is not complete. I meant to write this:-

Additionally, both FTP and HTTP were not and are not federated,
one-to-many services or systems in the way that Usenet was (and is). I
say again that Usenet was unique in this timeframe for the use case of
public access, one-to-many, binary distribution.


-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 15:16, Michael Stone wrote:
>
>> As with your other comments about Usenet, this is not an issue for a
>> non-publicly federated system. I.e. The problem that affected Usenet
>> (the
>> ultimate in publicly federated systems) in this context does not
>> affect NNTP in
>> general for discussion group usage.
>
> Sure. But in that context, there's not really much benefit to NNTP
> either. It's just a dumb transport protocol with fewer deployed
> clients than HTTP.

Well, we've discussed this at some length now and I can only say that,
in my opinion and experience, NNTP seems overwhelmingly advantageous to
me in the scenario of a private discussion group (i.e. for a discussion
list much like this one and for the common profile of its members). I
recognise that other people and other types of user prefer access
methodologies (e.g. email lists, web forums, app-based, IM-style, etc.)
but none of that, to my mind, lessens NNTP's ideal applicability to
getting private discussion group messages from place to place (the front
end UI/UX being a different thing again).

>> Remember that we're having this discussion over email. As you
>> observed above,
>> SMTP-based email suffers from a spam problem due to this very issue.
>> And yet
>> this discussion list works. If this list was a NNTP-based discussion
>> group, it
>> would be even more bandwidth-efficient
>
> How? Let's just drop the discussion about how horrible usenet was and
> focus on what the potential benefits of NNTP are. I can't think of
> many (definitely none significant) over SMTP

The key advantage of NNTP over email/SMTP in terms of bandwidth
efficiency is that, with NNTP, messages are only sent to users when they
explicitly ask for them. This is more bandwidth-efficient than an
email-based list since the email-based list must send out messages to
each and every user whether or not they want them.

There is also a management efficiency advantage to NNTP in that it
doesn't have the deliverability problems that plague email nowadays.

> and none at all over a well implemented modern web based discussion
> with a cacheable REST interface.

To my mind, a REST protocol has a different (but overlapping) use case
to NNTP or email lists. I know of no standard, open REST protocol that
replaces either NNTP or email discussion lists, for example.

An often implicitly stated requirement (for certain types of users) in
the private discussion list use case is compatibility with a standard
mail or Usenet/NNTP client. Clearly, this is not important for every
user (and more and more users prefer web UIs nowadays, albeit often in
ignorance of other ways to do things) but I nevertheless take the view
that NNTP has its place and is, technically speaking, a near-ideal
protocol for distribution of discussion groups.

>> This is the issue with what I called "moderator-ability" above.
>>
>> What "noise of an NNTP feed"? A NNTP feed need have no more "noise"
>> than this
>> mail list does. Once again you seem to be conflating NNTP (used in
>> the context
>> of a discussion group like this one or a group of such discussion
>> groups) with
>> the massive volume of Usenet.
>
> Well, you also seem to like to jump back and forth in talking about
> one or the other, without actually offering any specifics. :) You
> brush off the problems of (the only) large scale NNTP implementation
> by offering a closed environment with close to zero users as a
> counterexample.

You seem to have it the wrong way round.

I am not "offering a closed environment with close to zero users as a
counterexample". It (i.e. NNTP in private discussion groups) is not a
counter example of or to anything. It is, in fact, the specific issue
under discussion!

It is *you* who introduced the historical problems of Usenet and used
them as erroneous reasons to reject NNTP for the specific use case under
discussion, that is private discussion groups.

I "brush off" the problems of Usenet because they really do have nothing
whatsoever to do with NNTP in the context of private discussion groups,
for the reasons I have specified. You were conflating Usenet the system
with NNTP the protocol and thereby blaming NNTP for problems that would
have plagued Usenet even if it was still based on UUCP and not NNTP.

Additionally, I got drawn into historical discussions about Usenet with
you but the overall conversation from the perspective of my involvement
is still about the applicability and suitability of NNTP for private
discussions groups (i.e. something for which it is ideal in reality) and
the way that NNTP's involvement in Usenet does not make NNTP a poor
protocol for private discussions groups.

> But I'm happy to stop talking about usenet...except that you bring it
> up again:

But why did you ever mention it, when it was not and is not relevant to
the issue at hand?

I remind you that I only joined in a discussion of Usenet because it was
you who introduced it. I joined in specifically to point out how 

Problema resolución DNS

[remgasis remgasis]

Estimada lista,

un cordial saludo. En esta oportunidad les escribo porque recientemente he
cambiado la IP de mi servidor DNS y desde ese momento he presentado
problemas en la resolución DNS de algunas páginas con el dominio .com.ve.

Destaco que teniendo configurada la DNS 8.8.8.8 en mi pc cuando hago
algunas consultas con nslookup, muchos dominios .gob.ve aparecen con la IP
185.53.178.24, la cual no corresponde a cada dirección consultada sino a
Team Internet AG y ya la he reportado en abuse. Ahora, cuando hago nslookup
desde mi DNS server si aparece la IP que corresponde, por ejemplo,
www.seniat.gob.ve - 200.11.221.10.

En ambos casos no carga el portal www.seniat.gob.ve.

*Por ejemplo, desde una pc cualquiera:*

nslookup www.seniat.gob.ve
Servidor:  google-public-dns-a.google.com
Address:  8.8.8.8

Respuesta no autoritativa:
Nombre:  www.seniat.gob.ve.*com.ve *
Address:  185.53.178.24 (ESTA IP NO CORRESPONDE)

*Desde el DNS server:*

nslookup www.seniat.gob.ve 8.8.8.8
Server: 8.8.8.8
Address:8.8.8.8#53

Non-authoritative answer:
Name:   www.seniat.gob.ve
Address: 200.11.221.10


*En ambos casos no carga el portal http://www.seniat.gob.ve
. *

*Sin embargo, si hago un dig desde mi pc:*

dig ANY seniat.gob.ve

; <<>> DiG 9.9.5-W1 <<>> ANY seniat.gob.ve
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55899
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;seniat.gob.ve. IN  ANY

;; ANSWER SECTION:
seniat.gob.ve.  21599   IN  NS  dns2.cantv.net.
seniat.gob.ve.  21599   IN  NS  dns1.cantv.net.
seniat.gob.ve.  21599   IN  MX  10 mail.seniat.gob.ve.
seniat.gob.ve.  21599   IN  MX  10 correo.seniat.gob.ve.
seniat.gob.ve.  21599   IN  SOA localhost.seniat.gob.ve.
hostmas
ter.cantv.net. 2017071201 172800 3600 1728000 172800

;; Query time: 234 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 28 09:23:59 Hora estßndar de Venezuela 2018
;; MSG SIZE  rcvd: 190

*Obtengo el mismo resultado en el DNS server.*

*Pero cuando hago la traza desde mi pc:*

dig @8.8.8.8 +trace seniat.gob.ve

; <<>> DiG 9.9.5-W1 <<>> @8.8.8.8 +trace seniat.gob.ve
; (1 server found)
;; global options: +cmd
.   242792  IN  NS  m.root-servers.net.
.   242792  IN  NS  b.root-servers.net.
.   242792  IN  NS  c.root-servers.net.
.   242792  IN  NS  d.root-servers.net.
.   242792  IN  NS  e.root-servers.net.
.   242792  IN  NS  f.root-servers.net.
.   242792  IN  NS  g.root-servers.net.
.   242792  IN  NS  h.root-servers.net.
.   242792  IN  NS  i.root-servers.net.
.   242792  IN  NS  a.root-servers.net.
.   242792  IN  NS  j.root-servers.net.
.   242792  IN  NS  k.root-servers.net.
.   242792  IN  NS  l.root-servers.net.
.   242792  IN  RRSIG   NS 8 0 518400
2018090905 201
8082704 41656 .
5JMqHLxtfkQVZ3n/4N9DItagGwt0uroqX+a5zWgE1228kt0DZI1YqhKa qGN
goTO7HPWdlK0/ftMxmfA15jNrdu3nGDjMFnzg5jizv7FtVMJm1jq+
okeJaX8HH4XO6lOBVHw6v1geVS
ve5yZRlx1OUOU/r9WBcOilHnVrt+cx
KzKhy5tejQXveLx8kAS1r4kabfFu0Ct9R0p/2pU3uYbid7E1n
jS2JI+C BmtPplLgqEFR1fzbf3EcTEzKEJihupGdrdtWUyisZZ6W91T4O33HfDmc
OPf9mHbfNLeQcAx
jWvSmQGXuX1X3TtGkWvnb/2z1/0Q0hRHtkYQjN3p3 OyZXZQ==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 68 ms

*;; connection timed out; no servers could be reached*

*Pero desde mi DNS server si la completa:*

dig @8.8.8.8 +trace seniat.gob.ve

; <<>> DiG 9.9.5-3ubuntu0.4-Ubuntu <<>> @8.8.8.8 +trace seniat.gob.ve
; (1 server found)
;; global options: +cmd
.   241686  IN  NS  a.root-servers.net.
.   241686  IN  NS  e.root-servers.net.
.   241686  IN  NS  m.root-servers.net.
.   241686  IN  NS  i.root-servers.net.
.   241686  IN  NS  k.root-servers.net.
.   241686  IN  NS  c.root-servers.net.
.   241686  IN  NS  h.root-servers.net.
.   241686  IN  NS  g.root-servers.net.
.   241686  IN  NS  b.root-servers.net.
.   241686  IN  NS  d.root-servers.net.
.   241686  IN  NS  j.root-servers.net.
.   241686  IN  NS  l.root-servers.net.
.   241686  IN  NS  f.root-servers.net.
.   241686  IN  RRSIG   NS 8 0 

Répertoire avec des noms étranges à la racine : -ffffffffffffffff-0000000000

[Fabrice Delvallée]

Bonjour la liste

Je viens de trouver de deux répertoires aux noms étranges à la racine de 
ma Debian stretch :


Sortie de ls -la /-* :
---
/-0a01-00:
total 8
drwxr-xr-x  2 root root 4096 août  15 11:16 .
drwxr-xr-x 25 root root 4096 août  15 11:18 ..

/--00:
total 8
drwxr-xr-x  2 root root 4096 août  15 11:18 .
drwxr-xr-x 25 root root 4096 août  15 11:18 ..

Sortie de stat /-* :

---

Fichier : /-0a01-00

Taille : 4096 Blocs : 8 Blocs d'E/S : 4096 répertoire

Périphérique : 801h/2049d Inœud : 5111809 Liens : 2

Accès : (0755/drwxr-xr-x) UID : ( 0/ root) GID : ( 0/ root)

Accès : 2018-08-15 11:16:42.123253962 +0200

Modif. : 2018-08-15 11:16:42.123253962 +0200

Changt : 2018-08-15 11:16:42.123253962 +0200

Créé : -



Fichier : /--00

Taille : 4096 Blocs : 8 Blocs d'E/S : 4096 répertoire

Périphérique : 801h/2049d Inœud : 5373953 Liens : 2

Accès : (0755/drwxr-xr-x) UID : ( 0/ root) GID : ( 0/ root)

Accès : 2018-08-15 11:18:18.145037942 +0200

Modif. : 2018-08-15 11:18:18.145037942 +0200

Changt : 2018-08-15 11:18:18.145037942 +0200

Créé : -


Bien sur j'ai aucune idée de ce que je faisait le 15 août vers 11h18...

Est-ce grave docteur ?

Re: mailing list vs "the futur"

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 28, 2018 at 10:32:30AM -0400, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 04:22:56PM +0200, to...@tuxteam.de wrote:

[...]

> >To be fair, this only applies to the brave (pre CDN) old world :)
> 
> No, it applies just as much to CDNs--even more so.

It was very much tongue-in-cheek: I should have attached the ;-P

Thing is, it takes control away from normal pedestrians and gives
it to those who can afford a CDN -- yay, centralized Internet.

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

iEYEARECAAYFAluFY94ACgkQBcgs9XrR2kYBqQCfYsiCkjMhVxdT/DC96vl9zrNb
2X0An0MV+Mki/ra4QCb6/4qZyjzd3TIM
=M6D8
-END PGP SIGNATURE-

Re: Cannot Install/Uninstall sendmail

[Cindy-Sue Causey]

On 8/28/18, Luis Finotti  wrote:
> On Tue, Aug 28, 2018 at 9:41 AM David Wright 
> wrote:
>
>> On Tue 28 Aug 2018 at 09:14:36 (-0400), Luis Finotti wrote:
>> > # apt remove sendemail
>>
>> Oops.
>>
>> > Reading package lists... Done
>> > Building dependency tree
>> > Reading state information... Done
>> > Package 'sendemail' is not installed, so not removed
>> > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
>> > 1 not fully installed or removed.
>> > After this operation, 0 B of additional disk space will be used.
>> > Setting up sendmail-base (8.15.2-11) ...
>>
>> sendmail-base is what you should be trying to remove.
>> And you should be using dpkg directly, not messing around with apt.
>> As you can see, you asked apt to remove something and it tries to
>> configure something instead. If you're going to use sid or a
>> sid lookalike, you're going to have to use the appropriate tools.
>>
>> > dpkg: error processing package sendmail-base (--configure):
>> >  installed sendmail-base package post-installation script subprocess
>> > returned error exit status 255
>> > Errors were encountered while processing:
>> >  sendmail-base
>> > E: Sub-process /usr/bin/dpkg returned an error code (1)
>> > 
>> >
>> > Any help would be greatly appreciated!
>>
>> You see—you want to know what dpkg itself is doing.
>>
>
> Here it is:
>
> # dpkg -P sendmail-base
> (Reading database ... 1562548 files and directories currently installed.)
> Removing sendmail-base (8.15.2-11) ...
> update-inetd: error: --group is only relevant with --add
> dpkg: error processing package sendmail-base (--purge):
>  installed sendmail-base package pre-removal script subprocess returned
> error exit status 255
> Errors were encountered while processing:
>  sendmail-base
>
> Any suggestions?


I've had luck on occasion by following where *my* setup tells me to try:

apt --fix-broken install

Generic just like that with no specific packages named.

Just had to run it a couple times recently. Sometimes I've gotten
lucky, and it fixes things just like that just that fast.

Other times it's like the other day. It will instead first attempt to
purge/remove the offending partially installed package. At one point,
I think I just gave up and let apt do what it thought might work.
Successfully remove a package *is* what it did.

This has just been since the one thread we had here about manually
installing via dpkg and then running into repeated missing
dependencies. I just checked ~/.bash_history and saw my topic was...
*cough* flash versus pepperflash. I was attempting deb package
installs with "dpkg -i" while otherwise only favoring the main
repository in /etc/apt/sources.list.

PS I finally gave up when I realized flash may have NEVER had anything
to do with the particular webpage issues I've had all these years. I
hate ol' timer's disease,.. been afflicted since about 1992. lol.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Inloggen op Active directory

[Wouter Verhelst]

Hoi Bas,

On Tue, Aug 28, 2018 at 03:35:20PM +0200, Bas Neve wrote:
> Beste mensen,
> 
> Inloggen op een active directory domein vanuit Debian95 lukt niet.

Bij mij wel.

> Voor diverse Unix varianten zijn er tools hiervoor beschikbaar zoals
> auth-config op Redhat, Ubuntu heeft pam-auth-update Suse yast. Een confiuratie
> tool voor Debian heb ik echter nog iet gevonden.

Bij Debian heet dat pam-auth-update, maar dat configureert alleen de
PAM-modules. De rest moet je zelf doen.

> Iemand een idee ? 

Niet met de (beperkte) info die je gegeven hebt. Wat heb je geprobeerd?
Wat lukte er niet? Kreeg je foutmeldingen? Zo ja, welke?

Met een vage "het lukt niet" kunnen we je niet helpen...

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Cannot Install/Uninstall sendmail

[Luis Finotti]

Thanks once more for the support!  The problem is now solved.

On Tue, Aug 28, 2018 at 10:20 AM David Wright 
wrote:

> On Tue 28 Aug 2018 at 09:48:06 (-0400), Luis Finotti wrote:
>
> > # dpkg -P sendmail-base
> > (Reading database ... 1562548 files and directories currently installed.)
> > Removing sendmail-base (8.15.2-11) ...
> > update-inetd: error: --group is only relevant with --add
> > dpkg: error processing package sendmail-base (--purge):
> >  installed sendmail-base package pre-removal script subprocess returned
> > error exit status 255
> > Errors were encountered while processing:
> >  sendmail-base
> >
> > Any suggestions?
>
> I would take a look at the pre-removal script sendmail-base.prerm to
> see what it's trying to do. If there are parts that aren't sensible,
> you could comment them out, alter things so that they can work, or
> even just make them "succeed" with "|| true" so you get to the end
> of the script. (Check sendmail-base.postinst while you're about it.)
>
> The scripts will contain a record of what modifications they intended
> to make to your system, so ultimately all you need to do is nullify
> those changes, remove the files in sendmail-base.list and convince
> dpkg that the package is purged. Manually if necessary.
>

Thanks for the pointer!   sendmail-base.prerm had the line:

update-inetd --group MAIL --disable smtp,smtps,submission;

and I was getting the error

update-inetd: error: --group is only relevant with --add

So, I changed it to:

update-inetd --disable smtp,smtps,submission;

and was then able to uninstall it.

Thanks again for your help.

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 04:22:56PM +0200, to...@tuxteam.de wrote:

On Tue, Aug 28, 2018 at 10:16:06AM -0400, Michael Stone wrote:

On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote:
>Isn't this true of, say, HTTP too?

Not in the same way, because you have a sender and a receiver,
without the potentially infinite number of other machines that might
be getting a copy of the content just in case someone might want it
someday.


To be fair, this only applies to the brave (pre CDN) old world :)


No, it applies just as much to CDNs--even more so. The CDN nodes have 
senders and receivers and a financial interest in ensuring a good cache 
rate based both on on-demand caching and predictive caching utilizing 
their knowledge of both. The old usenet machines had to retrieve 
anything that might be needed because they didn't know if a client might 
want it, and they didn't know if they could simply get it from the same 
server later.


Mike Stone

Re: mailing list vs "the futur"

[Dan Purgert]

Gene Heskett wrote:
> On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote:
>
>> On 28/08/2018 12:42, Michael Stone wrote:
>> > Yes and no. NNTP is inherently open to abuse because it wasn't
>> > designed with mechanisms to account for the cost of a transaction.
>> > (This is true of all the early internet protocols, not just NNTP,
>> > which is why we have, e.g., such a spam problem on SMTP.)
>>
>> Isn't this true of, say, HTTP too?
>
> [...] I had a long talk with  
> him just last week about how they are doing this new protocol where they 
> A: don't bother to verify me when I get redirected to their servers for 
> a one time code pad number to verify the authorization of my purchase.

him who?  your bank?


-- 
|_|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: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 02:52:36PM +0100, Mark Rousell wrote:

Except for perhaps hacked servers in some cases, FTP never did have much of a
part to play in binaries distribution from what I could see.


I guess you didn't use debian? Or are we only talking about the illegal 
content that I thought wasn't the reason usenet is important. It's so 
hard to keep track of what the point was supposed to be.


I will not bother to reply to the rest of the long discussion of usenet, 
since I don't want to be accused (again) of "incorrectly" talking about 
usenet instead of NNTP by someone who wrote a long message about usenet. 


Mike Stone

Re: mailing list vs "the futur"

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 28, 2018 at 10:16:06AM -0400, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote:
> >Isn't this true of, say, HTTP too?
> 
> Not in the same way, because you have a sender and a receiver,
> without the potentially infinite number of other machines that might
> be getting a copy of the content just in case someone might want it
> someday.

To be fair, this only applies to the brave (pre CDN) old world :)

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

iEYEARECAAYFAluFWsAACgkQBcgs9XrR2kbfnQCfQ0lI+rZAe9RsUYZOJmboRKjs
A84AnjtkqIdZwH0MYJ6wNfukMxRiNpR/
=GAEE
-END PGP SIGNATURE-

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 02:03:05PM +0100, Mark Rousell wrote:

Isn't this true of, say, HTTP too?


Not in the same way, because you have a sender and a receiver, without 
the potentially infinite number of other machines that might be getting 
a copy of the content just in case someone might want it someday.



As with your other comments about Usenet, this is not an issue for a
non-publicly federated system. I.e. The problem that affected Usenet (the
ultimate in publicly federated systems) in this context does not affect NNTP in
general for discussion group usage.


Sure. But in that context, there's not really much benefit to NNTP 
either. It's just a dumb transport protocol with fewer deployed clients 
than HTTP.



Remember that we're having this discussion over email. As you observed above,
SMTP-based email suffers from a spam problem due to this very issue. And yet
this discussion list works. If this list was a NNTP-based discussion group, it
would be even more bandwidth-efficient


How? Let's just drop the discussion about how horrible usenet was and 
focus on what the potential benefits of NNTP are. I can't think of many 
(definitely none significant) over SMTP, and none at all over a well 
implemented modern web based discussion with a cacheable REST interface.



   But certainly you can identify or deal with an abusive customer on HTTP
   much easier than you can identify and remediate abuse within the noise of
   an NNTP feed.


This is the issue with what I called "moderator-ability" above.

What "noise of an NNTP feed"? A NNTP feed need have no more "noise" than this
mail list does. Once again you seem to be conflating NNTP (used in the context
of a discussion group like this one or a group of such discussion groups) with
the massive volume of Usenet.


Well, you also seem to like to jump back and forth in talking about one 
or the other, without actually offering any specifics. :) You
brush off the problems of (the only) large scale NNTP implementation by 
offering a closed environment with close to zero users as a counterexample. 
But I'm happy to stop talking about usenet...except that you bring it up 
again:



I suspect you might criticise my description of Usenet (or NNTP) as a "one
known user to [...]" system but the sender of a Usenet message was known to
exactly the same extent as a SMTP email sender. In the timeframe under
discussion, both Usenet and SMTP email carry the same requirement (or lack
thereof) for authentication. There was no difference (either in practice or
theory) whatsoever.


There was, in that you could use a throwaway account to broadcast a 
message to a large number of effectively anonymous but long-term users. 
In the SMTP context it's really hard to have throwaway accounts send to 
other throwaway accounts, allow the content to be durable, and be 
discoverable. The closest analogy was shared mail accounts used as 
dropboxes, but the clients of those were easily tracked once the account 
was identified.



NNTP is ideally suited to sharing messages in a client/server
fashion. As I have observed, it is more efficient in this regard (in terms of
bandwidth-efficiency as well as management efficiency) than email lists and it
is at least as efficient in these terms (and likely more bandwidth-efficient)
than web forums.


You've asserted it many times, but you haven't actually shown with 
numbers how it's more efficient in practice to any degree that matters 
in the real world. When sending via SMTP you consolidate messages per 
ISP/mail domain, and the backend mail server can deduplicate (or avoid 
duplicating) the incoming messages if that's an administrative priority. 
In practice, the volume of something like the debian lists is so low 
compared to the volume of background spam it doesn't even really matter. 
If reading via REST in a caching HTTP environment it's even more 
efficient since you won't retrieve even a single copy of a message 
unless it's requested. In practice there's not much caching these days 
for a variety of reasons but again, compared to the overall volume of 
web traffic the load of debian discussion groups is too small to matter.



I am surprised to see you say that NNTP is "too complicated". In the medium
term future I'll have to implement a NNTP server and, having looked at the
RFCs, it doesn't look too bad. Have you experience of implementing NNTP?


Make sure that your NNTP implementation is interoperable with your web 
forum, because if it doesn't it's a dead end. (And duplicative--we 
already have a lot of unused NNTP server code.) It's not that NNTP is 
necessarily complicated in itself, it's that making it interoperate with the 
expectations of a modern web forum is hard--potentially impossible 
without proprietary extensions, at which point you've thrown away the 
entire point of sticking with NNTP instead of using something else. The 
conceptual split between transit and reading functionality is a lot of 
legacy to carry 

Re: Cannot Install/Uninstall sendmail

[David Wright]

On Tue 28 Aug 2018 at 09:48:06 (-0400), Luis Finotti wrote:

> # dpkg -P sendmail-base
> (Reading database ... 1562548 files and directories currently installed.)
> Removing sendmail-base (8.15.2-11) ...
> update-inetd: error: --group is only relevant with --add
> dpkg: error processing package sendmail-base (--purge):
>  installed sendmail-base package pre-removal script subprocess returned
> error exit status 255
> Errors were encountered while processing:
>  sendmail-base
> 
> Any suggestions?

I would take a look at the pre-removal script sendmail-base.prerm to
see what it's trying to do. If there are parts that aren't sensible,
you could comment them out, alter things so that they can work, or
even just make them "succeed" with "|| true" so you get to the end
of the script. (Check sendmail-base.postinst while you're about it.)

The scripts will contain a record of what modifications they intended
to make to your system, so ultimately all you need to do is nullify
those changes, remove the files in sendmail-base.list and convince
dpkg that the package is purged. Manually if necessary.

Cheers,
David.

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 13:16, Mark Rousell wrote:
>
> Footnote:-
> 1: A more recent example of a very similar skewed and confused view of
> things is the Casio F-91 watch. Certain elements of US intelligence
> had noticed that many terrorist suspects arrested in Iraq were wearing
> the Casio F-91W watch model. The intelligence reports extrapolated
> this apparent correlation to suggest, amongst other things, that the
> watch was chosen because its alarm capabilities allowed an alarm to be
> set more than 24 in the future (in fact that particular model allows
> no such thing, although some other Casio models do). In truth, the
> Casio F-91W model was and still is popular with third world terrorist
> suspects because it is (a) very cheap, and (b) it is produced in
> greater numbers than any other watch model in the world. I.e. Lots of
> people in third world countries wear Casio F-91Ws, not just
> terrorists. And yet the intelligence people were ignorant of the wider
> popularity of the F-91W and extrapolated incorrectly from the limited
> (skewed) data set of which they were aware. Similar errors of limited
> vision, confusion, and skew were made in the timeframe we're
> discussing here by some people running training course for professionals.

I just noticed a typo in the above. Here is the corrected version:

A more recent example of a very similar skewed and confused view of
things is the Casio F-91 watch. Certain elements of US intelligence had
noticed that many terrorist suspects arrested in Iraq were wearing the
Casio F-91W watch model. The intelligence reports extrapolated this
apparent correlation to suggest, amongst other things, that the watch
was chosen because its alarm capabilities allowed an alarm to be set
more than 24 hours in the future and so it would be useful as a bomb
timer. (In fact that particular model allows no such thing although some
other Casio watch models do). In truth, the Casio F-91W model was and
still is popular with third world terrorist suspects because it is (a)
very cheap, and (b) it is produced in greater numbers than any other
watch model in the world. I.e. Lots of people in third world countries
wear Casio F-91Ws, not just terrorists. And yet the intelligence people
were ignorant of the wider popularity of the F-91W and extrapolated
incorrectly from the limited (skewed) data set of which they were aware.
Similar errors of limited vision, confusion, and skew were made in the
timeframe we're discussing here by some people running training courses
for certain types of professional.



-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 13:55, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 01:16:45PM +0100, Mark Rousell wrote:
>> NNTP was inefficient in this regard compared to what other protocol or
>> protocols, exactly?
>
> FTP and later HTTP, which handled binaries efficiently. In fact, one
> was even named in a way to suggest it was a good way to transfer
> files. :)

HTTP came later and wasn't relevant in the timeframe to which you referred.

Additionally, both FTP and HTTP are not federated, many-to-many services
or systems. I say again that Usenet was unique in this timeframe for the
use case of public access, one-to-many, binary distribution.

Except for perhaps hacked servers in some cases, FTP never did have much
of a part to play in binaries distribution from what I could see.

I think it was file sharing P2P protocols that eventually reduced
people's preference for Usenet coupled with (as you say) ISPs' great
difficulty in continuing to support Usenet servers.

> Yes, academic, commercial ISP, and paid subscription servers. I also
had some insight into what it took
> to keep the servers running, not just the user-side view... I followed
a number of text groups, until the
> signal to noise ratio got low enough to make it not worth the effort.

I too was a Usenet user in that timeframe and worked for an ISP at the
time, although not directly on Usenet/NNTP servers.

> You seem to have an overly idealistic view of the level of logging on
> most news servers 20 years ago.

You mean about the same amount of logging as on mail servers, FTP
servers, or anything else at the time, then?

Sure, there wasn't much logging in practice. I didn't say there was. I'm
not being idealistic. I am simply observing that, logging or not,
accessing a NNTP server did not hide one's IP address any more then than
it does now. Indeed, despite greater legislation-mandated logging in
many countries, the technical opportunities to access a server of
potentially any type in a genuinely anonymous way are much greater now
than they were back then due to widespread availability of VPN services!

I therefore do not agree that anonymity was a primary driving factor for
the use of Usenet for one-to-many distribution of binaries (although I
don't doubt that the essentially false idea of anonymity may have
influenced many less-expert users). I'm not being idealistic about the
amount of access logging that went on when I say this; I am simply being
pragmatic. I am being pragmatic because Usenet was simply the only
widely available, worldwide, federated, public system available to
distribute data (especially binaries) in a one-to-many manner. Other
systems or protocols such as FTP just couldn't do what Usenet could do
back then.

> Also, for the record, I don't think I ever had a "training course" on
> usenet.

That's good. :-)

> As far as being wrong...if LE siezed an anonymous FTP server
> distributing illegal content and either reviewed its logs or monitored
> its link they could get a list of each IP that accessed content.

And the very same applied to a NNTP server attached to Usenet (or a
standalone NNTP server for that matter). It was and is no more difficult
for a NNTP server than for a FTP server, or an email server, or anything
else.

> There is no central point from which you can see who accessed usenet
> content.

But why would you expect there to be? It's a federated system. If you
were expecting such a thing then you were expecting the wrong thing.

One might also observe that looking for who accessed Usenet content is
surely a waste of time. If one is interested in preventing distribution
of illegal data of some sort then the primary concern is the sender, and
the sender was not anonymous with NNTP (regardless of the existence of
logs or not). Remember, the point here is one-to-many distribution, and
it's the one that law enforcement should surely be interested in.

> The bottom line is that for a period of time, usenet was the easiest
> way to obtain certain illegal content. There were certainly overblown
> reports that usenet was nothing but illegal content, and it's
> certainly possible to transfer illegal content via other protocols,
> but it's naive and/or disingenous to pretend that usenet didn't have a
> problem.

Oh I agree with you on this about Usenet.

But:
(a) I don't blame NNTP for this since it is not responsible for Usenet's
problems that ultimately derived from its massive scale, not its
protocols. The problems occurred as a result of the fact that Usenet was
and is a massive, worldwide, publicly federated one-to-many distribution
system. I.e. It was custom made (without its creators even realising
it!) for large scale distribution of binaries, whether legal or illegal.

(b) I dispute that Usenet had any real, reliable anonymity (although I
accept that some people may have erroneously believed it did). I have no
idealism or inflated idea about the level of logging that was common at
the time on any server, regardless of 

Re: [Buster]: KDE wierdness: missing window titlebars + more

[local10]

Aug 28, 2018, 3:40 AM by hdv.ja...@gmail.com:

> See the tread with the title "lots of issues with KDE after update" starting 
> at
> the 27th. Hans Ulrich and I are experiencing the same type of trouble in 
> testing
> at the moment.
>
Thanks for confirming it.

Re: Cannot Install/Uninstall sendmail

[Luis Finotti]

Thanks for the reply again.

On Tue, Aug 28, 2018 at 9:41 AM David Wright 
wrote:

> On Tue 28 Aug 2018 at 09:14:36 (-0400), Luis Finotti wrote:
>
> > # apt remove sendemail
>
> Oops.
>
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Package 'sendemail' is not installed, so not removed
> > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> > 1 not fully installed or removed.
> > After this operation, 0 B of additional disk space will be used.
> > Setting up sendmail-base (8.15.2-11) ...
>
> sendmail-base is what you should be trying to remove.
> And you should be using dpkg directly, not messing around with apt.
> As you can see, you asked apt to remove something and it tries to
> configure something instead. If you're going to use sid or a
> sid lookalike, you're going to have to use the appropriate tools.
>
> > dpkg: error processing package sendmail-base (--configure):
> >  installed sendmail-base package post-installation script subprocess
> > returned error exit status 255
> > Errors were encountered while processing:
> >  sendmail-base
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> >
> > Any help would be greatly appreciated!
>
> You see—you want to know what dpkg itself is doing.
>

Here it is:

# dpkg -P sendmail-base
(Reading database ... 1562548 files and directories currently installed.)
Removing sendmail-base (8.15.2-11) ...
update-inetd: error: --group is only relevant with --add
dpkg: error processing package sendmail-base (--purge):
 installed sendmail-base package pre-removal script subprocess returned
error exit status 255
Errors were encountered while processing:
 sendmail-base

Any suggestions?

Re: mailing list vs "the futur"

[Gene Heskett]

On Tuesday 28 August 2018 09:03:05 Mark Rousell wrote:

> On 28/08/2018 12:42, Michael Stone wrote:
> > Yes and no. NNTP is inherently open to abuse because it wasn't
> > designed with mechanisms to account for the cost of a transaction.
> > (This is true of all the early internet protocols, not just NNTP,
> > which is why we have, e.g., such a spam problem on SMTP.)
>
> Isn't this true of, say, HTTP too?

Yes, and in most cases spamassassin and friends are incapable of dealing 
with this. Judging any html only message as a very high probability of 
being spam. And the windows oriented idijits in charge of net services 
such as my banks online activities, aren't aware of that, so they've 
been deleting any plain text from their messages. I had a long talk with  
him just last week about how they are doing this new protocol where they 
A: don't bother to verify me when I get redirected to their servers for 
a one time code pad number to verify the authorization of my purchase.

B: I pointed out that the current method is dependant on a cookie that 
exists only on this machine, and likely this browser since palemoon has 
never worked for this.  And that this precludes my ability to goto any 
machine on my local net, fire up its browser and goto a vendors site and 
make a purchase.

I pointed out to him that he had other means of I'ding me that were both 
far more universal and would work just as well if this machine was in 
pieces and I was actually logging on from the browser on my milling 
machine in the garage.  Thats the presence of a list of security 
questions only I can answer, and which would via the https link that 
exists, give me that one time pad number without emailing it to far less 
secure a machine that is in parts on the front deck for its annual 
dusting and cleaning.

He agreed that it was at least as secure and that he would look into 
implementing it as an alternative way of identifying the account holder.

We'll see. Who was it that said words similar to "progress in driven by 
the obstinate?" I can be that, and proud of it.

[...]

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Cannot Install/Uninstall sendmail

[David Wright]

On Tue 28 Aug 2018 at 09:14:36 (-0400), Luis Finotti wrote:

> # apt remove sendemail

Oops.

> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'sendemail' is not installed, so not removed
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up sendmail-base (8.15.2-11) ...

sendmail-base is what you should be trying to remove.
And you should be using dpkg directly, not messing around with apt.
As you can see, you asked apt to remove something and it tries to
configure something instead. If you're going to use sid or a
sid lookalike, you're going to have to use the appropriate tools.

> dpkg: error processing package sendmail-base (--configure):
>  installed sendmail-base package post-installation script subprocess
> returned error exit status 255
> Errors were encountered while processing:
>  sendmail-base
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> Any help would be greatly appreciated!

You see—you want to know what dpkg itself is doing.

Cheers,
David.

Inloggen op Active directory

[Bas Neve]

Beste mensen,

Inloggen op een active directory domein vanuit Debian95 lukt niet.
Voor diverse Unix varianten zijn er tools hiervoor beschikbaar zoals
auth-config op Redhat, Ubuntu heeft pam-auth-update Suse yast. Een
confiuratie tool voor Debian heb ik echter nog iet gevonden.

Iemand een idee ?

Graag ontvang ik een bevestiging retour.

Met vriendelijke groet,

Bas Neve
bastiaann...@gmail.com
316 14 12 00 71

Re: processing order for configuration files in /etc/network/interfaces.d

[David Wright]

On Sun 26 Aug 2018 at 21:36:30 (+0300), Martin T wrote:
> Hi David,
> 
> > You need to post your evidence, starting with your /etc/network/interfaces
> > file. You say you're using ifup, so we can perhaps discount this paragraph:
> >
> >Currently, "source-directory" isn't supported by
> >network-manager and guessnet.

Actually, I haven't quite figured out what this means. AIUI if an
interface is defined in /e/n/i then NM shouldn't configure it anyway.
Does it mean that if you define one in a "source-directory" directory,
NM won't realise and so might try to configure it itself?

> > but we don't know whether you're using "source-directory" or "source",
> > for example.
> 
> I'm using "source":
> 
> # cat /etc/network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> source /etc/network/interfaces.d/*
> #
> 
> > If you care about the order in which these files are sourced,
> > for the time being I would source them individually in the order you
> > want.
> 
> Yes, this is probably a good idea. However, ideally, "man interfaces"
> should state in which order files in /etc/network/interfaces.d/ are
> processed.

We also need to look at your evidence as to the configuration order
actually executed. I'm not yet convinced that your /tmp/interfaces_test
tells the right answer in view of the following statement:

   "When ifupdown is being called with the --all option, before doing
anything to interfaces, if calls all the hook scripts (pre-up or
down) with IFACE set to "--all", LOGICAL set to the current value
of --allow parameter (or "auto" if it's not set), ADDRFAM="meta"
and METHOD="none". After all the interfaces have been brought up
or taken down, the appropriate scripts (up or post-down) are
executed."

That includes  ifup -a  of course.

Cheers,
David.

Re: Cannot Install/Uninstall sendmail

[Luis Finotti]

Firstly, thanks for the reply!

On Tue, Aug 28, 2018 at 9:04 AM David Wright 
wrote:

> On Mon 27 Aug 2018 at 12:38:42 (-0400), Luis Finotti wrote:
> > Hi everyone,
> >
> > I'm having trouble installing/removing sendmail in Debian Sid (well,
> > aptosid -- http://www.aptosid.com -- actually).
>
> Perhaps their forums might help.
>

I tried:
http://www.aptosid.com/index.php?name=PNphpBB2=viewtopic=18661#18661

I've got some of the hints that I mentioned I've tried already from them.


>
> > I tried to install and it failed: https://pastebin.com/Qu2jRqsn
> >
> > 'apt -f install' did not fix it, nor did 'dpkg --configure -a'.
> >
> > Since it was not essential (and did not install correctly), I tried to
> > uninstall it, but it also fails:
>
> […]
>
> > One notices in the failed install attempt (the pastebin link above):
> >
> > --
> > adduser: Warning: The home directory `/var/lib/sendmail' does not belong
> to
> > the user you are currently creating.
> > update-inetd: warning: cannot add service, /etc/inetd.conf does not exist
> > --
> >
> > I had:
> > --
> > # ls -ld /var/lib/sendmail
> > drwx-- 2 smmta smmta 4096 Aug 22 15:06 /var/lib/sendmail/
> > --
> >
> > Changing ownership to root did not allow me to uninstall it.
>
> What's the output from this attempt?
>

Here it is:


# ls -ld /var/lib/sendmail/
drwx-- 2 root root 4096 Aug 22 15:06 /var/lib/sendmail/

# apt remove sendemail
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'sendemail' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up sendmail-base (8.15.2-11) ...
Usage: update-inetd [...]  

Commands:
  --add   add 
  --remove   remove 
  --enable [,...]enable  (comma-separated list)
  --disable [,...]   disable  (comma-separated list)

Options:
  --group add entry to section 
  --pattern  use  to select a service
  --comment-chars use  as comment characters
  --multi allow multiple removes/disables
  --fileuse  instead of /etc/inetd.conf
  --verbose   explain what is being done
  --debug enables debugging mode
  --help  display this help and exit
  --version   output version information and exit

In order to prevent the shell from changing your  definition you
have to quote the  using single or double quotes. You can use
tabs
(tab character or \t) and spaces to separate the fields of the .

Note: users must use --comment-chars '#' to disable a service for that
setting
to survive upgrades. Package maintainer scripts should use the default
--comment-chars. See update-inetd(8) for details.

Usage: update-inetd [...]  

Commands:
  --add   add 
  --remove   remove 
  --enable [,...]enable  (comma-separated list)
  --disable [,...]   disable  (comma-separated list)

Options:
  --group add entry to section 
  --pattern  use  to select a service
  --comment-chars use  as comment characters
  --multi allow multiple removes/disables
  --fileuse  instead of /etc/inetd.conf
  --verbose   explain what is being done
  --debug enables debugging mode
  --help  display this help and exit
  --version   output version information and exit

In order to prevent the shell from changing your  definition you
have to quote the  using single or double quotes. You can use
tabs
(tab character or \t) and spaces to separate the fields of the .

Note: users must use --comment-chars '#' to disable a service for that
setting
to survive upgrades. Package maintainer scripts should use the default
--comment-chars. See update-inetd(8) for details.

Usage: update-inetd [...]  

Commands:
  --add   add 
  --remove   remove 
  --enable [,...]enable  (comma-separated list)
  --disable [,...]   disable  (comma-separated list)

Options:
  --group add entry to section 
  --pattern  use  to select a service
  --comment-chars use  as comment characters
  --multi allow multiple removes/disables
  --fileuse  instead of /etc/inetd.conf
  --verbose   explain what is being done
  --debug enables debugging mode
  --help  display this help and exit
  --version   output version information and exit

In order to prevent the shell from changing your  definition you
have to quote the  using single or double quotes. 

Re: Cannot Install/Uninstall sendmail

[David Wright]

On Mon 27 Aug 2018 at 12:38:42 (-0400), Luis Finotti wrote:
> Hi everyone,
> 
> I'm having trouble installing/removing sendmail in Debian Sid (well,
> aptosid -- http://www.aptosid.com -- actually).

Perhaps their forums might help.

> I tried to install and it failed: https://pastebin.com/Qu2jRqsn
> 
> 'apt -f install' did not fix it, nor did 'dpkg --configure -a'.
> 
> Since it was not essential (and did not install correctly), I tried to
> uninstall it, but it also fails:

[…]

> One notices in the failed install attempt (the pastebin link above):
> 
> --
> adduser: Warning: The home directory `/var/lib/sendmail' does not belong to
> the user you are currently creating.
> update-inetd: warning: cannot add service, /etc/inetd.conf does not exist
> --
> 
> I had:
> --
> # ls -ld /var/lib/sendmail
> drwx-- 2 smmta smmta 4096 Aug 22 15:06 /var/lib/sendmail/
> --
> 
> Changing ownership to root did not allow me to uninstall it.

What's the output from this attempt?

Cheers,
David.

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 12:42, Michael Stone wrote:
> Yes and no. NNTP is inherently open to abuse because it wasn't
> designed with mechanisms to account for the cost of a transaction.
> (This is true of all the early internet protocols, not just NNTP,
> which is why we have, e.g., such a spam problem on SMTP.)

Isn't this true of, say, HTTP too?

As with your other comments about Usenet, this is not an issue for a
non-publicly federated system. I.e. The problem that affected Usenet
(the ultimate in publicly federated systems) in this context does not
affect NNTP in general for discussion group usage.

Remember that we're having this discussion over email. As you observed
above, SMTP-based email suffers from a spam problem due to this very
issue. And yet this discussion list works. If this list was a NNTP-based
discussion group, it would be even more bandwidth-efficient, it would
not suffer from deliverability problems that email over SMTP can bring,
and moderator-ability would not be an issue either (see below for more
on this).

> But certainly you can identify or deal with an abusive customer on
> HTTP much easier than you can identify and remediate abuse within the
> noise of an NNTP feed.

This is the issue with what I called "moderator-ability" above.

What "noise of an NNTP feed"? A NNTP feed need have no more "noise" than
this mail list does. Once again you seem to be conflating NNTP (used in
the context of a discussion group like this one or a group of such
discussion groups) with the massive volume of Usenet.

In fact, there is no difference whatsoever in the ability of moderators
to identify and/or deal with abusive users on NNTP-based discussion
groups compared to web-based forums. Equally in both cases, abusive
messages can be seen by moderators, pre-moderation is potentially
possible in both cases, messages can be deleted, and users can be
suspended/banned or whatever. The only difference is that deletion of
previously posted messages in a web-forum is always visible to everyone
whereas message deletion is not retrospectively visible for
already-downloaded messages received by NNTP (although this does depend
to some extent on client software implementation).

Let me say again that the problems that you often ascribe to NNTP are
actually problems with Usenet (i.e. a massively and publicly federated
system that happened to use NNTP) and are nothing to do with NNTP itself
in the scenario under discussion here.

> I remember the heroic efforts that abuse staff were trying in the mid
> to late 90s, but it just wasn't possible. SMTP was able to mitigate
> the worst problems by instituting spam filters and dropping
> connections from shady corners of the internet--especially open
> relays. But this was possible even to approach because SMTP involves a
> known sender and a known receiever, so if a message is lost either the
> sender or receiever can try to resolve the problem. It's much less
> clear how you cut off NNTP servers without getting
> silently-disconnected islands of news and a horrible user experience
> for everyone.

Again, this is an issue with Usenet, not NNTP. Whilst these things were
a problem, I think you are further wrong to compare email to Usenet in
this context. The reason I say this is because email in this context is
a one-to-one system (i.e. as you say, one known user to one known user
in this context) whereas NNTP fulfilled a different use case entirely:
It was one-to-many (i.e. one known user to many unknown users).

Therefore there was no point in trying to 'fix' Usenet in this context.
It was working as intended. Email was fixable because its use case was
fundamentally different (even though email can be used for similar
things to Usenet).

I suspect you might criticise my description of Usenet (or NNTP) as a
"one known user to [...]" system but the sender of a Usenet message was
known to *exactly* the same extent as a SMTP email sender. In the
timeframe under discussion, both Usenet and SMTP email carry the same
requirement (or lack thereof) for authentication. There was no
difference (either in practice or theory) whatsoever.

> You can "solve" the problem by keeping NNTP in a walled garden
> (disconnecting from usenet) but then you lose a lot of the inherent
> advantages of NNTP and end up with a protocol that's kinda overweight
> for the simple problem of transferring a few text messages in a
> client/server fashion.

Where did you get that idea from? You're still seeing things from a
Usenet-centric perspective. There is no need to see things that way.

We're not talking about "disconnecting from usenet", as you put it. The
use case under discussion here never was connected to Usenet. As I
mentioned in another recent message, ISPs were hosting private
NNTP-based discussion groups long before they dropped Usenet-connected
NNTP servers.

There is nothing about NNTP that requires it to be connected to Usenet.
You lose nothing whatsoever in the context under discussion here: That

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 01:16:45PM +0100, Mark Rousell wrote:

NNTP was inefficient in this regard compared to what other protocol or
protocols, exactly?


FTP and later HTTP, which handled binaries efficiently. In fact, one was 
even named in a way to suggest it was a good way to transfer files. :)



May I ask, did you use Usenet in this timeframe?


Yes, academic, commercial ISP, and paid subscription servers. I also had 
some insight into what it took to keep the servers running, not just the 
user-side view... I followed a number of text groups, until the signal 
to noise ratio got low enough to make it not worth the effort.



I disagree. This attitude (that anonymity was the primary driver) is redolent
of the confused or skewed training courses I referred to above. Whilst I can
accept that some people may have perceived Usenet to be anonymous, they were of
course wrong both then and now (and this was well known to technical users back
at that time).


You seem to have an overly idealistic view of the level of logging on 
most news servers 20 years ago. Also, for the record, I don't think I 
ever had a "training course" on usenet.


As far as being wrong...if LE siezed an anonymous FTP server 
distributing illegal content and either reviewed its logs or monitored 
its link they could get a list of each IP that accessed content. There 
is no central point from which you can see who accessed usenet content.  
You might be able to get that by investigating every usenet server on 
the internet, but it's enough of a harder problem that access was 
effectively anonymous up until large providers started actively trying 
to address certain kinds of activity (and then, only for those 
providers). You may be referring to whether the posting is anonymous, 
which is a quite different question. It's certainly much easier to track 
a post to a single origin, though jurisdictional boundaries could make 
it hard to actually do anything with that information. The bottom line 
is that for a period of time, usenet was the easiest way to obtain 
certain illegal content. There were certainly overblown reports that 
usenet was nothing but illegal content, and it's certainly possible to 
transfer illegal content via other protocols, but it's naive and/or 
disingenous to pretend that usenet didn't have a problem.



I should add that I described Usenet as an "efficient" distribution medium
above and it most certainly was efficient in this respect. Even though, as you
say, NNTP needs to encode binaries, Usenet was still efficient because of its
one-to-many capability and its asynchronous capability. It just worked.


The one to many capability simply didn't outweigh the enormous volume of 
one-to-none-via-many. Even back in the day there were a lot of really 
passionate advocates of the theoretical greatness of the service, with 
no clue of how much it was costing to provide.



And let me re-iterate that none of this history, whilst interesting,
particularly relates to NNTP's continued suitability for discussion groups such
as this one.


Well, there's no particularly relevant discussion of how suitable it is 
for email lists like this one. :) If 25 years of advocacy haven't 
managed to get debian to understand how wonderful it would be to switch 
from SMTP lists to NNTP groups, it's really unlikely to happen going 
forward. Instead, it's likely that the theoretical advantages don't 
nearly outweigh the practical disadvantages.


Mike Stone

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 12:10, Michael Stone wrote:
> On Tue, Aug 28, 2018 at 09:39:43AM +0200, to...@tuxteam.de wrote:
>> No. I guess the thing is that *because* NNTP was comparatively
>> efficient,
>> it was used for the "big stuff" (alt.pic.* anyone?). The point is that,
>> to reap the benefits of its efficiency, a provider has to set up an
>> NNTP server and do its care and feeding. And perhaps prune the
>> newsgroups
>> it's ready to carry. A full feed was, for that time, taxing, but not
>> because NNTP was inefficcient, but because that's where the big stuff
>> was. No one mailed pictures or archives around (unless, that is, to
>> punish the occasional spammer: X11 sources were mailed around, if I
>> remember correctly)
>
> NNTP was fairly inefficient for large binaries because they were
> repacked to 7 bits and then chopped up into small pieces, some of
> which tended to get lost--so either the entire thing is reposted or
> enough redundant information was sent to survive the loss of some
> pieces. And the servers kept exchanging the data whether anyone
> requested/looked at it or not.

NNTP was inefficient in this regard compared to what other protocol or
protocols, exactly?

Compared to email? Well, email suffered from very similar issues
transferring binaries.

Compared to DCC over IRC? (DCC being a then-popular one-to-one
alternative to Usenet's one-to-many distribution model). I must admit
that I've never examined the details of the DCC protocol but it is
certainly inefficient in terms of /user experience/ compared to Usenet
over NNTP: In practice DCC was essentially synchronous, one at a time,
needing continuous user management whereas Usenet facilitated a
time-efficient asynchronous access mechanism for the end user without
continuous management.

So what one-to-many distribution platforms or protocols existed in this
timeframe against which to compare NNTP (or Usenet)?

And you are persisting in conflating NNTP with Usenet. The problem with
Usenet (as you say) was the volume of binaries, /which would have been a
problem no matter protocol was used to transfer them, /regardless of the
efficiency of NNTP. This problem with Usenet does not, however,
translate to any kind of inherent efficiency problem with NNTP as a
transfer mechanism for discussions.

May I ask, did you use Usenet in this timeframe? I ask this because some
of your comments remind me of training courses run for certain types of
professional at that time which were taught by people who, themselves,
commonly had only limited, and sometimes very skewed and confused,
experience of the systems and protocols they were supposedly experts
on[1]. Thus what they taught was close to, but not quite, an accurate
representation of how things really were. In particular, conflation of
worldwide systems like Usenet with specific protocols like NNTP is an
example of some of the inaccuracies or errors of comprehension that they
passed on to their students. As I said in my other recent message,
Usenet (at that time and now) relied and relies on NNTP but NNTP is not
tainted by the problems of Usenet.

If you are saying that NNTP was not designed to carry binaries then you
are of course correct but (a) just like other protocols, it has been
extended to do so, and (b), as I observed above, what are you comparing
it to in terms of efficiency? As a one-to-many (not anonymous, see
below) distribution medium it had no real alternative at the time.

> Heck, even the moderation (where it existed) was inefficient--first,
> transfer the spam; then, store the spam; transfer the cancel message;
> store the cancel message; check to see if the spam is in the stored
> messages; finally, delete the spam or wait for it to be transferred.

Certainly, NNTP moderation over the federated Usenet system was far less
than ideal but, once again, let's remember that this is not a problem
for a discussion group that is not shared over Usenet. Moderation using
NNTP in this context (i.e. the context under discussion here) is
actually better than with a mail list and not a lot different to a web
forum.

> Binaries on NNTP took off not because they were efficient, but because
> they were perceived to be more anonymous than direct transfers.
> (There's no central logs of which clients look at which specific
> content, and the full feed is deniable as to intent.)

I disagree. This attitude (that anonymity was the primary driver) is
redolent of the confused or skewed training courses I referred to above.
Whilst I can accept that some people may have perceived Usenet to be
anonymous, they were of course wrong both then and now (and this was
well known to technical users back at that time).

>From what I recall, Usenet grew in popularity for binaries groups not
because it was (supposedly, in some people's views) anonymous but
because it was an *efficient one-to-many distribution medium*. In fact
it was effectively the *only* one-to-many distribution medium available
at all until the first 

Re: Curiositat sobre les IP assignades pels proveïdors

[Joan]

Com diu l'Orestes, diria que Parlem ho fa... Però Parlem no te
permanència ;-)

Joan

El Mon, 27 Aug 2018 14:24:46
+0200 Pedro  va escriure el següent:

> Gràcies per la precisió Jordi.
> 
> M'alegro de continuar aprenent.
> 
> Però si us plau, digueu els proveïdors que estan fent NAT als usuaris!
> 
> Que si no dones de baixa el producte en 15 dies te l'has de menjar un
> any (permanència).
> 

Re: mailing list vs "the futur"

[Dan Purgert]

Michael Stone wrote:
> On Mon, Aug 27, 2018 at 12:28:35PM -0400, Dan Ritter wrote:
>>On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote:
>>>
>>> That bandwidth limit is not on your side of the isp, its the bandwidth
>>> from the main trunk lines to the isp. NNTP is a huge bandwidth hog
>>> regardless of how much of it your isp accepts for spooling on local disk
>>> to serve you.
>>>
>>
>>This is not the case.
>
> Yes it is. Most ISPs stopped supporting NNTP because of the ridiculous 
> bandwidth (and disk space) demands. 

I cant see *text* based NGs requiring nearly as much space (or
bandwidth) as modern (i.e. HTML-based) email. Now, if you're talking
about the "binary" groups, yeah, that's going to be a complete mess, and
I can see why they wouldn't want to carry those groups.

> Your rebuttal skipped over the part about people posting off-topic
> junk all over the place, and the fact that (the couple of cranks who

Don't see OT trash as any more painful than spam emails, not to mention
all the crap that people willingly sign up for.

> [...] A full newsfeed hit 1TB/day in the early 2000s, and most of the
> ISPs who were still trying to provide the service threw the towel in
> at that point. The costs were through the roof, the fraction of
> customers who used the service was miniscule, and almost nobody
> canceled because they turned off the news server.

I take it "a full newsfeed" includes those binary groups, huh?  I mean,
E-S is only pushing an average of a few hundred MB/day -- BUT they only
carry the text groups.


> [...]
> There's a reason usenet is effectively dead. It was a great idea 
> technically, on a "safe" network. It's completely incapable of dealing 
> with abuse on the open internet.

Except it's still around, and still dealing with the open internet.
Sure, it's not very widely used, but if it couldn't deal with the
internet, it wouldn't exist at all.

Furthermore, it's not that the ~protocol~ is bad by any means, just that
the content is effectively worthless.  I mean, given the proliferation
of spam, one could argue similarly against email.

> In theory you can still use an NNTP client (vs a server) to follow a 
> limited number of text-only groups fairly efficiently. In practice 
> there's just not that much left worth following because the experience 
> got to be so bad, and because so few people are even aware it exists 
> anymore. If you purchase newsgroup service as a standalone from a 
> specialized company you typically get a somewhat more curated experience 
> (for a pretty sizable fraction of the total price of your internet 
> connection, to pay the costs outlined above). The reality is that the 
> primary use of these services is downloading pirated software and other 
> binaries.

No theory needed - it works perfectly well.  There's enough still out
there that's worth reading; although I don't expect that NNTP will
necessarily stick around for the rest of my lifetime.


-- 
|_|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: programs freeze in /

[Gary Hodder]

On Tue, 2018-08-28 at 09:15 +0300, Reco wrote:
>   Hi.
> 
> On Tue, Aug 28, 2018 at 03:57:42PM +1000, Gary Hodder wrote:
> > Hi all,
> > In midnight commander if I go to the / directory mc freezes.
> > This also happens in leafpad the cursor just stays spinning and
> > nothing
> > happens.
> > Both mc and leathpad were started from a root console.
> > I have 2 machine both on 9.5 and both do the same.
> > Is there a fix for this?
> 
> Sharing the result of "strace ls /" and "dmesg | tail -100" (should
> be
> executed in this order) would be a good place to start.
> 
> Reco
> 
Found the problem, it was a nfs mount where the machine was shut down
without unmounting the share.

Thanks
Gary.

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 09:15:43AM +0100, Mark Rousell wrote:

You appear to be conflating the NNTP protocol with Usenet, the global message
transmission network. They are different things. Usenet as we currently know it
relies on NNTP but NNTP is not Usenet.

Whilst I agree that it is true that ISPs stopped running their own
Usenet-linked NNTP servers for the reasons you describe, it is nevertheless
wholly false to say that NNTP is the problem in this context. The problem was
Usenet and the massive bulk of binary groups. NNTP was not and is not to blame
for Usenet's excess. Any distribution protocol would have been a bandwidth hog
in those circumstances.


Yes and no. NNTP is inherently open to abuse because it wasn't designed 
with mechanisms to account for the cost of a transaction. (This is true 
of all the early internet protocols, not just NNTP, which is why we 
have, e.g., such a spam problem on SMTP.) But certainly you can identify 
or deal with an abusive customer on HTTP much easier than you can 
identify and remediate abuse within the noise of an NNTP feed. I 
remember the heroic efforts that abuse staff were trying in the mid to 
late 90s, but it just wasn't possible. SMTP was able to mitigate the 
worst problems by instituting spam filters and dropping connections from 
shady corners of the internet--especially open relays. But this was 
possible even to approach because SMTP involves a known sender and a 
known receiever, so if a message is lost either the sender or receiever 
can try to resolve the problem. It's much less clear how you cut off 
NNTP servers without getting silently-disconnected islands of news and a 
horrible user experience for everyone. You can "solve" the problem by 
keeping NNTP in a walled garden (disconnecting from usenet) but then you 
lose a lot of the inherent advantages of NNTP and end up with a protocol 
that's kinda overweight for the simple problem of transferring a few 
text messages in a client/server fashion. In theory it would be nice to 
just be able to access web-based discussion lists via NNTP so you could 
use a generic client and customize the interface. But this isn't a thing 
that's done much; the NNTP protocol is both too complicated and also too 
lacking in functionality that modern discussion group members look for. 
There are probably more people using tapatalk for that purpose--even 
though it's hideous and proprietary--simply because it's a better fit 
than NNTP for a modern discussion group.


Mike Stone

Re: canvis en el su.

[Pere Nubiola Radigales]

Possan el
ALWAYS_SET_PATH yes

funciona perfectament.
Gracies

Pere Nubiola Radigales
Telf: +34 656316974
e-mail: p...@nubiola.cat
   pnubi...@fsfe.org
   pere.nubi...@gmail.com


2018-08-27 20:06 GMT+02:00 Eloi :

> El 27/8/18 a les 16:58, Pere Nubiola Radigales ha escrit:
> > Algú sap el perqué del canvis del su?
> > .
> > Fins ara amb la crida su es reinicialitzaba el path  amb el del usuari
> > root, mantenint la resta del entorn.
> > Ara si vols el path de root, necessites fer su -, reinicialitzant tot
> > l'entorn.
> >
> > Pere Nubiola Radigales
> > Telf: +34 656316974
> > e-mail: p...@nubiola.cat 
> >pnubi...@fsfe.org 
> >pere.nubi...@gmail.com 
> >
> Enganxo la nota enviada per apt-listchanges al correu local explicant el
> canvi
>
> util-linux (2.32-0.4) unstable; urgency=medium
>
>   The util-linux implementation of /bin/su is now used, replacing the
>   one previously supplied by src:shadow (shipped in login package), and
>   bringing Debian in line with other modern distributions. The two
>   implementations are very similar but have some minor differences (and
>   there might be more that was not yet noticed ofcourse), e.g.
>
>   - new 'su' (with no args, i.e. when preserving the environment) also
> preserves PATH and IFS, while old su would always reset PATH and IFS
> even in 'preserve environment' mode.
>   - su '' (empty user string) used to give root, but now returns an error.
>   - previously su only had one pam config, but now 'su -' is configured
> separately in /etc/pam.d/su-l
>
>   The first difference is probably the most user visible one. Doing
>   plain 'su' is a really bad idea for many reasons, so using 'su -' is
>   strongly recommended to always get a newly set up environment similar
>   to a normal login. If you want to restore behaviour more similar to
>   the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
>
>  -- Andreas Henriksson   Fri, 03 Aug 2018 10:52:22 +0200
>
>
>

Re: mailing list vs "the futur"

[Michael Stone]

On Tue, Aug 28, 2018 at 09:39:43AM +0200, to...@tuxteam.de wrote:

No. I guess the thing is that *because* NNTP was comparatively efficient,
it was used for the "big stuff" (alt.pic.* anyone?). The point is that,
to reap the benefits of its efficiency, a provider has to set up an
NNTP server and do its care and feeding. And perhaps prune the newsgroups
it's ready to carry. A full feed was, for that time, taxing, but not
because NNTP was inefficcient, but because that's where the big stuff
was. No one mailed pictures or archives around (unless, that is, to
punish the occasional spammer: X11 sources were mailed around, if I
remember correctly)


NNTP was fairly inefficient for large binaries because they were 
repacked to 7 bits and then chopped up into small pieces, some of which 
tended to get lost--so either the entire thing is reposted or enough 
redundant information was sent to survive the loss of some pieces. And 
the servers kept exchanging the data whether anyone requested/looked at 
it or not.  Heck, even the moderation (where it existed) was 
inefficient--first, transfer the spam; then, store the spam; transfer 
the cancel message; store the cancel message; check to see if the spam 
is in the stored messages; finally, delete the spam or wait for it to be 
transferred.


Binaries on NNTP took off not because they were efficient, but because 
they were perceived to be more anonymous than direct transfers. (There's 
no central logs of which clients look at which specific content, and the 
full feed is deniable as to intent.) This lead to a big child 
pornography problem, among other issues (not usenet's finest moment). 
Things are not nearly as anonymous now as they were 20 years ago and the 
most illegal content has tended to move elsewhere. (Though "anonymous 
VPN access" remains a feature point for the subscription news 
services--and this is not for the benefit of people accessing comp.misc.)


It really doesn't seem like you ever looked at the stats on what 
fraction of the feed an ISP received was ever requested by any customer, 
or you wouldn't argue that this was an efficient mechanism. (But god 
forbid you stopped carrying alt.binaries.stupid.waste.of.space because 
then customers would tie up the support line complaining that your 
newsgroup count was lower than your competitor's newsgroup count.) Again, 
nice idea 30 years ago, but incapable of withstanding abuse on the modern 
internet.

Re: Curiositat sobre les IP assignades pels proveïdors

[Joan G. Villaraco]

Hola Orestes i companyia,

A mi em va passar el mateix amb Pepehone (ADSL) i Yoigo (fibra) amb el
CG-NAT, només has de consultar-lis com fer la petició per a que t'ho
treguin i et passin a una IP legal d'internet. Jo ho vaig fer per a tots
dos proveïdors sense cap problema i totes dues connexions em van assignar
IPs accessibles.

Joan


El lun., 27 ago. 2018 a las 13:42, Orestes Mas ()
escribió:

> Hola a tothom,
>
> Observo un fenomen curiós, i m'agradaria saber si algú de vosaltres s'hi
> ha trobat.
>
> Fa pocs dies m'he posat fibra a casa. Volia obrir el port 22 del router
> per poder accedir des de fora via ssh a un ordinador. Això ja ho feia
> amb el proveïdor antic i no tenia cap problema, però ara amb el router
> nou no em funcionava. La IP pública, segons m'indiquen webs del tipus
> "whatismyip" era 93.176.xxx.yyy (canvia si reboto el router).
>
> Però com que no em funcionava m'hi he barallat una estona i al final
> acabo deduint que el proveïdor d'internet utilitza una xarxa privada
> interna (una classe B, suposo, amb adreces de l'interval
> 100.76.xxx.yyy). I surt a internet amb unes quantes adreces públiques
> compartides entre diversos usuaris.
>
> Les preguntes: Us heu trobat que el proveïdor d'internet faci NAT també?
> Sabeu si com a usuaris ens podem queixar (ja imagino que no...)? Vaig
> errat si dedueixo que això impedirà que funcioni qualsevol accés a casa
> iniciat des de l'exterior (tipus emule, bittorrent,ssh , httpd...)?
> Suposo que funcionarà entre usuaris de la xarxa privada, però com que
> només són 65536 això no és massa esperançador...
>
> Orestes
>
>
>

Re: mailing list vs "the futur"

[Mark Rousell]

On 28/08/2018 00:04, Gene Heskett wrote:
> My knowledge is based on a conversation I had with my then isp in about 
> 1993 or so, so its entirely possible that the protocol has been changed 
> since then. What they had then struck me as very very wastefull of 
> resources. Because I was such a PITA, they actually built another 
> machine for NNTP and had at bring in another oc3 circuit to feed it. I 
> had what was a full house Amiga 2000 with 64 megs of ram on a PP 040 
> board, had a pair of 1GB scsi seagates, their machine had a 47GB drive, 
> which was filled in just an hour or so, so the expire was set at 8 
> hours. So the last thing I did at night was dial them up and grab what I 
> wanted that was new, and the first thing in the morning, the same.
>
> Sheer economics has likely driven some major changes in how NNTP works 
> today. And I expect thats a hell of a lot better for the average ma & pa 
> isp. By the time I built a new machine and put red hat 5 on it, in 1998 
> I think, NNTP had degenerated to 90% spam, so I never rejoined that pool 
> party, it was too polluted for me. Email was easier to filter, and here 
> I am still, almost 20 years later, and older too, I'll be 84 in a couple 
> more months if I don't miss morning roll call first.

As in my reply to Michael Stone, posted just now, you are conflating
NNTP with Usenet. The problems you describe above are all to do with
Usenet, not with the NNTP protocol per se.

NNTP is not a bandwidth hog. It is not now and never has been.

Usenet was (and still is) a bandwidth hog, but it would have been so no
matter protocol was used to transmit it.

-- 
Mark Rousell
 
 
 

Re: mailing list vs "the futur"

[Mark Rousell]

On 27/08/2018 21:13, Michael Stone wrote:
> On Mon, Aug 27, 2018 at 12:28:35PM -0400, Dan Ritter wrote:
>> On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote:
>>>
>>> That bandwidth limit is not on your side of the isp, its the bandwidth
>>> from the main trunk lines to the isp. NNTP is a huge bandwidth hog
>>> regardless of how much of it your isp accepts for spooling on local
>>> disk
>>> to serve you.
>>>
>>
>> This is not the case.
>
> Yes it is. Most ISPs stopped supporting NNTP because of the ridiculous
> bandwidth (and disk space) demands. Your rebuttal skipped over the
> part about people posting off-topic junk all over the place, and the
> fact that (the couple of cranks who actually just wanted to read
> comp.misc or whatever aside) most people who wanted "newsgroups"
> really wanted the high volume binary groups with pirated software or
> movies or whatever--so if an ISP dropped the high volume part of the
> NNTP feed, they basically had no reason not to drop the whole thing.
> Back in the late 90s when the handwriting was on the wall it was
> pushing toward 100GB/day to keep up with a full newsfeed.

You appear to be conflating the NNTP protocol with Usenet, the global
message transmission network. They are different things. Usenet as we
currently know it relies on NNTP but NNTP is not Usenet.

Whilst I agree that it is true that ISPs stopped running their own
Usenet-linked NNTP servers for the reasons you describe, it is
nevertheless wholly false to say that NNTP is the problem in this
context. The problem was Usenet and the massive bulk of binary groups.
NNTP was not and is not to blame for Usenet's excess. Any distribution
protocol would have been a bandwidth hog in those circumstances.

> In theory you can still use an NNTP client (vs a server) to follow a
> limited number of text-only groups fairly efficiently. In practice
> there's just not that much left worth following because the experience
> got to be so bad, and because so few people are even aware it exists
> anymore. If you purchase newsgroup service as a standalone from a
> specialized company you typically get a somewhat more curated
> experience (for a pretty sizable fraction of the total price of your
> internet connection, to pay the costs outlined above). The reality is
> that the primary use of these services is downloading pirated software
> and other binaries.

Even here, where you recognise that NNTP can be used for discussions
just like this mail list, you still seem to viewing NNTP primarily
within the context of Usenet. There is no need for NNTP-based
discussions to involve the single, federated Usenet system.

It is certainly true that NNTP has fallen out of favour for private
discussion groups (nothing to do with Usenet) but there are lots of
reasons for this (a long and complex discussion in its own right), and
Usenet's problems with volume are only peripherally connected to the
reduction in the use of NNTP for text-based discussions of the nature
carried here.

Both mail list-based discussion groups and NNTP-based discussion groups
have reduced in popularity as web-based forums have increased in
popularity, despite the fact that web-based forums are not an exact
replacement for the use cases of either email or NNTP. This change in
popularity never had and does not have any connection with the bandwidth
requirements of Usenet (regardless of the protocol used to carry it)/

It should be noted that private NNTP-based groups that were not shared
with Usenet existed long before ISPs stopped providing Usenet feeds as
part of their general service.

In truth, NNTP (colloquially but incorrectly referred to as "Usenet") is
still a great protocol for private discussions groups such as this mail
list and many others likes it, even if few[1] use it. Used in this
manner, NNTP is not and *never was* a bandwidth hog. NNTP is probably
more bandwidth-efficient overall than an email discussion list and as,
or potentially more, bandwidth-efficient than a web-based forum. NNTP
may have fallen out of favour for this type of use case (primarily in
favour of web forums as things now stand) but it can and does still do
the job in a bandwidth-efficient manner.



Footnote:-
1: For example, Mozilla still use NNTP discussions groups which are
mirrored as email lists.

-- 
Mark Rousell
 
 
 

Re: [Buster]: KDE wierdness: missing window titlebars + more

[hdv@gmail]

On 2018-08-28 07:24, local10 wrote:
> Aug 27, 2018, 6:00 PM by cyaiple...@sitesplace.net:
> 
>> I had that happen not too long ago in Stretch. I just rebooted and it was OK.
>>
> A reboot didn't do it for me, the issue still persist.
> 
> 
>> You may want to also check your settings in Display - Compositor. You may 
>> have to change to a different rendering backend. Also you might want to 
>> uncheck any experimental options if you have them checked.
>>
> What's even stranger I can't find the KDE System Preferences app (what 
> package is it in, by the way?), so I can't even find a way to change  
> display/keyboard/mouse/etc KDE settings. I installed buster fresh, that is, 
> there were no left over libs/config files/etc that would affect the new KDE 
> installation yet something is very screwed up with either KDE on my PC or 
> with KDE packages in testing.
> 
> Anyone using KDE in buster? If so, are you experiencing any issues with KDE 
> like missing window titlebars, missing apps, etc.?
> 
> Thanks
> 

See the tread with the title "lots of issues with KDE after update" starting at
the 27th. Hans Ulrich and I are experiencing the same type of trouble in testing
at the moment.

Grx HdV

Re: mailing list vs "the futur"

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Aug 27, 2018 at 07:04:36PM -0400, Gene Heskett wrote:
> On Monday 27 August 2018 12:28:35 Dan Ritter wrote:
> 
> > On Mon, Aug 27, 2018 at 11:37:48AM -0400, Gene Heskett wrote:
> > > [...] NNTP is a huge
> > > bandwidth hog regardless of how much of it your isp accepts for
> > > spooling on local disk to serve you.

This keeps coming up stubbornly in this thread: it is wrong.
NNTP, with its flood-filling algorithm, is fairly efficient
wrt. link usage. It was developed in a time when bandwidth
was expensive, and folks back then were no idiots, mind you.

> >
> > This is not the case.
> >
> > The NNTP server-to-server algorithm is analogous to rsync,
> > if you think of:

[...]

Yes, kind of.

> My knowledge is based on a conversation I had with my then isp in about 
> 1993 or so, so its entirely possible that the protocol has been changed 
> since then.

NNTP hasn't changed much since 1986, no.

> What they had then struck me as very very wastefull of 
> resources. Because I was such a PITA, they actually built another 
> machine for NNTP and had at bring in another oc3 circuit to feed it.

No. I guess the thing is that *because* NNTP was comparatively efficient,
it was used for the "big stuff" (alt.pic.* anyone?). The point is that,
to reap the benefits of its efficiency, a provider has to set up an
NNTP server and do its care and feeding. And perhaps prune the newsgroups
it's ready to carry. A full feed was, for that time, taxing, but not
because NNTP was inefficcient, but because that's where the big stuff
was. No one mailed pictures or archives around (unless, that is, to
punish the occasional spammer: X11 sources were mailed around, if I
remember correctly)

Video streaming these days is much less efficient.

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

iEYEARECAAYFAluE/D8ACgkQBcgs9XrR2kavwACeJriYNwJmdGKjh6QtIH+7qMQ0
YX4AnRR4KDbBeQTuRDtTF5OoDltCviy/
=o96w
-END PGP SIGNATURE-

programs freeze in /

[Gary Hodder]

Hi all,
In midnight commander if I go to the / directory mc freezes.
This also happens in leafpad the cursor just stays spinning and nothing
happens.
Both mc and leathpad were started from a root console.
I have 2 machine both on 9.5 and both do the same.
Is there a fix for this?

Thanks
Gary.

Re: programs freeze in /

[Reco]

Hi.

On Tue, Aug 28, 2018 at 03:57:42PM +1000, Gary Hodder wrote:
> Hi all,
> In midnight commander if I go to the / directory mc freezes.
> This also happens in leafpad the cursor just stays spinning and nothing
> happens.
> Both mc and leathpad were started from a root console.
> I have 2 machine both on 9.5 and both do the same.
> Is there a fix for this?

Sharing the result of "strace ls /" and "dmesg | tail -100" (should be
executed in this order) would be a good place to start.

Reco

programs freeze in /

[Gary Hodder]

Hi all,
In midnight commander if I go to the / directory mc freezes.
This also happens in leafpad the cursor just stays spinning and nothing
happens.
Both mc and leathpad were started from a root console.
I have 2 machine both on 9.5 and both do the same.
Is there a fix for this?

Thanks
Gary.