Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022, at 23:50, Gareth Evans wrote: > On Mon 20 Jun 2022, at 23:31, Gareth Evans wrote: >> On Mon 20 Jun 2022, at 17:34, The Wanderer wrote: >>> On 2022-06-20 at 12:01, Brian wrote: >>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: > On 2022-06-20 at 08:59, Brian wrote: >>> >> The ability to print to an IPP printer involves discovering its >> URI. CUPS gets the URI via avahi-daemon whether it is an >> on-demand or manual queue. > > But that discovery doesn't have to be done by CUPS; once the URI is > known, it should be possible for CUPS to simply accept the URI and > work with it from then on, without discovery entering into the > picture. "...once the URIis known"? What mechaism does that? Incidentally, a URI is required to query a printer for its attributes. >>> >>> Any of a number of mechanisms. >>> >>> CUPS could run discovery once, then either A: present the discovered URI >>> with a prompt for whether to add it to its local list of known printers >>> or B: add it to that list automatically, and then in either case not run >>> discovery again until something asks it to. >>> >>> The user could run discovery manually (e.g. from the command line), then >>> enter the discovered URI into CUPS. >>> >>> The user could look at another computer where the URI is already present >>> in CUPS, and copy that across to the computer at hand. >>> >>> I could probably come up with more options if I thought about it for >>> long enough. >>> >> Setting up a manual queue for a moden printer is still available >> but is unnecessary. 'lpstat -e' showves every printer on a subnet >> and they should (barring bugs) appear in an application's print >> dialog without any intervention. > > The thing is, though, sometimes this is *undesirable*. It is possible that upstream CUPS would agree. The intention is to do something about it eventually. >>> >>> Depending on what the "something" is, that could be a very positive >>> development! >>> > Going back to my workplace as an example, we have one subnet per > building per floor, and one printer per classroom; we want the > computers in each room to be able to see and print to the printer > from that classroom, *only*. Having the ones from the other > classrooms show up in the applications' print dialog would be a > problem. DNS-SD doesn't traverse subnets. >>> >>> Yes, but we don't have one subnet per classroom, we have one subnet per >>> floor, with multiple classrooms per floor. >>> >> You can control whether Avahi browses for printers or not but >> cannt make it selective in its browsing. DNS-SD is an >> all-or-nothing public service discovery protocol. Perhaps think >> of the display screens at airports. > > That's just about discovery, though. I'm talking about what's done > with the discovered information. > > It sounds to me as if it's being said that CUPS takes the > discovered information and automatically puts every discovered > printer into the list of printers that will be made available in > the print dialog (or equivalent). > > That should not be the only option. It should also be possible to > run discovery, manually select zero or more printers from the set > discovered, and add *just those printers* to the list of those > that will be shown in the print dialog > > (It should also be possible to add printers to that list manually, > without running discovery, if you know the necessary information.) That's certainly possible at present. >>> >>> I figured, and seemed to recall, but did not want to assume. >>> > The result would be being able to be sure that the list of printers > available in the print dialog will only change if someone manually > modifies it, rather than changing automatically if the set of > printers discoverable on the network changes. Other would see the automatic change as a definite plus. >>> >>> And in some cases so would I! But not in others. And my interpretation >>> of Gene's original complaint, as you quoted it, would suggest that he is >>> in a case where he also would not. >>> >>> That's why whether or not this discovery-and-updating process is >>> performed automatically should be *configurable*. >>> >> I beleive filtering of a printer list using LDAP is something >> being considered for inclusion in a future CUPS. > > Why should LDAP need to be involved? Unless you're using an > external print server to get the printer list from (in which case > things become in some ways simpler and in other ways considerably > more complicated), the list of printers that applications should > see is local, and should be able to be maintained locally without > bringing external things such as LDAP into the picture. My
Re: Status of Virtualbox in debian
On 20/06/2022 14:55, Siard wrote: On Mon, 20 Jun 2022 14:21 +0200, Anders Andersson wrote: Has something changed that makes virtualbox workable again, I have the Virtualbox 6.1.34 package for Debian 11, downloaded from www.virtualbox.org, working fine in Debian 12 (Bookworm). Have you succeeded in gaining support for USB? I haven't yet got past the and guest Additions stage. Peter HB
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022, at 23:31, Gareth Evans wrote: > On Mon 20 Jun 2022, at 17:34, The Wanderer wrote: >> On 2022-06-20 at 12:01, Brian wrote: >> >>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: >>> On 2022-06-20 at 08:59, Brian wrote: >> > The ability to print to an IPP printer involves discovering its > URI. CUPS gets the URI via avahi-daemon whether it is an > on-demand or manual queue. But that discovery doesn't have to be done by CUPS; once the URI is known, it should be possible for CUPS to simply accept the URI and work with it from then on, without discovery entering into the picture. >>> >>> "...once the URIis known"? What mechaism does that? Incidentally, a >>> URI is required to query a printer for its attributes. >> >> Any of a number of mechanisms. >> >> CUPS could run discovery once, then either A: present the discovered URI >> with a prompt for whether to add it to its local list of known printers >> or B: add it to that list automatically, and then in either case not run >> discovery again until something asks it to. >> >> The user could run discovery manually (e.g. from the command line), then >> enter the discovered URI into CUPS. >> >> The user could look at another computer where the URI is already present >> in CUPS, and copy that across to the computer at hand. >> >> I could probably come up with more options if I thought about it for >> long enough. >> > Setting up a manual queue for a moden printer is still available > but is unnecessary. 'lpstat -e' showves every printer on a subnet > and they should (barring bugs) appear in an application's print > dialog without any intervention. The thing is, though, sometimes this is *undesirable*. >>> >>> It is possible that upstream CUPS would agree. The intention is to >>> do something about it eventually. >> >> Depending on what the "something" is, that could be a very positive >> development! >> Going back to my workplace as an example, we have one subnet per building per floor, and one printer per classroom; we want the computers in each room to be able to see and print to the printer from that classroom, *only*. Having the ones from the other classrooms show up in the applications' print dialog would be a problem. >>> >>> DNS-SD doesn't traverse subnets. >> >> Yes, but we don't have one subnet per classroom, we have one subnet per >> floor, with multiple classrooms per floor. >> > You can control whether Avahi browses for printers or not but > cannt make it selective in its browsing. DNS-SD is an > all-or-nothing public service discovery protocol. Perhaps think > of the display screens at airports. That's just about discovery, though. I'm talking about what's done with the discovered information. It sounds to me as if it's being said that CUPS takes the discovered information and automatically puts every discovered printer into the list of printers that will be made available in the print dialog (or equivalent). That should not be the only option. It should also be possible to run discovery, manually select zero or more printers from the set discovered, and add *just those printers* to the list of those that will be shown in the print dialog (It should also be possible to add printers to that list manually, without running discovery, if you know the necessary information.) >>> >>> That's certainly possible at present. >> >> I figured, and seemed to recall, but did not want to assume. >> The result would be being able to be sure that the list of printers available in the print dialog will only change if someone manually modifies it, rather than changing automatically if the set of printers discoverable on the network changes. >>> >>> Other would see the automatic change as a definite plus. >> >> And in some cases so would I! But not in others. And my interpretation >> of Gene's original complaint, as you quoted it, would suggest that he is >> in a case where he also would not. >> >> That's why whether or not this discovery-and-updating process is >> performed automatically should be *configurable*. >> > I beleive filtering of a printer list using LDAP is something > being considered for inclusion in a future CUPS. Why should LDAP need to be involved? Unless you're using an external print server to get the printer list from (in which case things become in some ways simpler and in other ways considerably more complicated), the list of printers that applications should see is local, and should be able to be maintained locally without bringing external things such as LDAP into the picture. >>> >>> My understanding of LDAP is very limited. All I know is that CUPS >>> will eshew simple filtering. It has been tried, and didn't work. >> >> I don't even know why
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022, at 17:34, The Wanderer wrote: > On 2022-06-20 at 12:01, Brian wrote: > >> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: >> >>> On 2022-06-20 at 08:59, Brian wrote: > The ability to print to an IPP printer involves discovering its URI. CUPS gets the URI via avahi-daemon whether it is an on-demand or manual queue. >>> >>> But that discovery doesn't have to be done by CUPS; once the URI is >>> known, it should be possible for CUPS to simply accept the URI and >>> work with it from then on, without discovery entering into the >>> picture. >> >> "...once the URIis known"? What mechaism does that? Incidentally, a >> URI is required to query a printer for its attributes. > > Any of a number of mechanisms. > > CUPS could run discovery once, then either A: present the discovered URI > with a prompt for whether to add it to its local list of known printers > or B: add it to that list automatically, and then in either case not run > discovery again until something asks it to. > > The user could run discovery manually (e.g. from the command line), then > enter the discovered URI into CUPS. > > The user could look at another computer where the URI is already present > in CUPS, and copy that across to the computer at hand. > > I could probably come up with more options if I thought about it for > long enough. > Setting up a manual queue for a moden printer is still available but is unnecessary. 'lpstat -e' showves every printer on a subnet and they should (barring bugs) appear in an application's print dialog without any intervention. >>> >>> The thing is, though, sometimes this is *undesirable*. >> >> It is possible that upstream CUPS would agree. The intention is to >> do something about it eventually. > > Depending on what the "something" is, that could be a very positive > development! > >>> Going back to my workplace as an example, we have one subnet per >>> building per floor, and one printer per classroom; we want the >>> computers in each room to be able to see and print to the printer >>> from that classroom, *only*. Having the ones from the other >>> classrooms show up in the applications' print dialog would be a >>> problem. >> >> DNS-SD doesn't traverse subnets. > > Yes, but we don't have one subnet per classroom, we have one subnet per > floor, with multiple classrooms per floor. > You can control whether Avahi browses for printers or not but cannt make it selective in its browsing. DNS-SD is an all-or-nothing public service discovery protocol. Perhaps think of the display screens at airports. >>> >>> That's just about discovery, though. I'm talking about what's done >>> with the discovered information. >>> >>> It sounds to me as if it's being said that CUPS takes the >>> discovered information and automatically puts every discovered >>> printer into the list of printers that will be made available in >>> the print dialog (or equivalent). >>> >>> That should not be the only option. It should also be possible to >>> run discovery, manually select zero or more printers from the set >>> discovered, and add *just those printers* to the list of those >>> that will be shown in the print dialog >>> >>> (It should also be possible to add printers to that list manually, >>> without running discovery, if you know the necessary information.) >> >> That's certainly possible at present. > > I figured, and seemed to recall, but did not want to assume. > >>> The result would be being able to be sure that the list of printers >>> available in the print dialog will only change if someone manually >>> modifies it, rather than changing automatically if the set of >>> printers discoverable on the network changes. >> >> Other would see the automatic change as a definite plus. > > And in some cases so would I! But not in others. And my interpretation > of Gene's original complaint, as you quoted it, would suggest that he is > in a case where he also would not. > > That's why whether or not this discovery-and-updating process is > performed automatically should be *configurable*. > I beleive filtering of a printer list using LDAP is something being considered for inclusion in a future CUPS. >>> >>> Why should LDAP need to be involved? Unless you're using an >>> external print server to get the printer list from (in which case >>> things become in some ways simpler and in other ways considerably >>> more complicated), the list of printers that applications should >>> see is local, and should be able to be maintained locally without >>> bringing external things such as LDAP into the picture. >> >> My understanding of LDAP is very limited. All I know is that CUPS >> will eshew simple filtering. It has been tried, and didn't work. > > I don't even know why filtering would be involved. You're not starting > with a longer list and filtering it to show only a subset; you're > starting with an empty list, populating it
acceso full a una ip
buenas a todos Necesito que me aclaren esto soy nuevo e esto de iptables. Necesito a una ip de mi lan por ej la 192.168.200.3 darle acceso ainternet full y que no tenga nada que ver con el proxy, es para que baje actualizaciones y todo para servidores etc. puede ser así Ahh la ip real par el proxy por ej 200.55.55.3 iptables -A INPUT -s 192.168.200.3 -j ACCEPT ?? Acepto toda ayuda
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022 at 19:49:18 +0100, Brian wrote: Please forget about this mai. I pressed the wrong key. Never done that before! > On Mon 20 Jun 2022 at 12:34:19 -0400, The Wanderer wrote: > > > On 2022-06-20 at 12:01, Brian wrote: > > > > > "...once the URIis known"? What mechaism does that? Incidentally, a > > > URI is required to query a printer for its attributes. > > > > Any of a number of mechanisms. > > > > CUPS could run discovery once, then either A: present the discovered URI > > with a prompt for whether to add it to its local list of known printers > > or B: add it to that list automatically, and then in either case not run > > discovery again until something asks it to. > > > > The user could run discovery manually (e.g. from the command line), then > > enter the discovered URI into CUPS. > > > > The user could look at another computer where the URI is already present > > in CUPS, and copy that across to the computer at hand. > > > > I could probably come up with more options if I thought about it for > > long enough. > > > > > DNS-SD doesn't traverse subnets. > > > > Yes, but we don't have one subnet per classroom, we have one subnet per > > floor, with multiple classrooms per floor. > > > > > Other would see the automatic change as a definite plus. > > > > And in some cases so would I! But not in others. And my interpretation > > of Gene's original complaint, as you quoted it, would suggest that he is > > in a case where he also would not. > > > > That's why whether or not this discovery-and-updating process is > > performed automatically should be *configurable*. > > > > > My understanding of LDAP is very limited. All I know is that CUPS > > > will eshew simple filtering. It has been tried, and didn't work. > > > > I don't even know why filtering would be involved. You're not starting > > with a longer list and filtering it to show only a subset; you're > > starting with an empty list, populating it (either manually, or > > automatically but only on demand) from a longer one, storing the > > resulting list, and later showing it on demand. > > > > Or, at least, that's the way it *should* work. > > > > If there's a reason why filtering needs to be involved, given that "two > > separate lists" model, I'd be interested in seeing that reason > > clarified. > > > > (I can see why it would be useful in a model which says that the list > > which is available to applications is always updated automatically from > > the list generated by discovery; in that context you'd need some way to > > tell the system which things from the discovered list should be included > > or excluded from the made-available list. But since that shouldn't be > > the only behavior, filtering shouldn't be the starting point for > > thinking about this.) >
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022 at 12:34:19 -0400, The Wanderer wrote: > On 2022-06-20 at 12:01, Brian wrote: > > > "...once the URIis known"? What mechaism does that? Incidentally, a > > URI is required to query a printer for its attributes. > > Any of a number of mechanisms. > > CUPS could run discovery once, then either A: present the discovered URI > with a prompt for whether to add it to its local list of known printers > or B: add it to that list automatically, and then in either case not run > discovery again until something asks it to. > > The user could run discovery manually (e.g. from the command line), then > enter the discovered URI into CUPS. > > The user could look at another computer where the URI is already present > in CUPS, and copy that across to the computer at hand. > > I could probably come up with more options if I thought about it for > long enough. > > > DNS-SD doesn't traverse subnets. > > Yes, but we don't have one subnet per classroom, we have one subnet per > floor, with multiple classrooms per floor. > > > Other would see the automatic change as a definite plus. > > And in some cases so would I! But not in others. And my interpretation > of Gene's original complaint, as you quoted it, would suggest that he is > in a case where he also would not. > > That's why whether or not this discovery-and-updating process is > performed automatically should be *configurable*. > > > My understanding of LDAP is very limited. All I know is that CUPS > > will eshew simple filtering. It has been tried, and didn't work. > > I don't even know why filtering would be involved. You're not starting > with a longer list and filtering it to show only a subset; you're > starting with an empty list, populating it (either manually, or > automatically but only on demand) from a longer one, storing the > resulting list, and later showing it on demand. > > Or, at least, that's the way it *should* work. > > If there's a reason why filtering needs to be involved, given that "two > separate lists" model, I'd be interested in seeing that reason > clarified. > > (I can see why it would be useful in a model which says that the list > which is available to applications is always updated automatically from > the list generated by discovery; in that context you'd need some way to > tell the system which things from the discovered list should be included > or excluded from the made-available list. But since that shouldn't be > the only behavior, filtering shouldn't be the starting point for > thinking about this.)
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On 2022-06-20 at 12:01, Brian wrote: > On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: > >> On 2022-06-20 at 08:59, Brian wrote: >>> The ability to print to an IPP printer involves discovering its >>> URI. CUPS gets the URI via avahi-daemon whether it is an >>> on-demand or manual queue. >> >> But that discovery doesn't have to be done by CUPS; once the URI is >> known, it should be possible for CUPS to simply accept the URI and >> work with it from then on, without discovery entering into the >> picture. > > "...once the URIis known"? What mechaism does that? Incidentally, a > URI is required to query a printer for its attributes. Any of a number of mechanisms. CUPS could run discovery once, then either A: present the discovered URI with a prompt for whether to add it to its local list of known printers or B: add it to that list automatically, and then in either case not run discovery again until something asks it to. The user could run discovery manually (e.g. from the command line), then enter the discovered URI into CUPS. The user could look at another computer where the URI is already present in CUPS, and copy that across to the computer at hand. I could probably come up with more options if I thought about it for long enough. >>> Setting up a manual queue for a moden printer is still available >>> but is unnecessary. 'lpstat -e' showves every printer on a subnet >>> and they should (barring bugs) appear in an application's print >>> dialog without any intervention. >> >> The thing is, though, sometimes this is *undesirable*. > > It is possible that upstream CUPS would agree. The intention is to > do something about it eventually. Depending on what the "something" is, that could be a very positive development! >> Going back to my workplace as an example, we have one subnet per >> building per floor, and one printer per classroom; we want the >> computers in each room to be able to see and print to the printer >> from that classroom, *only*. Having the ones from the other >> classrooms show up in the applications' print dialog would be a >> problem. > > DNS-SD doesn't traverse subnets. Yes, but we don't have one subnet per classroom, we have one subnet per floor, with multiple classrooms per floor. >>> You can control whether Avahi browses for printers or not but >>> cannt make it selective in its browsing. DNS-SD is an >>> all-or-nothing public service discovery protocol. Perhaps think >>> of the display screens at airports. >> >> That's just about discovery, though. I'm talking about what's done >> with the discovered information. >> >> It sounds to me as if it's being said that CUPS takes the >> discovered information and automatically puts every discovered >> printer into the list of printers that will be made available in >> the print dialog (or equivalent). >> >> That should not be the only option. It should also be possible to >> run discovery, manually select zero or more printers from the set >> discovered, and add *just those printers* to the list of those >> that will be shown in the print dialog >> >> (It should also be possible to add printers to that list manually, >> without running discovery, if you know the necessary information.) > > That's certainly possible at present. I figured, and seemed to recall, but did not want to assume. >> The result would be being able to be sure that the list of printers >> available in the print dialog will only change if someone manually >> modifies it, rather than changing automatically if the set of >> printers discoverable on the network changes. > > Other would see the automatic change as a definite plus. And in some cases so would I! But not in others. And my interpretation of Gene's original complaint, as you quoted it, would suggest that he is in a case where he also would not. That's why whether or not this discovery-and-updating process is performed automatically should be *configurable*. >>> I beleive filtering of a printer list using LDAP is something >>> being considered for inclusion in a future CUPS. >> >> Why should LDAP need to be involved? Unless you're using an >> external print server to get the printer list from (in which case >> things become in some ways simpler and in other ways considerably >> more complicated), the list of printers that applications should >> see is local, and should be able to be maintained locally without >> bringing external things such as LDAP into the picture. > > My understanding of LDAP is very limited. All I know is that CUPS > will eshew simple filtering. It has been tried, and didn't work. I don't even know why filtering would be involved. You're not starting with a longer list and filtering it to show only a subset; you're starting with an empty list, populating it (either manually, or automatically but only on demand) from a longer one, storing the resulting list, and later showing it on demand. Or, at least, that's the way it *should* work. If there's a
Re: Postfix comme MX2 d'un Sendmail
On Mon, Jun 20, 2022 at 05:25:39PM +0200, BERTRAND Joël wrote: > Je viens de couper le MX1 durant une petite demi-heure. Le MX2 récupère > tous les mails en synchronisant les listes grises entre MX1 et 2 et > renvoie le tout au MX1 dès qu'il réapparaît. > > Je finasserai la configuration plus tard. > > Une question résiduelle que je viens de me poser. Lorsqu'un utilisateur > envoie un mail, il utilise le SMTP (sur le MX1) sur le port 587. > sendmail demande une authentification. Si pas d'authentification, le > mail est refusé. Mais sur le port 25, quel est le mécanisme qui fait > qu'un utilisateur ne peut pas envoyer directement un mail (que ce soit > avec Postfix ou sendmail) ? > Peut-être ajouter "reject_unauth_destination" au paramètre smtpd_recipient_restrictions ? https://wiki.auf.org/wikiteki/Postfix/Authentification Salut, -Roberto -- Roberto C. Sánchez
Re: issue with purging an old kernel
Since i am running dozens of VM's, i can say: Me2 am running into this regularly, when i am trying to purge old kernels. I am seeing this so frequently, that i even wrote a script (meant to be run inside the VM's) to clean up the mess, some apt-scripts happen to leave behind. But in this special case of yours, there is no harm done by just removing this empty dir (which is left behind quite a lot in my machines too). But ... as this is not the only place, where debian does not comply with my sense of an orderly regime in the filesystem, i prefer to resort to living with the feeling of "a somewhat dirty" system. Just as my body gets polluted over a lifetime, so does any operating system and the effort, to clean it up only to save a few bytes, gets increasingly ridiculous, as those bytes wont crash the system. Hopefully, the microplastic and active chemicals, that pollute our bodies, wont crash it either, but i am not so certain about the latter. DdB Am 20.06.2022 um 16:58 schrieb D. R. Evans: > So it seems reasonable to remove /lib/modules/5.10.0-11-amd64/misc/ > manually and re-execute the purge command. > > But before I try that, I'm puzzled as to how this situation could have > arisen. Has anyone else seen this happen, and does anyone have a > reasonable suggestion as to how it could have occurred? > > Doc -- Liebe ist ... Datakanja
Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote: > On 2022-06-20 at 08:59, Brian wrote: > > > On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote: > > > >> On 2022-06-19 at 15:47, Brian wrote: > > >>> You (or the OP) would have to say what is meant by "delete". > >>> CUPS essentially *discover* printers. It is why it exists. Is > >>> that not wanted? > >> > >> I understand the reason for CUPS' existence to be, not > >> *discovering printers*, but *facilitating the ability to print*. > >> That could involve discovering printers and presenting them as > >> available, or it could involve only presenting as available a list > >> of printers that have been entered into CUPS or otherwise set up in > >> CUPS by some more manual means. (Among perhaps other > >> possibilities.) > > > > The ability to print to an IPP printer involves discovering its URI. > > CUPS gets the URI via avahi-daemon whether it is an on-demand or > > manual queue. > > But that discovery doesn't have to be done by CUPS; once the URI is > known, it should be possible for CUPS to simply accept the URI and work > with it from then on, without discovery entering into the picture. "...once the URIis known"? What mechaism does that? Incidentally, a URI is required to query a printer for its attributes. > >> Certainly at my workplace I understand that our Macs use CUPS for > >> (network) printing, but at least at one point in our history > >> (within the past decade), we had to go in and define each printer > >> by IP address in CUPS on each Mac (or on the central machine which > >> would be replicated to the others). > > > > Setting up a manual queue for a moden printer is still available > > but is unnecessary. 'lpstat -e' showves every printer on a subnet and > > they should (barring bugs) appear in an application's print dialog > > without any intervention. > > The thing is, though, sometimes this is *undesirable*. It is possible that upstream CUPS would agree. The intention is to do something about it eventually. > Going back to my workplace as an example, we have one subnet per > building per floor, and one printer per classroom; we want the computers > in each room to be able to see and print to the printer from that > classroom, *only*. Having the ones from the other classrooms show up in > the applications' print dialog would be a problem. DNS-SD doesn't traverse subnets. > The set of printers which are discoverable on the network, and the set > of printers which are available to applications as print destinations, > should not have to be the same thing; the former should be generated on Not a bad iea. Others have also asked for it. Upstream have responed positively. > demand whenever discovery is performed, and the latter should be > maintained locally. It should be possible to populate the latter list > from the former, selectively, but this should not *have* to happen - > much less always happen automatically in all cases. > > >> I can certainly see it as being reasonable to want to be able to > >> have CUPS perform printer discovery *on request*, and manually > >> choose which of the discovered printers to add to the list of ones > >> that will be remembered and shown as available when printing, but > >> not have CUPS run discovery *automatically* and *automatically* add > >> every discovered printer to that list. (I don't know with any > >> confidence whether CUPS does the latter; I don't run it in enough > >> environments with enough different available printers to have been > >> able to make an assessment. However, I do have the impression that > >> it may.) > > > > You can control whether Avahi browses for printers or not but cannt > > make it selective in its browsing. DNS-SD is an all-or-nothing > > public service discovery protocol. Perhaps think of the display > > screens at airports. > > That's just about discovery, though. I'm talking about what's done with > the discovered information. > > It sounds to me as if it's being said that CUPS takes the discovered > information and automatically puts every discovered printer into the > list of printers that will be made available in the print dialog (or > equivalent). > > That should not be the only option. It should also be possible to run > discovery, manually select zero or more printers from the set > discovered, and add *just those printers* to the list of those that will > be shown in the print dialog > > (It should also be possible to add printers to that list manually, > without running discovery, if you know the necessary information.) That's certainly possible at present. > The result would be being able to be sure that the list of printers > available in the print dialog will only change if someone manually > modifies it, rather than changing automatically if the set of printers > discoverable on the network changes. Other would see the automatic change as a definite plus. > As far as I can tell, that's entirely a matter
Re: issue with purging an old kernel
On Mon, 20 Jun 2022 08:58:55 -0600 "D. R. Evans" wrote: Hello D., >But it failed, with the error message: Actually; .exited, with the warning. That is to say, it's doing what it's supposed to do. -- Regards _ / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" Buy some love at the five and dime You Have Placed A Chill In My Heart - Eurythmics pgpAG1L91Ru3g.pgp Description: OpenPGP digital signature
Re: issue with purging an old kernel
On Mon, 20 Jun 2022 08:58:55 -0600 "D. R. Evans" wrote: > So it seems reasonable to remove /lib/modules/5.10.0-11-amd64/misc/ > manually and re-execute the purge command. Yes, go ahead and do so. > > But before I try that, I'm puzzled as to how this situation could > have arisen. Has anyone else seen this happen, and does anyone have a > reasonable suggestion as to how it could have occurred? I've seen similar before. The only two reasons for this I can think of are: 1) Something other than the kernel package put something into that directory tree. 2) The kernel package put something in there but didn't remove it first. But I'm no expert on Debian packaging. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Postfix comme MX2 d'un Sendmail
Je viens de couper le MX1 durant une petite demi-heure. Le MX2 récupère tous les mails en synchronisant les listes grises entre MX1 et 2 et renvoie le tout au MX1 dès qu'il réapparaît. Je finasserai la configuration plus tard. Une question résiduelle que je viens de me poser. Lorsqu'un utilisateur envoie un mail, il utilise le SMTP (sur le MX1) sur le port 587. sendmail demande une authentification. Si pas d'authentification, le mail est refusé. Mais sur le port 25, quel est le mécanisme qui fait qu'un utilisateur ne peut pas envoyer directement un mail (que ce soit avec Postfix ou sendmail) ? Bien cordialement, JKB
issue with purging an old kernel
Normally to remove an old kernel from my debian stable systems, I issue the following command: apt purge linux-headers--amd64 linux-headers--common linux-image--amd64 Following this recipe, which has always worked in the past, I issued: apt purge linux-headers-5.10.0-11-amd64 linux-headers-5.10.0-11-common linux-image-5.10.0-11-amd64 But it failed, with the error message: Purging configuration files for linux-image-5.10.0-11-amd64 (5.10.92-2) ... rmdir: failed to remove '/lib/modules/5.10.0-11-amd64': Directory not empty dpkg: warning: while removing linux-image-5.10.0-11-amd64, directory '/lib/modules/5.10.0-11-amd64' not empty so not removed If I look in the named directory, I see: root@zbrew:~# ls -al /lib/modules/5.10.0-11-amd64 total 35 drwxr-xr-x 3 root root 3 Jun 20 08:49 . drwxr-xr-x 7 root root 7 Jun 17 07:08 .. drwxr-xr-x 2 root root 2 Apr 25 07:53 misc and the directory /lib/modules/5.10.0-11-amd64/misc turns out to be empty. So it seems reasonable to remove /lib/modules/5.10.0-11-amd64/misc/ manually and re-execute the purge command. But before I try that, I'm puzzled as to how this situation could have arisen. Has anyone else seen this happen, and does anyone have a reasonable suggestion as to how it could have occurred? Doc -- Web: http://enginehousebooks.com/drevans
Re: Status of Virtualbox in debian
On Mon, 20 Jun 2022 14:21 +0200, Anders Andersson wrote: > Has something changed that makes virtualbox workable again, I have the Virtualbox 6.1.34 package for Debian 11, downloaded from www.virtualbox.org, working fine in Debian 12 (Bookworm).
Re: Postfix comme MX2 d'un Sendmail
Roberto C. Sánchez a écrit : > Bonjour Joël, Bonjour Roberto. > On Mon, Jun 20, 2022 at 02:14:11PM +0200, BERTRAND Joël wrote: >> >> Pour l'instant, j'ai écrit dans /etc/mail/main.cf la chose suivante : >> >> command_directory = /usr/sbin >> daemon_directory = /usr/libexec/postfix >> data_directory = /var/db/postfix >> debug_peer_level = 2 >> debugger_command = >> disable_vrfy_command = yes >> html_directory = /usr/share/doc/html/postfix >> inet_interfaces = all >> inet_protocols = all >> mail_owner = postfix >> mailq_path = /usr/bin/mailq >> manpage_directory = /usr/share/man >> maximal_queue_lifetime = 10d >> milter_default_action = accept >> mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.1/8 >> newaliases_path = /usr/bin/newaliases >> non_smtpd_milters = unix:/var/clamav/clamav-milter.sock >> postscreen_access_list = permit_mynetworks >> proxy_interfaces = 192.168.15.14 >> queue_directory = /var/spool/postfix >> readme_directory = /usr/share/examples/postfix >> relay_domains = $mydestination, systella.fr >> relay_recipient_maps = >> sample_directory = /usr/share/examples/postfix >> sendmail_path = /usr/sbin/sendmail >> setgid_group = maildrop >> smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock >> smtpd_recipient_restrictions = permit_sasl_authenticated, >> permit_mynetworks, check_relay_domains, reject_unauth_destination >> unknown_local_recipient_reject_code = 550 >> > J'utilise Postfix comme primaire et comme secondaire, alors je ne sais > rien concernant Sendmail. Mais, ma configuration Postfix comprend les > adresses IP des autres serveurs Postfix dans le paramètre mynetworks et > le secondaire aussi le paramètre relayhost de cette manière: > > relayhost = [mx1.example.com] > > Je pense que parce que relayhost manque de ta configuration, ton Postfix > ne sait pas qu'il doive envoyer le message au MX1 sans essayer résoudre > l'adresse se c'est du domaine @systella.fr en ce cas. Il y a effectivement du mieux : Root rayleigh:[/etc/mail] > telnet 62.212.98.88 25 Trying 62.212.98.88... Connected to 62.212.98.88. Escape character is '^]'. 220 legendre.systella.fr ESMTP Postfix EHLO rayleigh 250-legendre.systella.fr 250-PIPELINING 250-SIZE 1024 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: 250 2.1.0 Ok RCPT TO: 554 5.5.4 SPF test failed Je ne me prends plus le même coup de pied aux fesses ;-) Dans les logs de postfix, je trouve : Jun 20 15:32:21 legendre postfix/smtpd[16414]: warning: support for restriction "check_relay_domains" will be removed from Postfix; use "reject_unauth_destination" instead Jun 20 15:32:21 legendre postfix/smtpd[16414]: warning: restriction `reject_unauth_destination' after `check_relay_domains' is ignored Jun 20 15:32:21 legendre milter-greylist: (unknown id): addr 213.41.150.218 flushed, removed 0 grey and autowhite (ACL 90) Jun 20 15:32:21 legendre milter-greylist: (unknown id): addr [213.41.150.218][213.41.150.218] from to blacklisted (ACL 90) Jun 20 15:32:21 legendre postfix/smtpd[16414]: NOQUEUE: milter-reject: RCPT from unknown[213.41.150.218]: 554 5.5.4 SPF test failed; from= to= proto=ESMTP helo= J'ai donc changé la configuration pour la suivante (avec le même résultat final, à savoir un échec du test SPF) : command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = disable_vrfy_command = yes html_directory = /usr/share/doc/html/postfix inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_queue_lifetime = 10d milter_default_action = accept mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.0/8 newaliases_path = /usr/bin/newaliases non_smtpd_milters = unix:/var/clamav/clamav-milter.sock postscreen_access_list = permit_mynetworks proxy_interfaces = 192.168.15.14 queue_directory = /var/spool/postfix readme_directory = /usr/share/examples/postfix relay_domains = $mydestination, systella.fr relay_recipient_maps = relayhost = [rayleigh.systella.fr] sample_directory = /usr/share/examples/postfix sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination unknown_local_recipient_reject_code = 550 (j'ai trié le fichier de conf en retirant les commentaires, ça n'apparaît peut-être pas dans un ordre logique). Et là, j'ai un gros doute concernant le DNS. Le champ SPFv1 est le suivant (récupéré depuis le serveur faisant tourner PostFix) : legendre# host -t TXT systella.fr systella.fr descriptive text "v=spf1 a:rayleigh.systella.fr a:newton.systella.fr a:newton-ipv6.systella.fr ip6:2001:7a8:a8ed:253::1/64 -all" legendre# host 213.41.150.218 218.150.41.213.in-addr.ARPA domain name pointer
CUPS and available-printers-list management (was Re: non installed printer can not be removed)
On 2022-06-20 at 08:59, Brian wrote: > On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote: > >> On 2022-06-19 at 15:47, Brian wrote: >>> You (or the OP) would have to say what is meant by "delete". >>> CUPS essentially *discover* printers. It is why it exists. Is >>> that not wanted? >> >> I understand the reason for CUPS' existence to be, not >> *discovering printers*, but *facilitating the ability to print*. >> That could involve discovering printers and presenting them as >> available, or it could involve only presenting as available a list >> of printers that have been entered into CUPS or otherwise set up in >> CUPS by some more manual means. (Among perhaps other >> possibilities.) > > The ability to print to an IPP printer involves discovering its URI. > CUPS gets the URI via avahi-daemon whether it is an on-demand or > manual queue. But that discovery doesn't have to be done by CUPS; once the URI is known, it should be possible for CUPS to simply accept the URI and work with it from then on, without discovery entering into the picture. >> Certainly at my workplace I understand that our Macs use CUPS for >> (network) printing, but at least at one point in our history >> (within the past decade), we had to go in and define each printer >> by IP address in CUPS on each Mac (or on the central machine which >> would be replicated to the others). > > Setting up a manual queue for a moden printer is still available > but is unnecessary. 'lpstat -e' showves every printer on a subnet and > they should (barring bugs) appear in an application's print dialog > without any intervention. The thing is, though, sometimes this is *undesirable*. Going back to my workplace as an example, we have one subnet per building per floor, and one printer per classroom; we want the computers in each room to be able to see and print to the printer from that classroom, *only*. Having the ones from the other classrooms show up in the applications' print dialog would be a problem. The set of printers which are discoverable on the network, and the set of printers which are available to applications as print destinations, should not have to be the same thing; the former should be generated on demand whenever discovery is performed, and the latter should be maintained locally. It should be possible to populate the latter list from the former, selectively, but this should not *have* to happen - much less always happen automatically in all cases. >> I can certainly see it as being reasonable to want to be able to >> have CUPS perform printer discovery *on request*, and manually >> choose which of the discovered printers to add to the list of ones >> that will be remembered and shown as available when printing, but >> not have CUPS run discovery *automatically* and *automatically* add >> every discovered printer to that list. (I don't know with any >> confidence whether CUPS does the latter; I don't run it in enough >> environments with enough different available printers to have been >> able to make an assessment. However, I do have the impression that >> it may.) > > You can control whether Avahi browses for printers or not but cannt > make it selective in its browsing. DNS-SD is an all-or-nothing > public service discovery protocol. Perhaps think of the display > screens at airports. That's just about discovery, though. I'm talking about what's done with the discovered information. It sounds to me as if it's being said that CUPS takes the discovered information and automatically puts every discovered printer into the list of printers that will be made available in the print dialog (or equivalent). That should not be the only option. It should also be possible to run discovery, manually select zero or more printers from the set discovered, and add *just those printers* to the list of those that will be shown in the print dialog (It should also be possible to add printers to that list manually, without running discovery, if you know the necessary information.) The result would be being able to be sure that the list of printers available in the print dialog will only change if someone manually modifies it, rather than changing automatically if the set of printers discoverable on the network changes. As far as I can tell, that's entirely a matter for CUPS, since CUPS is the software which would be maintaining such a list and providing such a list to the applications which need to print. If that behavior is possible, it must be CUPS that is providing it. If it is not possible, then by the nature of CUPS' purpose and role (that of middleman between applications and printers), it must be CUPS that is at fault for not providing it. > I beleive filtering of a printer list using LDAP is something being > considered for inclusion in a future CUPS. Why should LDAP need to be involved? Unless you're using an external print server to get the printer list from (in which case things become in some ways simpler and
Re: non installed printer can not be removed
On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote: > On 2022-06-19 at 15:47, Brian wrote: > > > On Sun 19 Jun 2022 at 14:54:58 -0400, The Wanderer wrote: > > > >> On 2022-06-19 at 14:50, Brian wrote: > > >>> What does being "precious" involve? > >> > >> I'm less certain about this, but my guess is that it means that > >> CUPS insists on having these detected printers listed as available, > >> rather than permitting them to be deleted from the list of > >> available printers and having them remain that way. > > > > You (or the OP) would have to say what is meant by "delete". CUPS > > essentially *discover* printers. It is why it exists. Is that not > > wanted? > > I understand the reason for CUPS' existence to be, not *discovering > printers*, but *facilitating the ability to print*. That could involve > discovering printers and presenting them as available, or it could > involve only presenting as available a list of printers that have been > entered into CUPS or otherwise set up in CUPS by some more manual means. > (Among perhaps other possibilities.) The ability to print to an IPP printer involves discovering its URI. CUPS gets the URI via avahi-daemon whether it is an on-demand or manual queue. > Certainly at my workplace I understand that our Macs use CUPS for > (network) printing, but at least at one point in our history (within the > past decade), we had to go in and define each printer by IP address in > CUPS on each Mac (or on the central machine which would be replicated to > the others). Setting up a manual queue for a moden printer is still available but is unnecessary. 'lpstat -e' showves every printer on a subnet and they should (barring bugs) appear in an application's print dialog without any intervention. > I can certainly see it as being reasonable to want to be able to have > CUPS perform printer discovery *on request*, and manually choose which > of the discovered printers to add to the list of ones that will be > remembered and shown as available when printing, but not have CUPS run > discovery *automatically* and *automatically* add every discovered > printer to that list. (I don't know with any confidence whether CUPS > does the latter; I don't run it in enough environments with enough > different available printers to have been able to make an assessment. > However, I do have the impression that it may.) You can control whether Avahi browses for printers or not but cannt make it selective in its browsing. DNS-SD is an all-or-nothing public service discovery protocol. Perhaps think of the display screens at airports. I beleive filtering of a printer list using LDAP is something being considered for inclusion in a future CUPS. -- Brian.
Re: Postfix comme MX2 d'un Sendmail
Bonjour Joël, On Mon, Jun 20, 2022 at 02:14:11PM +0200, BERTRAND Joël wrote: > > Pour l'instant, j'ai écrit dans /etc/mail/main.cf la chose suivante : > > command_directory = /usr/sbin > daemon_directory = /usr/libexec/postfix > data_directory = /var/db/postfix > debug_peer_level = 2 > debugger_command = > disable_vrfy_command = yes > html_directory = /usr/share/doc/html/postfix > inet_interfaces = all > inet_protocols = all > mail_owner = postfix > mailq_path = /usr/bin/mailq > manpage_directory = /usr/share/man > maximal_queue_lifetime = 10d > milter_default_action = accept > mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.1/8 > newaliases_path = /usr/bin/newaliases > non_smtpd_milters = unix:/var/clamav/clamav-milter.sock > postscreen_access_list = permit_mynetworks > proxy_interfaces = 192.168.15.14 > queue_directory = /var/spool/postfix > readme_directory = /usr/share/examples/postfix > relay_domains = $mydestination, systella.fr > relay_recipient_maps = > sample_directory = /usr/share/examples/postfix > sendmail_path = /usr/sbin/sendmail > setgid_group = maildrop > smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock > smtpd_recipient_restrictions = permit_sasl_authenticated, > permit_mynetworks, check_relay_domains, reject_unauth_destination > unknown_local_recipient_reject_code = 550 > J'utilise Postfix comme primaire et comme secondaire, alors je ne sais rien concernant Sendmail. Mais, ma configuration Postfix comprend les adresses IP des autres serveurs Postfix dans le paramètre mynetworks et le secondaire aussi le paramètre relayhost de cette manière: relayhost = [mx1.example.com] Je pense que parce que relayhost manque de ta configuration, ton Postfix ne sait pas qu'il doive envoyer le message au MX1 sans essayer résoudre l'adresse se c'est du domaine @systella.fr en ce cas. > Mais à chaque fois que je tente un envoi, postfix me renvoie la chose > suivante : > > Root rayleigh:[/etc/mail] > telnet 62.212.98.88 25 > Trying 62.212.98.88... > Connected to 62.212.98.88. > Escape character is '^]'. > 220 legendre.systella.fr ESMTP Postfix > EHLO rayleigh > 250-legendre.systella.fr > 250-PIPELINING > 250-SIZE 1024 > 250-ETRN > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250 DSN > MAIL FROM: > 250 2.1.0 Ok > RCPT TO: > 451 4.3.0 : Temporary lookup failure > quit > 221 2.0.0 Bye > Connection closed by foreign host. > Root rayleigh:[/etc/mail] > > > Un RCPT TO: renvoie la même erreur alors > que ce compte existe sur le serveur en question. > > Et là, je ne comprends plus... Tous les howto que l'on trouve sur > internet proposent d'autres solutions qui ne donnent pas de meilleurs > résultats. > > Une idée ? > Il m'intéressera savoir si c'est le même après avoir ajouté relayhost à la configuration. Salut, -Roberto -- Roberto C. Sánchez
Re: Status of Virtualbox in debian
On Mon, 20 Jun 2022 14:21:53 +0200 Anders Andersson wrote: Hello Anders, >Has something changed that makes virtualbox workable again, or has it >*always* been available in sid? It's always(1) been available in sid. VB has still got the same issue WRT migrating to testing; Work may still be ongoing, in the background, to overcome the issue. It's academic to me as I don't use VB. That said, I was interested enough to go and have a poke around on the Debian package and bug tracker sites. (1) For certain values of 'always'. -- Regards _ / ) "The blindingly obvious is never immediately apparent" / _)rad "Is it only me that has a working delete key?" To the ends of the earth, you look for sense in it No Time To Be 21 - The Adverts pgppTInq8a0ZJ.pgp Description: OpenPGP digital signature
Re: Status of Virtualbox in debian
On Mon, Jun 20, 2022 at 02:21:53PM +0200, Anders Andersson wrote: > I remember when Virtualbox was removed from debian, and I remember the > reasons. That's why I was surprised when I saw a recent message to the > list where a user tried to install it. Searching for "virtualbox" > indeed shows me that it is available in stretch-backports and sid: > https://packages.debian.org/virtualbox=1 > > Has something changed that makes virtualbox workable again, or has it > *always* been available in sid? > My recollection is that it has always been available in sid. There are two slightly different meanings for "removed from Debian". There is total removal as a result of things like licensing, which results in the package being removed from all Debian distributions (including unstable and experimental). Then there is removal from testing (and therefore stable) as a result of major bugs or inability to provide security support. This is the case with packages like VirtualBox, MySQL (and mostly anything else from Oracle), where upstream refuses to provide information concerning which changes address which security vulnerabilities. That information is necessary for the Debian security team to properly support packages in a stable release. Regards, -Roberto -- Roberto C. Sánchez
Status of Virtualbox in debian
I remember when Virtualbox was removed from debian, and I remember the reasons. That's why I was surprised when I saw a recent message to the list where a user tried to install it. Searching for "virtualbox" indeed shows me that it is available in stretch-backports and sid: https://packages.debian.org/virtualbox=1 Has something changed that makes virtualbox workable again, or has it *always* been available in sid?
Postfix comme MX2 d'un Sendmail
Bonjour à tous, Je tente la configuration d'un serveur de mail postfix comme backup d'un sendmail des familles et le moins qu'on puisse dire, c'est que si la configuration de sendmail est complexe, on voit assez rapidement ce qui cloche contrairement à postfix ;-) Je _sais_ configurer un MX2 avec sendmail. J'ai déjà configuré le DNS : ;; ADDITIONAL SECTION: rayleigh.systella.fr. 86400 IN A 213.41.150.218 newton-ipv6.systella.fr. 86400 IN 2001:7a8:a8ed:253::1 newton.systella.fr. 86400 IN A 213.41.149.211 legendre.systella.fr. 86400 IN A 62.212.98.88 noemie.nerim.net. 86400 IN A 178.132.17.109 Le firewall est réglé correctement sur le MX2, je peux l'attaquer avec un telnet sur le port 25. J'ai un serveur de mail principal qui récupère avec sendmail tout un tas de domaines. Ce serveur fait office de ESMTP et de MX1, a accès à deux WAN et fonctionne en IPv4 et v6. Il fait exactement ce que je lui demande. Je dois utiliser un serveur distant qui utilise Postfix. Et là, c'est un désastre. Je n'arrive pas à avoir la configuration que je désire. Tous les mails envoyés à localhost ou à legendre.systella.fr (le serveur en question) sur le port submission doivent être traités par le MX local, lequel relaye vers le MX1 grâce à /etc/mail.aliases qui contient des choses comme ça : MAILER-DAEMON: postmaster postmaster: root toor: root daemon: root bin:root games: root postfix:postmaster named: root ntpd: root sshd: root nobody: root root: joel.bertr...@systella.fr operator: joel.bertr...@systella.fr ... Je ne veux pas que les utilisateurs puissent utiliser ce MX2 comme un ESMTP (ça casserait DKIM, SPFv1...). Je veux donc que tout ce qui n'est pas à destination de legendre.systella.fr et qui passe par le ESMTP et non le MX soit rejeté. Mais je veux aussi que tout ce qui est à destination de systella.fr soit relayé vers le MX1. Pour l'instant, j'ai écrit dans /etc/mail/main.cf la chose suivante : command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = disable_vrfy_command = yes html_directory = /usr/share/doc/html/postfix inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man maximal_queue_lifetime = 10d milter_default_action = accept mynetworks = 192.168.10.0/24, 192.168.12.0/24, 192.168.15.14/32, 127.0.0.1/8 newaliases_path = /usr/bin/newaliases non_smtpd_milters = unix:/var/clamav/clamav-milter.sock postscreen_access_list = permit_mynetworks proxy_interfaces = 192.168.15.14 queue_directory = /var/spool/postfix readme_directory = /usr/share/examples/postfix relay_domains = $mydestination, systella.fr relay_recipient_maps = sample_directory = /usr/share/examples/postfix sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, check_relay_domains, reject_unauth_destination unknown_local_recipient_reject_code = 550 Mais à chaque fois que je tente un envoi, postfix me renvoie la chose suivante : Root rayleigh:[/etc/mail] > telnet 62.212.98.88 25 Trying 62.212.98.88... Connected to 62.212.98.88. Escape character is '^]'. 220 legendre.systella.fr ESMTP Postfix EHLO rayleigh 250-legendre.systella.fr 250-PIPELINING 250-SIZE 1024 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: 250 2.1.0 Ok RCPT TO: 451 4.3.0 : Temporary lookup failure quit 221 2.0.0 Bye Connection closed by foreign host. Root rayleigh:[/etc/mail] > Un RCPT TO: renvoie la même erreur alors que ce compte existe sur le serveur en question. Et là, je ne comprends plus... Tous les howto que l'on trouve sur internet proposent d'autres solutions qui ne donnent pas de meilleurs résultats. Une idée ? Bien cordialement, JKB
