Re: Making Debian available

[lange]

Another very odd thing I found.

On https://www.debian.org/CD/faq/
there's no hint about images including non-free firmware. No hint
about firmware at all. And then this FAQ


Where is the CD image with non-free?
  .
Sometimes, someone is kind enough to create unofficial non-free CDs. If you 
cannot find any links on this website, you can try asking on the debian-cd 
mailing list.


So we do not tell our users that we (the CD team I guess) already
create these very usefull images including non-free firmware. And then
we tell the users to search the link themselves. Not very friendly.


Please improve the FAQ and add a link to the ISO our end user need to
install their notebook with Debian.


-- 
regards Thomas

Re: RFC: pam: dropping support for NIS/NIS+?

[lange]

Hi,

I'm using NIS since 20+ years in a small network with about 60 computers.
Since I manage all computers and the physical network can be seen as secure
(I know it's not perfect secure) I do not need the additional crypto
features of NIS+ or LDAP, which would be overkill. All my users use
yppasswd on the NIS master for changing their password. I guess I
still need pam support for this because I set things like this in
pam.d/common-password:

passwordrequisite   pam_cracklib.so retry=3 difok=3 
minlen=14


Yes, I surely would miss the NIS support.

-- 
regards Thomas

Re: RFC: pam: dropping support for NIS/NIS+?

[lange]

> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek  
> said:

> If your users are using yppasswd on the NIS master for changing passwords,
> then evidently you are not relying on support for NIS in PAM.  (yppasswd
> doesn't even link against libpam.)
Thanks for clarifying this.

-- 
regards Thomas

Re: RFC: pam: dropping support for NIS/NIS+?

[lange]

> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek  
> said:

> NIS also dates from a period when rsh was considered acceptable, and unless
> I'm mistaken, has a comparable level of security.  Allowing access to
> password hashes for users based on the IP of the machine you are querying
> from is not a sane security policy, and I don't think we should indefinitely
> make Debian worse for all other users (bigger minimal system == worse) to
> cater to users of these obsolete, insecure systems.

A normal user does not see the password hashes, only processes which
can use a port < 1024 see the password hash in the NIS map.

So I do not see a problem giving machines of a subnet (based on their
IP) access to the NIS data, when I can make sure only permitted
computers can access the network. This does not give all users of this
machine access to the password hashes.

-- 
regards Thomas

directory for icons

[Thomas Lange]

Hi

my package fai-server will include a command faimond-gui which needs
some icons. Were should I put those icons?

/usr/share/packagename/icons or
/usr/share/commandname/icons or
/usr/share/icons/packagename

or a different location? I could not find anything in the policy,
developers-reference or FHS concerning this.

-- 
regards Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#563004: ITP: procserv -- A process server with telnet console and log access

[Ralph Lange]

Package: wnpp
Severity: wishlist
Owner: Ralph Lange 


* Package name: procserv
  Version : 2.5.0
  Upstream Author : Ralph Lange 
* URL : http://sourceforge.net/projects/procserv/
* License : GPLv3
  Programming Lang: C++
  Description : A process server with telnet console and log access

procServ is a wrapper that starts an arbitrary command as a child process in
the background, connecting its standard input and output to a TCP port for
telnet access. It supports logging, child restart (manual or automatic on
exit), and more.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#563004: ITP: procserv -- A process server with telnet console and log access

[Ralph Lange]

Hello,

On Wed 30 Dec 2009 2:07:16 Frank Lin PIAT wrote:

I am curious why ssh+screen can't do the job? It would be much more
secure than telnet. It would be nice to add a note in the package
description.

Also it is much more "à la unix" to use two tools together to do one
job, each one doing one thing well.
  


Here's a bit of background:
procServ origins as a tool for the open source accelerator and physics 
control system software EPICS (http://www.aps.anl.gov/epics). In that 
context it is mainly used to run "soft" EPICS I/O processes in the 
background, while giving access to the console (stdin/stdout) of the 
process through a local telnet port. These soft IOC (input/output 
controller) processes are doing real-time (as fas as Linux allows) 
stuff, are heavily multi-threaded, doing lots of socket-based IO.
The other, "hard" IOCs in control systems are usually VME-based systems 
running a real-time OS, with their serial console wired to a terminal 
server, that allows telnet access. (Some with, most without authentication.)


A ssh/screen combination was used to run the soft IOCs in the beginning, 
but we had many reports that using nifty features of screen (like 
browsing the history buffer) would stall threads and eventually crash 
the child process. Also (to provide the rich set of features), screen 
always assumes the connecting terminal is interactive and understands 
VT100 escape sequences, which is not the case when using a more generic 
console access and logging facility like conserver, where connecting to 
screen sessions fill up log files with escape sequences that make 
viewing the log impossible.


So to make things simpler, a lot more stable, and actually more "à la 
unix", procServ was created as a small, simple facility that runs a 
child process and connects the console to a telnet server, and that's 
it. No history browsing, no authentication, no multiple, named, 
individually colored background sessions, no terminal escape sequences. 
It adds some system-service level features that screen misses, like 
restarting the child manually or automatically (with a grace period), 
blocking characters that could kill the child, creating PID files, etc.


To keep things secure, procServ only allows telnet connections from 
localhost, so the suggested tool chain is 
conserver(/ssh/)telnet/procServ: conserver doing multi-user mode, 
authentication/authorization, central logging, etc., either running 
locally (connecting by telnet to procServ), or remote (connecting by ssh 
then telnet to procServ). Within a control system, the use of conserver 
allows to integrate the "hard" and "soft" IOCs in exactly the same 
fashion, i.e. access to the console, log files etc. is the same for VME 
real-time and Linux soft real-time IOCs.


Ralph


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

FAI workshop

[Thomas Lange]

Hi all,

again this year, we will held a FAI workshop meeting from july 2-4 at
the Linuxhotel (http://www.linuxhotel.de) in Essen, Germany. 
People which already use FAI meet there to work the whole weekend on
improving the FAI software like we did in the past.

If you have experiences with FAI and like to join the workshop, please
write an email to me.

We have a littel agenda, which gives a minor timeline:

Friday: 
- Meet and greet
- Setup the network
- Changes in squeeze: what is related to FAI?
- Define important things in FAI to be done for squeeze
- Which packages in Debian are important for FAI? Are they in good shape?

Saturday:
- Discuss all FAI bugs, fix them, or add comments at least
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=fai
- FAI packages in Ubuntu. What needs to be done? How to improve the
  collaboration?
- Release management for FAI: stable, experimental, beta packages
- Automatic tests. Do we need virtual machines for that?

Sunday:
- Development of FAI: discussion of new features, enhancements, ideas
- FAI for other distributions
- Final round: What did we mangage to do this weekend 


The workshop website includes more detailed topics for discussion and to work 
on.
http://faiwiki.informatik.uni-koeln.de/index.php/DeveloperWorkshopJuly2010

About FAI:

 FAI is a non-interactive system to install, customize and manage
 Linux systems and software configurations on computers as well as
 virtual machines and chroot environments, from small networks to
 large infrastructures and clusters.

 http://www.informatik.uni-koeln.de/fai

-- 
regards Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19483.32638.113176.368...@suenner.informatik.uni-koeln.de

re: debian pxe dhcp netinstall (debconf enterprise fai etc.)

[Thomas Lange]

on ... <[EMAIL PROTECTED]> wrote:

> First i tried "fai", but while i liked the concept of
> classes it was to much of a hassle and the number of scripts and
> dependencies was to much to understand in 4 hours (after which i gave up). 
Did you try the simple example DEMO in FAI? Did you read chapter 4.8 "For the 
impatient user"?
I think one should get FAI work in 4 hours. But even if this time was
not enough, you could  additionaly have spend the time you needed for
writing your installation scripts.

> name. It seemed to me that its development had cheased. But the death knell 
> to fai was that it is currently not supporting "debconf". With the fallback 
> or override
But you can extend fai (using hooks) to use debconf and debwrap
(debwrap was new to me - looks pretty nice) as you do in your
scripts. This should take only a few minutes to write such a hook.

> The whole process is "nearly working". Some things are missing such as
> that nis does not add +::: to the corresponding files and such packages
AFAIK, NIS does not need this line any more. Use the file nsswitch.conf instead.


> ... or debconf asking for manual input. Especially debconf with its
> initial dialog when first installed was annoying
Never seen this with FAI.

 
> I would like to have some feedback, especially on the topic of
> doing automatic updates with an cron job. I would also like to hear of
> some hints if there is an other tool which does the job (debix,
Some guys are using FAI not only for the initial installation, but
also for updates and daily maintenance. They are using FAI's new command fcopy
for this.

> script files. I think the whole automatic management thing (which is
> also the reason behind the whole "enterprise" discussion) has a lot of
> potential. Having the ability to reconfigure large clusters or
You're right. Automating system administration and configuration
management is a hot topic these days. Do you know these references?

Automating Unix and Linux Administration by Kirk Bauer 

Bootstrapping an Infrastructure (1998)  Steve Traugott, Joel Huddleston
Proceedings of the Twelth Systems Administration Conference (LISA XII) (USENIX 
Association: Berkeley, CA)


I think you should spend some more time to look a FAI. Most of the
things you need for an automatied installation are already implemented
and working for a lot of users for their clusters, labs and
desktops. Also two of the top500 cluster where build using FAI.
If you need debconf or debwrap support, it's eaesy to extend FAI to
support it. But then you have also the nice class system.

I also have problems, when people are trying to write some code from
scratch. Often they only spend a few weeks or month in coding, then
this project will fall asleep and all their good work is lost. Second,
do not underestimate the time you will need to get a lot of users that
will test your software. Without other users, your software will not
become better, because you can't find all the bugs yourself. To
summarize, I invite you to join the FAI mailling list and help improve
FAI, so it will also meet your needs.

-- 
best regards Thomas Lange (author of FAI)
http://www.informatik.uni-koeln.de/fai/

automatic selection which kernel image to install

[Thomas Lange]

Is there a script, that can automaticly determine the best or correct
name of the kernel-image that should be installed?

I think something with grep and sed from /proc/cpuinfo should write
k7, k6, 586tsc or someing else to stdout. Has someone created this
script already ?

  kernel-image-2.4.18-k7
  kernel-image-2.4.18-k6
  kernel-image-2.4.18-686-smp
  kernel-image-2.4.18-686
  kernel-image-2.4.18-586tsc
  kernel-image-2.4.18-386

-- 
 Thomas

Re: debian-new-packages-announce@l.d.o ?

[Thomas Lange]

On Mon, May 07, 2001 at 08:40:19PM +0200, Piotr Krukowiecki wrote:
| Hi
| 
| What do you think about making a new list which would be used to
| announce new packages in Debian ?
| It could be done automatically, when package is uploaded for the first
| time. It would contain description of package etc.
| DWN includes some info about new packages, but it's not very
| informative.
| 

Great. It should contain the package name, the section where it will
put into the archive and the short description from the control file.

-- 
 Thomas

Re: Automating dpkg-reconfigure answers via a shell script

[Thomas Lange]

>>>>> On Thu, 13 Sep 2001 16:26:32 +0200, "VALETTE Eric" <[EMAIL PROTECTED]> 
>>>>> said:

> Wichert Akkerman wrote:
>>> It should be possible to do
>>> 
>>> dpkg -i pkg.deb <>> 
>>  No it should not, that is completely the wrong way to do
>> it. That is just a hack to work around debconf not working
>> properly for you or packages not using it yet.

> I disagree. Debconf will never be able to answer anything that I
> want and that is not default. If debconf is able to handle
> default value correctly, I will then need to use
> dpkg-reconfigure to change the default value. I want to make it
> non interactively. Other solution is to not install the packages
> that need special configuration and install them using dpkg -i
> and a way tio give the values I want.

> And if you look at the fai software
> 
<http://www.informatik.uni-koeln.de/fai/fai-guide.html/ch-instprocess.html#s-icscripts>

> They have faced excatly the same problem meaning they have also
> found no solution. I think we should have dpkg-reconfigure (or
> dpkg or whatever) be able to overide default pacakge installtion
> value from a file.

The best solution would be that all postinst scripts use debconf. The
We do not need this dirty trick.

-- 
 Thomas
--
Thomas Lange
Institut fuer Informatikmailto:[EMAIL PROTECTED]
   Universitaet zu Koeln
Pohligstr. 1Telefon: +49 221 470 5303
 50969 KoelnFax: +49 221 470 5317

1024D/AB9B66FD AEA6 A8C1 BD8E 67C4 8EF6  8BCA DC13 E54E AB9B 66FD
--

how to move a config file during package upgrade

[Thomas Lange]

Hi,

my package fai will have a new location for its configuration file
/etc/fai.conf. The next version will use /etc/fai/fai.conf. How can I
handle this in a preinst script during an upgrade ? Any examples would
be fine.

-- 
 Thomas
--
Thomas Lange
Institut fuer Informatikmailto:[EMAIL PROTECTED]
   Universitaet zu Koeln
Pohligstr. 1Telefon: +49 221 470 5303
 50969 KoelnFax: +49 221 470 5317

1024D/AB9B66FD AEA6 A8C1 BD8E 67C4 8EF6  8BCA DC13 E54E AB9B 66FD
--

Re: problems with the resolver in glibc 2.0.7u

[Soenke Lange]

On Fri, Oct 02, 1998 at 01:20:54AM +0200, Gergely Madarasz wrote:
> Hello!
> 
> It seems there is a problem in the resolver of 2.0.7u: I upgraded my libc
> because apache needed it (__register_frame_info) and after that some mails
> just returned with Host not found, for correct addresses. This happened on
> two different hosts. And, btw, telnet worked in the meanwhile for these
> hosts... so it seems to be a strange interaction between sendmail
> (8.8.8-20) and libc. Any other experiences like this ? I dont want to
> submit a bugreport for now, because i'm not sure about it, but if others
> find this, then it is at least a grave bug...
same with smail :-(

regards
Soenke

------
Soenke Lange
--
Microsoft spel chekar vor sail, worgs grate !!

Re: @debian.org mail

[Daniel Lange]

We (debian/DSA) do not provide email hosting. We provide email
forwarding.


DSA should re-evaluate that.

We run into more and more problems sending from @debian.org email 
addresses as the three big players in email ratchet up their anti-spam 
measures.


They are hosting a huge share of our users' email and the same for 
prospective contributors:



The default reply for missing wafer confirmation emails (the software 
running debconf19.debconf.org) and missing salsa password reset emails 
is "check your Spam folder". Debian.org doesn't have a SPF record so 
mail submitted from such Debian machines is a bit in a limbo.


We have more people registered for DebConf ("the Debian Developers' 
conference") with @gmail.com than @debian.org addresses.


Mail submitted from DD's private IPs frequently gets flagged as spam 
regardless of content by all three big players and - if submitted via 
IPv6 - refused directly by Google. Microsoft and Yahoo still run their 
MXs IPv4 only. But we can expect a similar policy once they add IPv6 
SMTPs at scale. And they won't warn us up-front.
The missing SPF record mentioned above means there is a lot of spam 
circulating with @debian.org fake senders and obviously our open 
submission policy on many mailing-lists and @debian.org technical 
addresses also fan out quite some spam. So we're not the best netizens 
we could be.


To do better, we should really offer SMTP submission/IMAP services for 
@debian.org as soon as possible and - after a grace period - publish a 
mx -all SPF record.


Google has added mailly and muffat to their internal 
has-no-proper-SPF-policy-whitelist (thank you!). This will obviously 
increase the problems for people not sending via Debian machines down 
the road.
Which is why a few people - including me - now route outbound via these 
Debian MX machines. That's a work-around for the technically inclined 
but won't really scale.


People have tried mending the gap by offering accounts on their personal 
infrastructure to fellow developers (and thanks for that Tollef and others).


We like people to use their @debian.org or @debconf.org email address 
when reaching out to sponsors and suppliers as this adds (perceived) 
credibility and (true) visibility. So we should make it easy for people 
to use those email addresses.


Just maintaining the status-quo of email-forwarding only seems past its 
useful life time.


Kind regards,
Daniel

P.S.: I have offered helping to run email services to DSA in the past.
I don't only complain. But DSA has the issue of them having to run 
committed infrastructure in the end. So if - for example - the Salsa 
team were not wanting to run salsa.debian.org anymore, DSA would end up 
having to add this to their work load. This is why DSA need to 
prioritize email regardless of who will set it up and run it initially.

Re: @debian.org mail

[Daniel Lange]

Hi Sam,

Am 03.06.19 um 13:29 schrieb Sam Hartman:

1) You're asking all DDs to use this infrastructure you set up.


Currently everybody routes inbound mail via two Debian servers (as they 
are the only MXs for debian.org).


Everybody who needs to make sure they can reach @gmail.com / GApps users 
/ Microsoft hosted Exchange etc. need to send via these, too, cf. my 
initial email.


People vote with their feet. We're not really overrun by new 
contributors. We shouldn't afford the arrogance of "it is your problem 
if my email doesn't reach your inbox". Esp. if we can do better.


That said, I don't care when DDs use their private domains for Debian 
stuff. I'd be all for continuing them to do so.


For things like fundraising officially looking email addresses are 
important. That's why I care to keep these functional. More DDs funded 
to travel to DebConf is a more happy me. I'm also sure many @debian.org 
-> random upstream messages are never received. Because random upstream 
is a Google / Microsoft / Yahoo user or runs an email server with a 
strict anti-spam policy. We just had that case with the cfp@ email of 
our Hamburg Mini-DebConf rejecting @debian.org email because of "forged 
recipients" and bad IP reputation scores. QQ (Tencent) refused emails 
from Salsa. This is the biggest email hoster in China. I'd like more 
Chinese to be able to participate in Debian. I have many such examples.


Hence I'd like us to offer email services to project members. That's an 
offer. Not a requirement. If DDs use the Debian infra or continue using 
their current setup, all fine for me.
Yes, a proper SPF record may make things more difficult for people that 
run their own. But I - for example - run my own and route via Debian MX 
(just the Debian mail of course). So it can be done. I just wish not 
every DD had to, if they wouldn't want to. And possibly end up using 
GMail and make Jonathan and many Free as in Freedom advocates unhappy.



2) I'm not really sure I want the debian machines to get a copy of all
mail I send from my debian.org address.


In case anybody replies to your email, these machines get the gist of 
your communication anyways. And you send via AWS (Amazon). I personally 
trust DSA more.


To me emails are postcards. Everybody along the transport chain may 
enjoy the pictures. Of course I can sign or encrypt if I want the 
pictures to stay genuine or the back side text private.


There is currently a trend in the FLOSS ecosystem to try migrating off 
irc, email and email lists towards Discourse, Gitlab, Mattermost and 
other web based tools. I'm not a fan of that at all (siloing). But one 
of the reasons is lowering the technical entry barrier to participation. 
We should give at least the project members everything they need as 
readily available as possible. And email is really basic.


Kind regards,
Daniel

Re: @debian.org mail

[Daniel Lange]

Am 03.06.19 um 18:09 schrieb Marco d'Itri:


-all would stop some forged emails, but we do not have forged email
issues.
We do. 4% of this year's spam in my spam traps have originated as fake 
@debian.org. Unfortunately we even nicely relay them as we can't tell 
legitimate and fake Debian email apart ourselves.


My favorite ones are fake me sending real me emails with forged 
Microsoft Outlook Express 6.00.2900.5338 headers. 'Cause that's 
definitely my MUA of choice. I've also been chosen for the Google 
foundation trustee board which - allegedly - gets me a personal grant to 
spend however I wish. I'm still waiting for Google's check to arrive.


Back to topic:

Mailly's sender score has ditched to 65/100 during the last spam wave in 
early May and it took two weeks to recover to sane ratings.


We also fan out spam like 
 
(msgid-search works but it's just a boring example) which - funnily - 
gets us spam points at Google (cause we amplify that to ~ a hundred 
@gmail.com recipients).


As we are white-listed at dnswl.org and a few other places such fan out

1) is very useful for spammers and
2) makes our IP reputation suffer as in the May case cited above

As I said earlier, we're not the best netizens we can be and we should 
not facilitate for others spamming in our name.


I know you don't like SPF mx -all but that is what stops the above and 
makes @debian.org mail delivery reliable again. As we relay mailing 
lists via lists.d.o (bendel) we can easily have that continue rewriting 
senders without issues. It can have a separate SPF.


There are other options, too, incl. the one you listed. I'd go for ARC 
if we want to go beyond SPF. But that would be a 20 year leap in email 
tech. I like iterations, i.e. aim for some less ambitious goals first.
It's DSA's call what they prefer. I don't care which solution is chosen 
as long as we get one.
O.k., I'd prefer us to not sign up for Google hosted email or Exchange 
online. I think that part is even safe to assume rough consensus on.

Re: @debian.org mail

[Daniel Lange]

Am 03.06.19 um 22:32 schrieb Marco d'Itri:


On Jun 03, Daniel Lange  wrote:

> > -all would stop some forged emails, but we do not have forged email
> > issues.
> We do. 4% of this year's spam in my spam traps have originated as fake
> @debian.org. Unfortunately we even nicely relay them as we can't tell
This is not a meaningful figure unless you also figure out how much of
that spam could have been detected.

It is a data point to prove your "we do not have forged email issues" wrong.
How much of that spam we can prevent depends on which improvements we 
implement.


Cord kindly produced a few more data points tonight:

We have 39487 @gmail.com users subscribed to lists.d.o mailing lists.
9658 emails from lists.d.o have been bounced / denied by gmail.com in 
the last week.

Re: @debian.org mail

[Daniel Lange]

Am 04.06.19 um 17:51 schrieb Graham Inggs:

I would certainly make use of SMTP for sending @debian.org email. I 
can't see the advantage of IMAP over forwarding though, would you 
explain how you see it working, or who would use it? 


I wouldn't need IMAP either. But for those who are stuck with gmail, 
hotmail, gmx and the like Debian hosted IMAP servers would mean they 
also get a chance to _receive_ all Debian email. Email from @debian.org 
to these email domains is currently rejected outright (IPv6 & gmail, 
Tencent brands) or often ends up in /Spam (IPv4 & gmail, many other 
"free" email providers). We can assume with an updated SMTP setup that 
situation will improve significantly but probably not to a 100%. We run 
mailing lists without sender address rewrite and ARC isn't there yet. 
But if we run IMAP, too, we can simply ensure delivery today (and in the 
future).


So having a submission host (SMTP) and a matching SPF policy solves the 
sending side of the problem, Debian-hosted secure IMAP the receiving side.


Supporting ARC* will eventually help keep mailing lists and bugs.d.o 
functional (for non-Debian-hosted email aka our users) when "the big 
players" ratchet up their anti-spam measures further. But that's, by my 
very subjective personal estimate, another few years down the line.


I'd probably add Debian hosted webmail, too. It's trivial to add and 
some people seem to need it as they spend their day jobs behind very 
restrictive firewalls.


* see https://en.wikipedia.org/wiki/Authenticated_Received_Chain for an 
explanation. That also explains quite well why plain DKIM / DMARC is 
hard to implement without serious side-effects.

DebConf23 registration and CfP are open

[Daniel Lange]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

For DebConf23, we're pleased to announce opening of registration and call for 
proposal.

Registration and the Call for Proposals for DebConf23 are now open. The 24th 
edition of the Debian annual conference will be held from *September 10th to 
September 17th, 2023, in Infopark, Kochi, India.* The main conference will be 
preceded by DebCamp, which will take place from September 3rd to September 9th, 
2023.

The registration form can be accessed by creating an account on the [DebConf23 
website](https://debconf23.debconf.org/) and clicking on "register" in the 
profile section. The number of attendees is capped at 300 this year. All registrations 
will be reviewed by bursary team, and completing the registration form does not guarantee 
attendance.

As always, basic registration for DebConf is free of charge for attendees. If 
you are attending the conference in a professional capacity or as a 
representative of your company, we kindly ask that you consider registering in 
one of our paid categories to help cover the costs of organizing the conference 
and to support subsidizing other community members.

The last day to register with guaranteed swag is 5th August.

We also encourage eligible individuals to apply for a diversity bursary. 
Travel, food, and accommodation bursaries are available. More details can be 
found on the [bursary info 
page](https://debconf23.debconf.org/about/bursaries/).

The last day to apply for a bursary is 1st July. Applicants should receive 
feedback on their bursary application by 16th July.

The call for proposals for talks, discussions and other activities is also open. To 
submit a proposal you need to create an account on the website, and then use the 
"Submit Talk" button in the profile section. The last day to submit and have 
your proposal be considered for the main conference schedule, with video coverage 
guaranteed, is 13th August.

DebConf23 is also accepting sponsors. Interested companies and organizations 
may contact the DebConf team through spons...@debconf.org or visit the 
[DebConf23 website](https://debconf23.debconf.org/sponsors/become-a-sponsor/).

Cheers!
Sahil
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEENXULj7bvlf8WuOvAZk8SOKqPE4oFAmSHcAwACgkQZk8SOKqP
E4q0VQ/+Py+iTo+PaRdcT9XTSST77HT/pc5HOxoSJIztUyxN0dH87mFtqQS3wdC6
aYHPUIEcWxDdnh7Qy2bMUYgiG1NE4qEouCafpRpD1kSd33L9FRlENyAJVKUedMUP
g83JQIq12f5xa4du7iH0zn7ubDX++7diUooib1lfHSlJdMQfcrgHijy04anIJQqW
x09ExS7bwFKk6CAbCz/7XLTsVFKl7iF7hnRqH5wIb+ri6iPcBLuaDBxX9dDFONHs
7sqnWJYub1+7GDkU91sFeeFflKOGVgfJ4H0nGWQrfdRC9rxWuh3mkjkpnI7sqnTQ
iT04qs/UiRKctr6RBmHaSAmy05LjvlNQ2VXCaibMCywt168Y9vH/YdkhI4pVJYWw
VklgkrUSAUbBQpRZ9XkmRQbIT1gOnhRNrrzefccKlyA0fCsAynY6OW+fmddURrOK
YXwX7NHgmEcLl/5wdnbQyvgaJj7OTrrxtrI8lhxQ71twAOij8ywjvwFSWBh9+iyR
SJj7IGYw8x9Hv2XDYU6M6fMtuNgMGYl+VRs4aXolnrpN6HL7AeOh4v4VvSBLASms
9S6HhfJZXhTsjOPYD3e92LlbSbfvpUGZq1O6ByJHybj1rp4Qt9AV183vXnoQxffd
4LMYuFKKlVW49UaX7zGuFXvqbpxt425H2aFlBFJed6sCuVi/PoY=
=WAWg
-END PGP SIGNATURE-

Re: Making Debian available - patch for webwml

[Thomas Lange]

> On Mon, 18 Jan 2021 12:37:37 +0100, Holger Wansing  
> said:

>> debian-www team: what do you think about adding some more hint/warning
>> banners pointing to firmware-including installation images?
I really like to have a hint, but warning is a too negative word.
Having those non-official images can help our users.

> First patch attached.
I would use admon-important.png or admon-tip.png, but not admon-warning.png.

Please let us treat non-free firmware as something positive, that our
users need for certain hardware and not use FUD when talking about
non-free firmware.

-- 
regards Thomas

Re: Making Debian available

[Thomas Lange]

Another very odd thing I found.

On https://www.debian.org/CD/faq/
there's no hint about images including non-free firmware. No hint
about firmware at all. And then this FAQ


Where is the CD image with non-free?
  .
Sometimes, someone is kind enough to create unofficial non-free CDs. If you 
cannot find any links on this website, you can try asking on the debian-cd 
mailing list.


So we do not tell our users that we (the CD team I guess) already
create these very usefull images including non-free firmware. And then
we tell the users to search the link themselves. Not very friendly.


Please improve the FAQ and add a link to the ISO our end user need to
install their notebook with Debian.

-- 
regards Thomas

Re: RFC: pam: dropping support for NIS/NIS+?

[Thomas Lange]

> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek  
> said:

> If your users are using yppasswd on the NIS master for changing passwords,
> then evidently you are not relying on support for NIS in PAM.  (yppasswd
> doesn't even link against libpam.)
Thanks for clarifying this.

-- 
regards Thomas

Re: DebConf20 registration is now open (with caveats)

[Daniel Lange]

Hi Enrico,

Am 23.05.20 um 18:41 schrieb Enrico Zini:

I'm perplexed by the deadline for the bursaries being earlier than the
date in which there'll be a decision about what the format of the
conference will be like.


That's because we need some time to evaluate bursary requests and if we 
give people approval too late, they will be unable to apply for Visa and 
get reasonable flights. So we'd exempt people that need a Visa for 
Israel inadvertently.


The bursary decisions are scheduled to be announced as soon as possible 
after an eventual "go ahead" decision for the physical conference and 
the availability of an approved conference budget.



The call for registration implies that one would be registering to a
similar format of conference as the previous years.


If you don't want to attend a physical conference, that is the right 
thing to do. We are currently only collecting registrations from people 
that are in the region or want to fly to Israel and estimate themselves 
that they will be likely be allowed to do so in August.



Can you however confirm that if on the 8th of June the format of the
conference will change into something that one would instead feel
motivated to attend, and such format would still requires expenses for
which one could use a bursary, then the bursaries deadline will be
extended?


An online format will be free of charge for people joining.

If a community member needs specific hardware to attend and cannot 
afford it themselves, there is the normal DPL reimbursement process 
available. This would apply to the prior Online Mini-DC (End of May) 
already before DebConf20 (End of August).


Kind regards,
Daniel

Reminder: DebConf20 registration, bursary status, Covid-19 survey results

[Daniel Lange]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

just a quick reminder:

The local team and the DebConf committee (DCC) need to decide next
Monday whether we keep DebConf20 as a physical conference for those
that will likely be able (and willing) to travel in August.

Please help us by registering if you want to attend at:

https://debconf20.debconf.org/register

by end of the week.

The bursary requests are closed for the moment as that deadline has
passed yesterday. So please register now if you do not need travel
sponsorship. Don't bother about food and accommodation at the moment.
For safety reasons alone, that would likely (have to) be provided.

The results of the survey we conducted in parallel are available at:

https://salsa.debian.org/debconf-team/public/data/dc20/-/tree/master/survey

24% of all people that wanted to join DebConf20 before the Corona
epidemic would still do so today and also recommend the in-person
conference. 59% prefer an online-only conference and 18% recommend to
cancel DebConf20.
79% of all respondents would be willing to join an online-only DebConf.
Please check the Salsa link above for more detailed results and analysis.
On a related note: Videos from the Online Mini-DC that took place last
weekend are available at:
https://ftp.acc.umu.se/pub/debian-meetings/2020/MiniDebConfOnline/

If you have any questions, feel free to drop by #debconf-team on IRC
and chat with us.

Kind regards,
Daniel
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEENXULj7bvlf8WuOvAZk8SOKqPE4oFAl7VEfkACgkQZk8SOKqP
E4rjEw/+NmboQ+JxHIKRa7wQhKf8EkR6B+aCjv7rVaj430Yxzo5fcL0Ak1DqeXnk
xnCCv47HSY1PjgQA5cvkg1dUzatl1A4YMxTPmZtYQnnBrBbx6vEqP7UWIzwVpz6U
7Pc2MB8rN3Ljuo7+48x0ASxpyj/1Y5KzZjYOhrCO1GG2WRnFDU7eEtKD5FBaIN/1
owdwDPRQMCCUZ8gJAPVaAn6HSMsqKlJ6cnS4Xo4eogE4HSHIB6EQOrASnQj4HY2j
OOv/uPAwt0NfJy3U87aS3L8qe0crlehycXzVpqH2TZfNcFVgdR6txtMun+IvXvrf
CAkoEWqZdkvLPQlRITqNMKk247r/YW28msWGWg66OILu5vVgQU/Ctps/tw0JnUuh
AsUvbCnryu/P3LrdxrSzrNtZED5LsXBz+bDxQWRV+lSirRB3/iXSyHtb6wRE2neH
D9gJct9lnDXH0V3fOiZxN0PB43b8skHAAvhOg4CXmAAOniEruMw2gqQEC4/aPnBm
BH0N/pFqDpz89x5Ri3YmNjo9vgKhJMPTBpLUb/UyN1CGDMG6jmumz7mb9Hvv6VFl
5Q7uVyhNWOkd2n6v+1Jnb2XstEm6AwnIvBUxshflYmlsOj53GPuCzhyuk5hRFzfh
M2lB5STRW+vK85fQfSMwU88B9QpCZL00oblYRkLu9gaSMY04als=
=fHTP
-END PGP SIGNATURE-

Re: [Debconf-team] OCF.tw for Debian Trusted Organization

[Daniel Lange]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 22.02.2017 um 04:30 schrieb Ying-Chun Liu (PaulLiu):
> I'd like to propose OCF.tw to be a Trusted Organization. And OCF.tw
> also have the interests to be in. But I don't know how to start. 
> We've both read 
> https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria 
> OCF.tw strongly meets the criteria.
Please see the "acceptance" / "criteria" links under
https://wiki.debian.org/Teams/Auditor/Organizations
for examples on how to specify that OCF.tw meets the
requirements to be a potential Debian Trusted Organization (TO).

FTR: OCF.tw is the local legal entity that the DebConf18 team from
Hsinchu, Taiwan proposes to help manage the cash flow and contracts
for the conference.

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYrTHXAAoJEGZPEjiqjxOKMSIP/iQIUg+dDoomDMOCUEcG6plM
evuSuPxae/EdYWRqnjnicYJN4BKbScqB7oiWBpWmtZeXDgK8/s/sAK9XqJ5FIEm9
ynr4K1RJfh0qaIi+Zs2PLIFdcF2S5gZx3qhEoZgTN8yz+vCnuBmui10yB5Skvyw3
+8HecxmF77hrVW349ZoHuIyjXSLpkL4j7/N7RRf1skhY60NpwjhJbmjDZjvgVkaO
zpkqBPBOhrjWh2BYnUmcl1swKANI1+q/DmfVm4jmNm1PGYhy+/71BeMJvnpvcDH+
pjSph4eLMy0zxAi6QOcUSjO0acnrcKtrZkxPUFAueU6kQTE49fTcDWTXMcy6SKYp
QAJi2/a/C3lPGJ71jwVaRSeNJqkdD4bio67ZeHlbIFfKsUaTXPbe4rCdpWPiMiL+
aMD5H35yTuxJiH/nBGRlY4Mp6ReS41aqaVLwgmyhON0yXoRXfmFzHxf2eaF568uj
2nSza+cnoRUsAgpMffZFJrxMEQe55AyKpm/0Ef1nGQNH5qc3qgUyWA1sDGqs6tfx
2YVNeNZLoVr5s5ovifdl50LT1+9h6rVezo74ZXx72DQZ6xYI4ka0TKuKnbmep2AN
nyLU30g5FFzSZDjOKAXPmq9feyYC1RNjlO7mB/jUPkhbRGtS80C6KpQh3STVS+1x
F/ZzIwN6vuK9FBfpuY2F
=hlZI
-END PGP SIGNATURE-