Re: How do I remotely access the computer in the next room?
On Mon, Jul 03, 2023 at 12:17:36AM +0100, Alain D D Williams wrote: > On Sun, Jul 02, 2023 at 06:49:07PM -0400, hobie of RMN wrote: > > Hi, All - > > > > I need the best way currently available to operate my brother's computer > > in the next room through my computer [...] > Claws-mail stores mail in the MH mailbox format. Mutt can handle MH mailboxes. > Why not use mutt via ssh on his machine, for most messages you do not need to > use X (ie graphics), this might mean that the connection is more robust. If you are comfortable with mutt, I'd first try exactly this. Install mutt on your brother's computer and run it over ssh without X (perhaps things are stable then). Unfortunately it's difficult to know what's going wrong when the connection "crumbles". It may be related to X, but then it may not. More debugging would be necessary. Cheers -- t signature.asc Description: PGP signature
Re: Why does Debian have code names for releases?
On Sun 02 Jul 2023 at 11:30:39 (-0400), Dan Ritter wrote: > David Wright wrote: > > On Sat 01 Jul 2023 at 11:34:53 (-0400), Dan Ritter wrote: > > > David Wright wrote: > > > > On Mon 26 Jun 2023 at 17:22:04 (-0400), Jeffrey Walton wrote: > > > > > On Mon, Jun 26, 2023 at 4:45 PM Dan Ritter > > > > > wrote: > > > > > > riveravaldez wrote: > > > > > > > It would be possible, as an alternative, to populate sources.list > > > > > > > with '2021', > > > > > > > for instance, instead of 'bullseye', 'bookworm', etc.? > > > > > > > > > > > > > > We could have something like, 'Debian 2023 - Bookworm', so, > > > > > > > preserving > > > > > > > tradition, but allowing '2023' to be used as an alternative > > > > > > > replacement of > > > > > > > the traditional name maybe? > > > > > > > > > > > > > > Just an idea, looking for a simple solution... > > > > > > > > > > > > > > BTW, considering Debian doesn't have the marketing impositions of > > > > > > > any > > > > > > > proprietary commercial product, I find 'Debian 2021', 'Debian > > > > > > > 2023', etc., > > > > > > > reasonably appealing... > > > > > > > > > > > > This would also be useful in my efforts to explain to my boss > > > > > > why we're upgrading the machines. > > > > > > > > > > > > "It's 2023 and we're running Debian 2021. It's time to upgrade." > > > > > > > > > > ++ > > > > > > > > I don't see how that works. What would your codename be, instead of > > > > trixie? How do you know? > > > > > > I wouldn't care, because "2023" would be a synonym for > > > "bookworm" in all the appropriate files. > > > > Now that bookworm has been released, it's straightforward to assign > > to it a Release Number of 2023. But the OP was querying the invention > > of the codename trixie. I'm asking what alternative would you choose? > > Trixie is what we would use up until code freeze, at which point > we would have the option of continuing to call it trixie, but it > would gain the synonym 2023. Suit yourself; the release names are not of any particular interest to me per se. They might be important for marketing and advocacy, but I'm not involved in that. All power to those who are: they probably hold views on the best names to choose. > > > > a project, and everyone knows what they're talking about. Unlike > > > > numbers, > > > > names are memorable and unambiguous (when well-chosen). > > > > > > buster, bullseye, bookworm. So we can't depend on them to be > > > well-chosen. > > > > What's not well-chosen about any one of those codenames? (I know some > > people have difficulty distinguishing between words with the same > > initial letter, even though their common meanings are completely > > different.) > > When I talk to my users and my boss, all of them have trouble > remembering them and keeping the order straight. > > And when I talk about releases older than oldoldstable, I have > trouble too. I don't know anything about your organisation. The environment I worked in was not principally concerned with computing, and I don't think my boss had any knowledge beyond the word "Linux", (possibly). My users were immersed in my software, but didn't concern themselves particularly with what OS was running it. As a user myself (of the university computing service), we were surveyed about application software that could/would/ought to be made available, but not the timing of OS upgrades, which required coordination across departments. When I served for a while on the appropriate committee, I remember our views being sought on which manufacturers would be asked to submit bids for the replacement system. We didn't discuss OS versions from five years ago, using either codenames or Sunday best names. > > I don't think it's sensible to use bare year numbers for releases, > > let alone for codenames for as yet unreleased versions, even where > > the dates were thought to be predictable. Take a couple of recent > > posts, transcribing them from codenames into year numbers: > > > > I'm not sure what you're reading into that. The 2021 manpage has a > > copyright date of 2006 (Red Hat). But if we look at service itself, > > which is a script, we can see that the ?earliest Debian version was > > written in 2004 by our very own John Hasler, for 2005 through 2009, > > by which time the version we have now, I think, joins it, and > > replaces it in 2011. > > > > It's not immediately clear that 2006 and 2004 are literal dates, > > whereas the other numbers were originally codenames. > > I am amenable to "stable2023" or "debian2023" or any reasonable, > unambiguous encoding standardization along those lines. That would seem more reasonable. > > These numbers are all standing for codenames. However, the dates that > > they now superficially resemble are misleading, because the ranking > > decisions are likely to have been made up to two years or more earlier > > than it would seem from the numbers. > > They went into effect when each stable
Re: Why does Debian have code names for releases?
On Sun 02 Jul 2023 at 12:08:27 (-0400), Stefan Monnier wrote: > >> > Unlike numbers, names are memorable and unambiguous (when well-chosen). > >> This claim is far from evident and needs justification. The only > [...] > > Leaving aside that Titanic is the real name of the ship and not a > > codename, the evidence is all around you. Look no further than > > your login name, or the name of your computer. A huge slice of the > > Internet's infrastructure, DNS, is concerned with allowing people > > to converse with memorable names rather than anonymous numbers. > > Anecdotal evidence cuts both ways: how many years have names rather > than numbers? One way of looking at this, for Anglophones: Every year has a name: it looks like the number of the year when written, but it's pronounced differently: for example, 1968, pronounced "nineteen sixtyeight". Convention dictates that the year is never written grouped, like 1,968, but is pronounced almost universally grouped into (unspoken) hundreds. One wouldn't say "one thousand and sixtyeight" (or "one thousand sixtyeight" in American). Exceptionally, the names of the years in the opening decade of this century haven't yet settled. Perhaps they never will until people alive at the time are all dead. > Numbers can be easier to remember in some cases, and names in others. Perhaps more people remember the A5 is the Holyhead Road, rather than the name Watling Street, unless you live in Milton Keynes, where it's also the V4. And MK is one place where you might think you remember the road numbers better than their names, but really you're just counting. There's a V9, which I must have driven on, if only to park in Downs Barn and dodge the fees in Central MK, but I don't have a clue what it's called, as most of it doesn't exist. That which does lies between Marlborough St (V8) and Brickhill St (V10), both of which I knew well, over two decades ago. And now I'm rambling 'cause I'm stuck: I'm not sure why I'm the one having to think up examples. Cheers, David.
Re: How do I remotely access the computer in the next room?
On Sun, 2023-07-02 at 22:18 -0400, Carl Fink wrote: > On 7/2/23 18:49, hobie of RMN wrote: > > Hi, All - > > > > I need the best way currently available to operate my brother's > > computer > > in the next room through my computer. I think we're both running > > Debian > > 11, the stable version for me, the testing version for him. I've > > tried > > ssh -X. It does work but only for a short time, then the > > connection > > crumbles - his computer has often locked up on him and we have no > > idea > > why, so the 'short time' aspect of the -X approach may relate to > > that. > > > > The point is, he's been away from home for awhile now and we're not > > sure > > when he'll return. Chiefly I'm looking for the most convenient way > > to keep > > an eye on his incoming e-mail for him. Mostly I use Mutt; he uses > > claws-mail exclusively, so I'll need to remotely launch claws-mail > > and > > have it retrieve latest e-mails. > > > > Thanks in advance for any help on this. Why doesn't he just access his email off his provider's server? Why doesn't he have access to that? Cheers! -- A Kiwi in Australia, doing my bit toward raising the national standard.
Re: How do I remotely access the computer in the next room?
On 7/2/23 18:49, hobie of RMN wrote: Hi, All - I need the best way currently available to operate my brother's computer in the next room through my computer. I think we're both running Debian 11, the stable version for me, the testing version for him. I've tried ssh -X. It does work but only for a short time, then the connection crumbles - his computer has often locked up on him and we have no idea why, so the 'short time' aspect of the -X approach may relate to that. The point is, he's been away from home for awhile now and we're not sure when he'll return. Chiefly I'm looking for the most convenient way to keep an eye on his incoming e-mail for him. Mostly I use Mutt; he uses claws-mail exclusively, so I'll need to remotely launch claws-mail and have it retrieve latest e-mails. Thanks in advance for any help on this. Surely it would be easier, if you have his mail password, to just set up claws-mail on your own system and download the mail there? I mean, clearly your brother trusts you with his email, and this way you wouldn't have to worry about his box's instability. -Carl Fink
Re: How do I remotely access the computer in the next room?
Hi, On Mon, Jul 03, 2023 at 12:17:36AM +0100, Alain D D Williams wrote: > On Sun, Jul 02, 2023 at 06:49:07PM -0400, hobie of RMN wrote: > > Chiefly I'm looking for the most convenient way to keep an eye > > on his incoming e-mail for him. Mostly I use Mutt; he uses > > claws-mail exclusively, so I'll need to remotely launch > > claws-mail and have it retrieve latest e-mails. > > Claws-mail stores mail in the MH mailbox format. Mutt can handle MH mailboxes. I'd probably go a step further and rsync those MH folders to my machine; that way I could use whatever mail program I liked locally without fear of affecting the other machine or the pristine copy of its email. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: How do I remotely access the computer in the next room?
enable X forwarding on the remote pc and install lxde and then,from your pc,run : ssh -Y ip remote lxpanel Il lun 3 lug 2023, 01:50 Jeffrey Walton ha scritto: > On Sun, Jul 2, 2023 at 6:56 PM hobie of RMN > wrote: > > > > I need the best way currently available to operate my brother's computer > > in the next room through my computer. I think we're both running Debian > > 11, the stable version for me, the testing version for him. I've tried > > ssh -X. It does work but only for a short time, then the connection > > crumbles - his computer has often locked up on him and we have no idea > > why, so the 'short time' aspect of the -X approach may relate to that. > > Turn off Suspend under power settings. That is killing your SSH connection. > > > The point is, he's been away from home for awhile now and we're not sure > > when he'll return. Chiefly I'm looking for the most convenient way to > keep > > an eye on his incoming e-mail for him. Mostly I use Mutt; he uses > > claws-mail exclusively, so I'll need to remotely launch claws-mail and > > have it retrieve latest e-mails. > > Assuming you want a GUI tool, you might try VNC or Xpra. > > Jeff > >
Re: How do I remotely access the computer in the next room?
On Sun, Jul 2, 2023 at 6:56 PM hobie of RMN wrote: > > I need the best way currently available to operate my brother's computer > in the next room through my computer. I think we're both running Debian > 11, the stable version for me, the testing version for him. I've tried > ssh -X. It does work but only for a short time, then the connection > crumbles - his computer has often locked up on him and we have no idea > why, so the 'short time' aspect of the -X approach may relate to that. Turn off Suspend under power settings. That is killing your SSH connection. > The point is, he's been away from home for awhile now and we're not sure > when he'll return. Chiefly I'm looking for the most convenient way to keep > an eye on his incoming e-mail for him. Mostly I use Mutt; he uses > claws-mail exclusively, so I'll need to remotely launch claws-mail and > have it retrieve latest e-mails. Assuming you want a GUI tool, you might try VNC or Xpra. Jeff
Re: How do I remotely access the computer in the next room?
On Sun, Jul 02, 2023 at 06:49:07PM -0400, hobie of RMN wrote: > Hi, All - > > I need the best way currently available to operate my brother's computer > in the next room through my computer. I think we're both running Debian > 11, the stable version for me, the testing version for him. I've tried > ssh -X. It does work but only for a short time, then the connection > crumbles - his computer has often locked up on him and we have no idea > why, so the 'short time' aspect of the -X approach may relate to that. > > The point is, he's been away from home for awhile now and we're not sure > when he'll return. Chiefly I'm looking for the most convenient way to keep > an eye on his incoming e-mail for him. Mostly I use Mutt; he uses > claws-mail exclusively, so I'll need to remotely launch claws-mail and > have it retrieve latest e-mails. Claws-mail stores mail in the MH mailbox format. Mutt can handle MH mailboxes. Why not use mutt via ssh on his machine, for most messages you do not need to use X (ie graphics), this might mean that the connection is more robust. You would only use graphics for displaying some attachments, eg images. > Thanks in advance for any help on this. > > --hobie > -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include
How do I remotely access the computer in the next room?
Hi, All - I need the best way currently available to operate my brother's computer in the next room through my computer. I think we're both running Debian 11, the stable version for me, the testing version for him. I've tried ssh -X. It does work but only for a short time, then the connection crumbles - his computer has often locked up on him and we have no idea why, so the 'short time' aspect of the -X approach may relate to that. The point is, he's been away from home for awhile now and we're not sure when he'll return. Chiefly I'm looking for the most convenient way to keep an eye on his incoming e-mail for him. Mostly I use Mutt; he uses claws-mail exclusively, so I'll need to remotely launch claws-mail and have it retrieve latest e-mails. Thanks in advance for any help on this. --hobie
Re: Raid Array and Changing Motherboard
On 7/2/23 13:11, Mick Ab wrote: On 19:58, Sun, 2 Jul 2023 David Christensen On 7/2/23 10:23, Mick Ab wrote: I have a software RAID 1 array of two hard drives. Each of the two disks contains the Debian operating system and user data. I am thinking of changing the motherboard because of problems that might be connected to the current motherboard. The new motherboard would be the same make and model as the current motherboard. Would I need to recreate the RAID 1 array for the new motherboard I.e. re-initialise the current RAID 1 disks and repopulate the disks with data or can I just set up the software RAID on the new motherboard without affecting the current data on the RAID 1 drives ? Shutdown the machine. Boot using a live USB stick. Type notes into a text file. Use script(1) to record console sessions. Use dd(1) to take an image of each disk to an external HDD (consider piping dd(1) to gzip(1) to save space). Shutdown. Take note of which HDD is cabled to which motherboard port. Replace motherboard. Connect HDD's to the same motherboard ports. Boot. It should "just work". Post details if you have problems. David Thanks for your reply. I don't quite understand what you are proposing. Backup the RAID member drives first, then swap motherboards. Do you mean the external HDDs would form a new RAID 1 array for the new motherboard ? No. For each existing RAID member drive, copy its blocks to a file on the external HDD. What would happen to the original RAID 1 disks ? They stay in the chassis and are connected to the same ports on the new motherboard. David
Re: Raid Array and Changing Motherboard
On 02.07.2023 22:23, Mick Ab wrote: I have a software RAID 1 array of two hard drives. Each of the two disks contains the Debian operating system and user data. I am thinking of changing the motherboard because of problems that might be connected to the current motherboard. The new motherboard would be the same make and model as the current motherboard. Would I need to recreate the RAID 1 array for the new motherboard I.e. re-initialise the current RAID 1 disks and repopulate the disks with data or can I just set up the software RAID on the new motherboard without affecting the current data on the RAID 1 drives ? It's hard to tell what exactly will happen, because it depends on BIOS/Firmware of the motherboard, even though there is a special metadata record on each disk, which contains role of the disk and configuration of the RAID array. I predict two outcomes: 1. Two disks connected to a new motherboard will be recognized by BIOS/Firmware right away after you switch controller mode from AHCI to RAID, and appear as existing RAID1 array. 2. Two disks connected to a new motherboard will appear as two normal disks and won't be recognized as a RAID1 array, asking you to create\init array. In case #2 data on disks will be lost, so before you do any manipulations make and verify backups. Usually BIOS RAID software is very basic and won't allow to preserve current data on disks, or select a role (primary/secondary) for the disks, or create incomplete RAID1 array using only one disk to allow to copy data over from the second disk. If you happen to have any other two old disks on hand, I suggest you to experiment with those on current motherboard, i.e. create an additional new RAID1 array and see if that array stays intact after simulated disks "transfer". You can simulate disks transfer by powering of the computer, disconnecting the test disks and check if test RAID1 array still listed. If test array will be listed and report two test disks missing then array information is also recorded in BIOS and this array information won't be on a new motherboard. However, if there won't be any information about test array, then it should appear when you reconnect test disks and data on test disks should be intact. There could be also a manual available from motherboard's manufacturer which could give some clues about what is possible and what would happen. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 02/07/2023 à 19:36, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
[...]
- tous les appels sortants échouent lamentablement ;
>>> Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
>>> les logs ici
> Pas de logs ...
Oui, journée difficile...
rayleigh*CLI> core set verbose 3
Console verbose was OFF and is now 3.
[Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
[Jul 2 23:11:18] WARNING[22514]: res_pjsip.c:2497 set_id_from_hdr:
CallerID Name 'BERTRAND Jo�l' for number '6001' has invalid UTF-8
characters which were replaced
-- Executing [001@internal:1] Dial("PJSIP/6001-0008",
"PJSIP/01@SBSR") in new stack
-- Called PJSIP/01@SBSR
== Everyone is busy/congested at this time (1:0/1/0)
-- Auto fallthrough, channel 'PJSIP/6001-0008' status is
'CONGESTION'
- les appels entrants font bien sonner le bon téléphone, mais seule la
voie sortante fonctionne.
>>> je ne comprends pas cette phrase
> ?
Lorsque j'appelle par exemple de mon cellulaire vers un numéro
correspondant au trunk SIP.
Il n'y a aucun paquet RTP qui provient de
l'extérieur...
>>> Qu'as tu mis dans ton transport
>>>
>>> external_media_address et external_signaling_address ?
>> [tcp-transport]
>> type=transport
>> protocol=tcp
>> bind=192.168.15.18
>> local_net=192.168.0.0/16
>> external_media_address=adresse publique
>> external_signaling_address=adresse publique
>
> tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette
> de ports que tu as définie est elle bien renvoyée vers asterisk ?
Tout est renvoyé vers le serveur asterisk (DMZ) qui accepte tout ce qui
vient du sous-réseau de l'opérateur en question quel que soit le
protocole (iptables). La signalisation est faite en TCP sur le port
5070. Mais les paquets RTP doivent normalement passer en UDP. Du reste,
c'est bien ce que j'observe.
>>
>>> Difficile de te répondre ne connaissant pas le schéma du réseau ...
>> WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1)
>> | |
>> | 192.168.1.2
>> +-serveur LAN
>> 192.168.10.128
>> |
>> LAN
>>
>> Tous les postes sont sur le LAN. Le WAN est en fait un MPLS
>> (redondance
>> fibre/4G d'un /29).
> Par hasard, une livebox ? Une fibre FIB Orange ?
Non, réseau Axione avec un Cisco.
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
>>> Ne connaissant pas la config de SBSR.
>>>
>>> Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
>>> commence par 0 plus un caractère minimum à ton opérateur, il risque de
>>> ne pas aimer ;)
>> [internal]
>> exten => 6001,1,Dial(PJSIP/6001)
>> exten => 6002,1,Dial(PJSIP/6002)
>> exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> Depuis le 01/01/2023 les 06 et 07 sont interdits pour la prospection
> commerciale, les numéros géographiques ne le sont plus, les 09 sont les
> numéros en vogue
>
> Ton opérateur ne publie t'il pas d'exemple de configuration ?
J'ai un accès internet pour les ploucs. J'ai déjà eu du mal à obtenir
une fibre avec un /29 IPv4 et un /48 IPv6 et un routage MPLS... Je n'ai
pas accès aux opérateurs pro classiques, il faut que ces opérateurs
aient un contrat de partenariat avec la région et ce sont souvent des
gens qui sont à trois ou quatre dans une boîte...
Re: Monitor Problem
On 07/02/2023 04:50 PM, Jeffrey Walton wrote: On Sun, Jul 2, 2023 at 4:36 PM Felix Miata wrote: Stephen P. Molnar composed on 2023-07-02 13:58 (UTC-0400): [...] I am at a resolution of 1024x768. Also, after I got in the first tine I decided to reboot and see what would happen. I had to do the fix again, so, of course, it is not permanent. Appending nomodeset is primarily intended for troubleshooting graphics issues by enabling fallback graphics functional for editing configurations and running package management. As long as you must use nomodeset, you are forced into 1024x768 at best, sometimes worse. It's only coincidental that this mode is used by both your original problem and using nomodeset, because it's a failsafe fallback. Gotta love tribal knowledge... Jeff Oh, I do! I do! Thank goodness for it, and all the great and knowledgeable people on this list!!! -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: Monitor Problem
On Sun, Jul 2, 2023 at 4:36 PM Felix Miata wrote: > Stephen P. Molnar composed on 2023-07-02 13:58 (UTC-0400): > [...] > > I am at a resolution of 1024x768. Also, after I got in the first tine I > > decided to reboot and see what would happen. I had to do the fix again, > > so, of course, it is not permanent. > > Appending nomodeset is primarily intended for troubleshooting graphics issues > by > enabling fallback graphics functional for editing configurations and running > package management. As long as you must use nomodeset, you are forced into > 1024x768 at best, sometimes worse. It's only coincidental that this mode is > used > by both your original problem and using nomodeset, because it's a failsafe > fallback. Gotta love tribal knowledge... Jeff
Re: Monitor Problem
Stephen P. Molnar composed on 2023-07-02 13:58 (UTC-0400): > Felix Miata wrote: >> Stephen P. Molnar composed on 2023-07-02 10:57 (UTC-0400): >>> I should have posted to the debian users group, but unfortunately, I >>> can't access the last reply you sent. Fortunately, I printed it. >>> I guess I really did it this time, I found a HDMI to HDMi at the >>> Microcenter but it doesn't open until 11:00am. >> Walmart has them, unless the pegs are all out of stock. Same for Best Buy. >> They're >> no different for PCs than for TVs. >>> So I thought I'd go ahead and remove the xserver-org-video-radeon driver >>> in preparation. When I rebooted the system I got an out of range signal >>> again. When I booted in to the recovery mode I got a arm_radeon_ vga >>> detect [radeon] *ERROR* VGA-1 probrd a monitor but no|invalid EDI error >>> that repeats over and over. >> At the Grub menu with the default still selected, strike the E key, then >> navigate >> to the end of the line that begins linu. Append there nomodeset, then >> proceed with >> the boot via F10 or Ctrl-X. First, try normally using the HDMI cable you >> should >> have procured by now. >> Most developers haven't used VGA connections for more than a decade, so they >> miss >> regressions they cause. Until users discover and report them, nothing gets >> done >> about them. Digital connections both produce higher quality output, and more >> reliability. >>> I really hate to bother you with this > Once again, your expertise and instructions have moved me back to whete > I was. > (base) comp@AbNormal:~$ inxi -GSaz > System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 > parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-23-amd64 > root=UUID=9848531c-e052-44b0-a5b6-9ea786f9eaee ro quiet nomodeset > Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm4 > dm: LightDM 1.26.0 > Distro: Debian GNU/Linux 11 (bullseye) > Graphics: Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: > VISIONTEK > driver: N/A alternate: radeon bus ID: 01:00.0 chip ID: 1002:68f9 > class ID: 0300 > Display: x11 server: X.Org 1.20.11 driver: loaded: vesa unloaded: > fbdev,modesetting > alternate: ati display ID: :0.0 screens: 1 > Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 271x203mm > (10.7x8.0") s-diag: 339mm (13.3") > Monitor-1: default res: 1024x768 > OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa > 20.3.5 compat-v: 3.1 > direct render: Yes That info is incomplete. Bullseye's inxi is ancient and broken. If you edit /etc/inxi.conf to read as follows: # cat /etc/inxi.conf ## We want to use the distro to track the package B_ALLOW_UPDATE=true GLOBAL_COLOR_SCHEME=0 # then sudo inxi -U will update it to the current version. > I am at a resolution of 1024x768. Also, after I got in the first tine I > decided to reboot and see what would happen. I had to do the fix again, > so, f course, it is not permanent. Appending nomodeset is primarily intended for troubleshooting graphics issues by enabling fallback graphics functional for editing configurations and running package management. As long as you must use nomodeset, you are forced into 1024x768 at best, sometimes worse. It's only coincidental that this mode is used by both your original problem and using nomodeset, because it's a failsafe fallback. > So the question is what do I do next? Perhaps, install Debian 12.0.0 on > my 500 GB SSD. > What do you think? Your new HD5450 GPU is in fact older than your "old" Kaveri Radeon R7 GPU. Your new one is the last of its generation. Your old one was the second of its generation. The generational change was very significant, quite a change in technology. Thus, your initrds might not be supporting it, which would cause fallback to the crude ancient techology VESA fallback display driver if the support for the older had never been installed. If this is the problem, rebuilding the initrds should solve it. Before doing that I would try sudo modprobe radeon to see if it has an apparent impact. If it solves the problem, running update-initramfs might be all that is required. It might also be that libdrm-radeon1 is not installed, which your HD5450 requires for optimal operation, and so also would need to be installed. If all is well, you should probably see pretty close to exactly as follows: # lsmod | egrep 'vid|deo|ati ' | sort drm 626688 5 drm_kms_helper,radeon,ttm drm_kms_helper278528 1 radeon i2c_algo_bit 16384 1 radeon radeon 1675264 2 ttm 114688 1 radeon video 61440 1 dell_wmi # dpkg-query -W | egrep 'firmwar|radeon' firmware-amd-graphics 20210315-3 firmware-linux-free 20200122-1 libdrm-radeon1:amd642.4.104-1 # All that said, I cannot imagine a
Re: Raid Array and Changing Motherboard
On 19:58, Sun, 2 Jul 2023 David Christensen > On 7/2/23 10:23, Mick Ab wrote: > > I have a software RAID 1 array of two hard drives. Each of the two disks > > contains the Debian operating system and user data. > > > > I am thinking of changing the motherboard because of problems that might be > > connected to the current motherboard. The new motherboard would be the same > > make and model as the current motherboard. > > > > Would I need to recreate the RAID 1 array for the new motherboard I.e. > > re-initialise the current RAID 1 disks and repopulate the disks with data > > or can I just set up the software RAID on the new motherboard without > > affecting the current data on the RAID 1 drives ? > > > Shutdown the machine. Boot using a live USB stick. Type notes into a > text file. Use script(1) to record console sessions. Use dd(1) to take > an image of each disk to an external HDD (consider piping dd(1) to > gzip(1) to save space). Shutdown. Take note of which HDD is cabled to > which motherboard port. Replace motherboard. Connect HDD's to the same > motherboard ports. Boot. It should "just work". > > > Post details if you have problems. > > > David > > Thanks for your reply. I don't quite understand what you are proposing. Do you mean the external HDDs would form a new RAID 1 array for the new motherboard ? What would happen to the original RAID 1 disks ?
Re: Configuration asterisk
Le 02/07/2023 à 19:36, BERTRAND Joël a écrit :
NoSpam a écrit :
Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
[...]
- tous les appels sortants échouent lamentablement ;
Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
les logs ici
Pas de logs ...
- les appels entrants font bien sonner le bon téléphone, mais seule la
voie sortante fonctionne.
je ne comprends pas cette phrase
?
Il n'y a aucun paquet RTP qui provient de
l'extérieur...
Qu'as tu mis dans ton transport
external_media_address et external_signaling_address ?
[tcp-transport]
type=transport
protocol=tcp
bind=192.168.15.18
local_net=192.168.0.0/16
external_media_address=adresse publique
external_signaling_address=adresse publique
tcp ? udp est la norme mais ppurqoi pas. RTP est en UDP.: la fourchette
de ports que tu as définie est elle bien renvoyée vers asterisk ?
Difficile de te répondre ne connaissant pas le schéma du réseau ...
WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1)
| |
| 192.168.1.2
+-serveur LAN
192.168.10.128
|
LAN
Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance
fibre/4G d'un /29).
Par hasard, une livebox ? Une fibre FIB Orange ?
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
Ne connaissant pas la config de SBSR.
Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
commence par 0 plus un caractère minimum à ton opérateur, il risque de
ne pas aimer ;)
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR)
exten => _00[1-79],1,Dial(PJSIP/${EXTEN:1}@SBSR)
Depuis le 01/01/2023 les 06 et 07 sont interdits pour la prospection
commerciale, les numéros géographiques ne le sont plus, les 09 sont les numéros
en vogue
Ton opérateur ne publie t'il pas d'exemple de configuration ?
[sbsr]
exten => +33,1,Dial(PJSIP/6001)
exten => +33,1,Dial(PJSIP/6002)
Es tu sûr que ton opérateur envoi le numéro préfixé +33 ?
Oui, j'en suis sûr, je le vois passer dans les logs.
Re: Raid Array and Changing Motherboard
On 7/2/23 10:23, Mick Ab wrote: I have a software RAID 1 array of two hard drives. Each of the two disks contains the Debian operating system and user data. I am thinking of changing the motherboard because of problems that might be connected to the current motherboard. The new motherboard would be the same make and model as the current motherboard. Would I need to recreate the RAID 1 array for the new motherboard I.e. re-initialise the current RAID 1 disks and repopulate the disks with data or can I just set up the software RAID on the new motherboard without affecting the current data on the RAID 1 drives ? Shutdown the machine. Boot using a live USB stick. Type notes into a text file. Use script(1) to record console sessions. Use dd(1) to take an image of each disk to an external HDD (consider piping dd(1) to gzip(1) to save space). Shutdown. Take note of which HDD is cabled to which motherboard port. Replace motherboard. Connect HDD's to the same motherboard ports. Boot. It should "just work". Post details if you have problems. David
Re: Why does Debian have code names for releases?
Stefan Monnier wrote: >> Leaving aside that Titanic is the real name of the ship and >> not a codename, the evidence is all around you. Look no >> further than your login name, or the name of your computer. >> A huge slice of the Internet's infrastructure, DNS, is >> concerned with allowing people to converse with memorable >> names rather than anonymous numbers. > > Anecdotal evidence cuts both ways: how many years have names > rather than numbers? There are pieces of military equipment that have a code designation as well as a flashy name, and people still use the code designation. There is no telling what will stick from one case to the other, or what will be most popular by some majority of guys using it. As long as there is a name or designation people can refer to it which is the most important part. -- underground experts united https://dataswamp.org/~incal
Re: Raid Array and Changing Motherboard
On Sun, 2 Jul 2023 18:23:31 +0100 Mick Ab wrote: > I am thinking of changing the motherboard because of problems that > might be connected to the current motherboard. The new motherboard > would be the same make and model as the current motherboard. > > Would I need to recreate the RAID 1 array for the new motherboard I.e. > re-initialise the current RAID 1 disks and repopulate the disks with > data or can I just set up the software RAID on the new motherboard > without affecting the current data on the RAID 1 drives ? I believe that will depend on how you built the RAID array. Assuming the new motherboard supports your current hard drives and peripheral cards. (As it should if it is the same make and model, and the manufacturer did nothing stupid.) If you used mdadm (Linux software RAID), you should have no problem. Some hardware RAID systems on a card should be OK. RAID in the firmware on the motherboard should be OK, unless the manufacturer made an incompatible upgrade. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Monitor Problem
On 07/02/2023 01:21 PM, Felix Miata wrote: Stephen P. Molnar composed on 2023-07-02 10:57 (UTC-0400): I should have posted to the debian users group, but unfortunately, I can't access the last reply you sent. Fortunately, I printed it. I guess I really did it this time, I found a HDMI to HDMi at the Microcenter but it doesn't open until 11:00am. Walmart has them, unless the pegs are all out of stock. Same for Best Buy. They're no different for PCs than for TVs. So I thought I'd go ahead and remove the xserver-org-video-radeon driver in preparation. When I rebooted the system I got an out of range signal again. When I booted in to the recovery mode I got a arm_radeon_ vga detect [radeon] *ERROR* VGA-1 probrd a monitor but no|invalid EDI error that repeats over and over. At the Grub menu with the default still selected, strike the E key, then navigate to the end of the line that begins linu. Append there nomodeset, then proceed with the boot via F10 or Ctrl-X. First, try normally using the HDMI cable you should have procured by now. Most developers haven't used VGA connections for more than a decade, so they miss regressions they cause. Until users discover and report them, nothing gets done about them. Digital connections both produce higher quality output, and more reliability. I really hate to bother you with this Once again, your expertise and instructions have moved me back to whete I was. (base) comp@AbNormal:~$ inxi -GSaz System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-23-amd64 root=UUID=9848531c-e052-44b0-a5b6-9ea786f9eaee ro quiet nomodeset Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 Distro: Debian GNU/Linux 11 (bullseye) Graphics: Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: VISIONTEK driver: N/A alternate: radeon bus ID: 01:00.0 chip ID: 1002:68f9 class ID: 0300 Display: x11 server: X.Org 1.20.11 driver: loaded: vesa unloaded: fbdev,modesetting alternate: ati display ID: :0.0 screens: 1 Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 271x203mm (10.7x8.0") s-diag: 339mm (13.3") Monitor-1: default res: 1024x768 OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.3.5 compat-v: 3.1 direct render: Yes I am at a resolution of 1024x768. Also, after I got in the first tine I decided to reboot and see what would happen. I had to do the fix again, so, f course, it is not permanent. So the question is what do I do next? Perhaps, install Debian 12.0.0 on my 500 GB SSD. What do you think? Thanks in advance. Apologies to the list fo not replying to the with my last email in the thread. -- Stephen P. Molnar, Ph.D. https://insilicochemistry.net (614)312-7528 (c) Skype: smolnar1
Re: Nvidia GT 710 and Secure Boot
Mick Ab composed on 2023-07-02 17:36 (UTC+0100): > I understand that some people have experienced problems with booting a > motherboard with Secure Boot enabled in the BIOS such that they get a blank > screen, can't enter the BIOS and possibly can't boot at all. > This problem seems to be due to having an old graphics card which doesn't > have UEFI firmware, in particular no GOP driver. > I have an Nvidia Geforce GT 710 graphics card, which is an old card and > probably doesn't have the UEFI firmware or GOP driver needed with the > Secure Boot feature. The way I understand GOP, the driver is provided by or for the bootloader when the bootloader is installed, and doesn't care about GPU firmware. > Is there a way in which the GT 710 can be updated to incorporate the > necessary UEFI firmware and GOP driver ? UEFI firmware is in a motherboard chip, not part of any gfxcard. I've had no problem using older gfxcards than yours in UEFI PC tests, but since the iGPU was newer in every case, there was no reason to burn extra electrons keeping an unneeded gfxcard installed. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Configuration asterisk
NoSpam a écrit :
>
> Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
>> [...]
>> - tous les appels sortants échouent lamentablement ;
> Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
> les logs ici
>> - les appels entrants font bien sonner le bon téléphone, mais seule la
>> voie sortante fonctionne.
> je ne comprends pas cette phrase
>> Il n'y a aucun paquet RTP qui provient de
>> l'extérieur...
>
> Qu'as tu mis dans ton transport
>
> external_media_address et external_signaling_address ?
[tcp-transport]
type=transport
protocol=tcp
bind=192.168.15.18
local_net=192.168.0.0/16
external_media_address=adresse publique
external_signaling_address=adresse publique
> Difficile de te répondre ne connaissant pas le schéma du réseau ...
WAN-modem fibre-(192.168.15.18)DMZ(asterisk 192.168.1.1)
| |
| 192.168.1.2
+-serveur LAN
192.168.10.128
|
LAN
Tous les postes sont sur le LAN. Le WAN est en fait un MPLS (redondance
fibre/4G d'un /29).
>>
>> [internal]
>> exten => 6001,1,Dial(PJSIP/6001)
>> exten => 6002,1,Dial(PJSIP/6002)
>> exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
>
> Ne connaissant pas la config de SBSR.
>
> Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
> commence par 0 plus un caractère minimum à ton opérateur, il risque de
> ne pas aimer ;)
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _00[1-7],1,Dial(PJSIP/${EXTEN:1}@SBSR)
>> [sbsr]
>> exten => +33,1,Dial(PJSIP/6001)
>> exten => +33,1,Dial(PJSIP/6002)
> Es tu sûr que ton opérateur envoi le numéro préfixé +33 ?
Oui, j'en suis sûr, je le vois passer dans les logs.
Raid Array and Changing Motherboard
I have a software RAID 1 array of two hard drives. Each of the two disks contains the Debian operating system and user data. I am thinking of changing the motherboard because of problems that might be connected to the current motherboard. The new motherboard would be the same make and model as the current motherboard. Would I need to recreate the RAID 1 array for the new motherboard I.e. re-initialise the current RAID 1 disks and repopulate the disks with data or can I just set up the software RAID on the new motherboard without affecting the current data on the RAID 1 drives ?
Re: Configuration asterisk
Le 02/07/2023 à 18:27, BERTRAND Joël a écrit :
[...]
- tous les appels sortants échouent lamentablement ;
Poste les logs. En cli, core set verbose 3 puis passe un appel en copie
les logs ici
- les appels entrants font bien sonner le bon téléphone, mais seule la
voie sortante fonctionne.
je ne comprends pas cette phrase
Il n'y a aucun paquet RTP qui provient de
l'extérieur...
Qu'as tu mis dans ton transport
external_media_address et external_signaling_address ?
Difficile de te répondre ne connaissant pas le schéma du réseau ...
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
Ne connaissant pas la config de SBSR.
Modifie ta ligne en _0X de manière à ne pas envoyer tout ce qui
commence par 0 plus un caractère minimum à ton opérateur, il risque de
ne pas aimer ;)
[sbsr]
exten => +33,1,Dial(PJSIP/6001)
exten => +33,1,Dial(PJSIP/6002)
Es tu sûr que ton opérateur envoi le numéro préfixé +33 ?
L'idée est de pouvoir sortir en faisant 0+numéro de téléphone.
Naturellement, la registration est bonne :
rayleigh*CLI> pjsip show registrations
==
SBSR/sip:37.97.65.186:5070 SBSR_auth
Registered(exp. 52s)
Objects found: 1
Bien cordialement,
JB
Nvidia GT 710 and Secure Boot
I understand that some people have experienced problems with booting a motherboard with Secure Boot enabled in the BIOS such that they get a blank screen, can't enter the BIOS and possibly can't boot at all. This problem seems to be due to having an old graphics card which doesn't have UEFI firmware, in particular no GOP driver. I have an Nvidia Geforce GT 710 graphics card, which is an old card and probably doesn't have the UEFI firmware or GOP driver needed with the Secure Boot feature. Is there a way in which the GT 710 can be updated to incorporate the necessary UEFI firmware and GOP driver ?
Re: Configuration asterisk
NoSpam a écrit :
> Fallait dire de suite que c'était pour un SPA ! C'est plus délicat mais
> cela fonctionne
>
> 1. d'ou sort le E accolé au 6001 ?
De nulle part, c'était un test pour ne pas avoir un identifiant
totalement numérique.
Je m'occuperai de cela lorsque j'aurai compris les plans de
numérotation. Pour l'instant, les appels passent d'un poste à l'autre en
interne, mais :
- tous les appels sortants échouent lamentablement ;
- les appels entrants font bien sonner le bon téléphone, mais seule la
voie sortante fonctionne. Il n'y a aucun paquet RTP qui provient de
l'extérieur...
[internal]
exten => 6001,1,Dial(PJSIP/6001)
exten => 6002,1,Dial(PJSIP/6002)
exten => _0.,1,Dial(PJSIP/${EXTEN:1}@SBSR)
[sbsr]
exten => +33,1,Dial(PJSIP/6001)
exten => +33,1,Dial(PJSIP/6002)
L'idée est de pouvoir sortir en faisant 0+numéro de téléphone.
Naturellement, la registration est bonne :
rayleigh*CLI> pjsip show registrations
==
SBSR/sip:37.97.65.186:5070 SBSR_auth
Registered(exp. 52s)
Objects found: 1
Bien cordialement,
JB
Re: Why does Debian have code names for releases?
>> > Unlike numbers, names are memorable and unambiguous (when well-chosen). >> This claim is far from evident and needs justification. The only [...] > Leaving aside that Titanic is the real name of the ship and not a > codename, the evidence is all around you. Look no further than > your login name, or the name of your computer. A huge slice of the > Internet's infrastructure, DNS, is concerned with allowing people > to converse with memorable names rather than anonymous numbers. Anecdotal evidence cuts both ways: how many years have names rather than numbers? Numbers can be easier to remember in some cases, and names in others. Stefan
Re: Configuration asterisk
Fallait dire de suite que c'était pour un SPA ! C'est plus délicat mais cela fonctionne 1. d'ou sort le E accolé au 6001 ? Mes notes pour Sipura 3k Line Enable: yes SIP Settings SIP Port: 5060 Proxy and Registration Proxy: Use Outbound Proxy: no Outbound Proxy: Use OB Proxy In Dialog: no Register: yes Make Call Without Reg: no Register Expires: Ans Call Without Reg: no Use DNS SRV: DNS SRV Auto Prefix: no Proxy Fallback Intvl: 3600 Subscriber Information Display Name: User ID: Password: Use Auth ID: no Auth ID: Mini Certificate: SRTP Private Key: Dial Plan: (<9,:9>9x<:@gw0>|<9,:><:@gw0>|<9,:0>[56]<:@gw0>|<9,:>[19]xx<:@gw0>|<9,:>0[19]<:@gw0>|xx.) Le 02/07/2023 à 17:48, BERTRAND Joël a écrit : NoSpam a écrit : sip:6001E@192.168.1.1 https://www.asterisk.org/identifying-endpoint-pjsip/ Rien n'y fait. Si je colle 6001 dans le SPA112, j'ai bien une trame qui demande une authentification du login sip:6001E@192.168.1.1. Mais que je colle username=6001E, 6001E@192.168.1.1 ou sip:6001E@192.168.1.1, ça termine par une erreur d'authentification. JB
Re: Configuration asterisk
NoSpam a écrit : > sip:6001E@192.168.1.1 > > https://www.asterisk.org/identifying-endpoint-pjsip/ Rien n'y fait. Si je colle 6001 dans le SPA112, j'ai bien une trame qui demande une authentification du login sip:6001E@192.168.1.1. Mais que je colle username=6001E, 6001E@192.168.1.1 ou sip:6001E@192.168.1.1, ça termine par une erreur d'authentification. JB
Re: Why does Debian have code names for releases?
David Wright wrote: > On Sat 01 Jul 2023 at 11:34:53 (-0400), Dan Ritter wrote: > > David Wright wrote: > > > On Mon 26 Jun 2023 at 17:22:04 (-0400), Jeffrey Walton wrote: > > > > On Mon, Jun 26, 2023 at 4:45 PM Dan Ritter > > > > wrote: > > > > > riveravaldez wrote: > > > > > > It would be possible, as an alternative, to populate sources.list > > > > > > with '2021', > > > > > > for instance, instead of 'bullseye', 'bookworm', etc.? > > > > > > > > > > > > We could have something like, 'Debian 2023 - Bookworm', so, > > > > > > preserving > > > > > > tradition, but allowing '2023' to be used as an alternative > > > > > > replacement of > > > > > > the traditional name maybe? > > > > > > > > > > > > Just an idea, looking for a simple solution... > > > > > > > > > > > > BTW, considering Debian doesn't have the marketing impositions of > > > > > > any > > > > > > proprietary commercial product, I find 'Debian 2021', 'Debian > > > > > > 2023', etc., > > > > > > reasonably appealing... > > > > > > > > > > This would also be useful in my efforts to explain to my boss > > > > > why we're upgrading the machines. > > > > > > > > > > "It's 2023 and we're running Debian 2021. It's time to upgrade." > > > > > > > > ++ > > > > > > I don't see how that works. What would your codename be, instead of > > > trixie? How do you know? > > > > I wouldn't care, because "2023" would be a synonym for > > "bookworm" in all the appropriate files. > > Now that bookworm has been released, it's straightforward to assign > to it a Release Number of 2023. But the OP was querying the invention > of the codename trixie. I'm asking what alternative would you choose? Trixie is what we would use up until code freeze, at which point we would have the option of continuing to call it trixie, but it would gain the synonym 2023. > > > a project, and everyone knows what they're talking about. Unlike numbers, > > > names are memorable and unambiguous (when well-chosen). > > > > buster, bullseye, bookworm. So we can't depend on them to be > > well-chosen. > > What's not well-chosen about any one of those codenames? (I know some > people have difficulty distinguishing between words with the same > initial letter, even though their common meanings are completely > different.) When I talk to my users and my boss, all of them have trouble remembering them and keeping the order straight. And when I talk about releases older than oldoldstable, I have trouble too. > I don't think it's sensible to use bare year numbers for releases, > let alone for codenames for as yet unreleased versions, even where > the dates were thought to be predictable. Take a couple of recent > posts, transcribing them from codenames into year numbers: > > I'm not sure what you're reading into that. The 2021 manpage has a > copyright date of 2006 (Red Hat). But if we look at service itself, > which is a script, we can see that the ?earliest Debian version was > written in 2004 by our very own John Hasler, for 2005 through 2009, > by which time the version we have now, I think, joins it, and > replaces it in 2011. > > It's not immediately clear that 2006 and 2004 are literal dates, > whereas the other numbers were originally codenames. I am amenable to "stable2023" or "debian2023" or any reasonable, unambiguous encoding standardization along those lines. > These numbers are all standing for codenames. However, the dates that > they now superficially resemble are misleading, because the ranking > decisions are likely to have been made up to two years or more earlier > than it would seem from the numbers. They went into effect when each stable version was released. Decisions are obviously made before they are implemented, and as I said, I'm not calling for a replacement, I'm calling for a substitutable predictable and postdictable alias implemented when the year of the stable release becomes extremely likely. The marginal case where unpredictable delays push a stable release out to December, and then possibly into the next calendar year, is not very concerning to me as long as there is no more than one stable .0 release per calendar year. -dsr-
Deactivating and Reactivating the display of a NUC 13
Hello everybody, This is a revised translation of a posting to the German Debian mailing list. Unfortunately nobody there was able to help me with my problem but I hope that on this list with a much wider list of readers somebody might have encountered my problem and found a solution for it. I have two NUC 13, one for work and one for private use. Both are running Debian 12 Bookworm with Gnome 43 and Wayland/Weston. My monitor is a Acer Predator XB273KGP, which has four connectors, two Displayport 1.4 and two HDMI 2.0. The Display port can do 120hz when connected via DP. One of the NUCs is connected with an USB-C-to-DP-Cable and the other one via HDMI 2.0 with only 60 hz. The other ports are used by other computers. My problem is that once the monitor is deactivated – either by manually switching it off or by DPMS - the only way to get a picture again is either to reboot the NUC or detach and re-attach the USB cable. The monitor simply complains that there is "No Signal" This runs counter to my intended usage. I want to enable power saving during the day and reactivate the NUC with a keypress when I want to check my emails or search Google. Also, the NUC is connected to my video projector via HDMI and I want to turn the computer display off when watching movies on the big screen. An active computer is both an unwelcome distraction and a waste of energy. Do you have any suggestions on how to fix this issue? I suspect that this is not the fault of my monitor – I have a windows pc for gaming and it awakes from suspend with a keypress without any problems. It is connected to another DP Port via a high quality DP cable. I do not even have a workaround until a long-term solution is found. At the moment I completely shutdown the NUC after use and start it when I want to use it. Luckily this takes only a few seconds – my NUCs are fast, especially with a Samsung 990 Pro – but I am still looking for a better way to handle this. Yours sincerely Stefan
Re: Why does Debian have code names for releases?
On Sat 01 Jul 2023 at 11:34:53 (-0400), Dan Ritter wrote: > David Wright wrote: > > On Mon 26 Jun 2023 at 17:22:04 (-0400), Jeffrey Walton wrote: > > > On Mon, Jun 26, 2023 at 4:45 PM Dan Ritter wrote: > > > > riveravaldez wrote: > > > > > It would be possible, as an alternative, to populate sources.list > > > > > with '2021', > > > > > for instance, instead of 'bullseye', 'bookworm', etc.? > > > > > > > > > > We could have something like, 'Debian 2023 - Bookworm', so, preserving > > > > > tradition, but allowing '2023' to be used as an alternative > > > > > replacement of > > > > > the traditional name maybe? > > > > > > > > > > Just an idea, looking for a simple solution... > > > > > > > > > > BTW, considering Debian doesn't have the marketing impositions of any > > > > > proprietary commercial product, I find 'Debian 2021', 'Debian 2023', > > > > > etc., > > > > > reasonably appealing... > > > > > > > > This would also be useful in my efforts to explain to my boss > > > > why we're upgrading the machines. > > > > > > > > "It's 2023 and we're running Debian 2021. It's time to upgrade." > > > > > > ++ > > > > I don't see how that works. What would your codename be, instead of > > trixie? How do you know? > > I wouldn't care, because "2023" would be a synonym for > "bookworm" in all the appropriate files. Now that bookworm has been released, it's straightforward to assign to it a Release Number of 2023. But the OP was querying the invention of the codename trixie. I'm asking what alternative would you choose? > > a project, and everyone knows what they're talking about. Unlike numbers, > > names are memorable and unambiguous (when well-chosen). > > buster, bullseye, bookworm. So we can't depend on them to be > well-chosen. What's not well-chosen about any one of those codenames? (I know some people have difficulty distinguishing between words with the same initial letter, even though their common meanings are completely different.) BTW nobody is forcing people to carry on using codenames after they've been given release numbers. It just says something about their usefulness. > > You don't have to memorize all of Debian's codenames in order, do you? > > There are about three or four in current use at any one time. (And the > > release numbers might be monotonic, but they're not sequential, so > > memorizing them would be just as tricky.) > > Since I've been using Debian since ... 1.3 ? I have been exposed > to at least a dozen names. > > It would always have been of more benefit to be able to say > "that went stable in 2002" or "next stable release will probably > be in 2025" rather than "3 Woody" and "13 Trixie". Keeping the > fun name is absolutely fine and indeed useful -- because > schedules slip and no software should be released before its > time. > > It's just that, when Trixie becomes stable, it would be very > useful to be able to put "2025" or "2026" in all my > documentation and config files instead of "13 Trixie". I don't think it's sensible to use bare year numbers for releases, let alone for codenames for as yet unreleased versions, even where the dates were thought to be predictable. Take a couple of recent posts, transcribing them from codenames into year numbers: I'm not sure what you're reading into that. The 2021 manpage has a copyright date of 2006 (Red Hat). But if we look at service itself, which is a script, we can see that the ?earliest Debian version was written in 2004 by our very own John Hasler, for 2005 through 2009, by which time the version we have now, I think, joins it, and replaces it in 2011. It's not immediately clear that 2006 and 2004 are literal dates, whereas the other numbers were originally codenames. You say your system is pre-2017, ie 2015. That means that you will have had both iproute2 and net-tools installed, as in 2015 they are both ranked important. AFAICT iproute2 has never been ranked lower than that, and its predecessor, iproute, was important as far back as 2009. (Earlier than that, it could only be optional, because you needed various options to have been compiled into the kernel.) These numbers are all standing for codenames. However, the dates that they now superficially resemble are misleading, because the ranking decisions are likely to have been made up to two years or more earlier than it would seem from the numbers. Cheers, David.
Re: Why does Debian have code names for releases?
On Sat 01 Jul 2023 at 18:00:01 (+0200), Roger Price wrote: > On Sat, 1 Jul 2023, David Wright wrote: > > > Unlike numbers, names are memorable and unambiguous (when well-chosen). > > This claim is far from evident and needs justification. The only > example I can think of is project number 401 which later became the > product "Titanic". However the name is not memorable in itself: what > we remember is the maritime disaster. Leaving aside that Titanic is the real name of the ship and not a codename, the evidence is all around you. Look no further than your login name, or the name of your computer. A huge slice of the Internet's infrastructure, DNS, is concerned with allowing people to converse with memorable names rather than anonymous numbers. Going back to your OP, the idea of using a purported Release Number before release is a recipe for confusion, because people may mistake it for an actual release before that actually happens. (The way in which the Debian project is organised is unlikely to result in one event that sometimes occurs elsewhere: where a distribution is partly built but abandoned, and a new one started under a fresh codename. Think MS's Cairo.) Moving on to ambiguity, any conversation about Debian is going to involve numbers: dates, version numbers, literal values, addresses, ports, enumerations, etc. Numbers have to be in a context, which tells you what sort of number it is. OTOH, with a codename like bookworm, the context of the list, forum, or whatever, is enough for you to know what it stands for. And it's "well-chosen" when it's a word unlikely to occur with a different meaning, and doesn't carry any misleading implications about the nature of the project, including release dates. Cheers, David.
Re: Configuration asterisk
sip:6001E@192.168.1.1 https://www.asterisk.org/identifying-endpoint-pjsip/ Le 02/07/2023 à 15:54, BERTRAND Joël a écrit : NoSpam a écrit : Remplace user=6002 par username=SDA112net2501 Dès que je mets autre chose qu'une suite de chiffres, je reçois ceci comme erreur : [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - Failed to authenticate [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - No matching endpoint found JB
Re: Configuration asterisk
NoSpam a écrit : > Remplace user=6002 par username=SDA112net2501 Dès que je mets autre chose qu'une suite de chiffres, je reçois ceci comme erreur : [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - Failed to authenticate [Jul 2 15:52:30] NOTICE[9876]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'REGISTER' from '"BERTRAND Jo�l" ' failed for '192.168.10.253:5060' (callid: 96a66e5d-8db7dc63@192.168.10.253) - No matching endpoint found JB
Re: Configuration asterisk
Remplace user=6002 par username=SDA112net2501 Perso: . j'utiliser le wizard . je préfère identify au lieu de l'enregistrement dès que possible Le 02/07/2023 à 15:27, BERTRAND Joël a écrit : [SDA112net2501](SDA112) auth=SDA112net2501 aors=SDA112net2501 [SDA112net2501](auth_userpass) username=6002 password= [SDA112net2501](aor_dynamic)
Re: Configuration asterisk
NoSpam a écrit : > Bonjour. Bonjour, > chan_sip est deprecated depuis longtemps et sera retiré avant la fin de > l'année. pjsip est son successeur, évolution obligatoire. > > J'ose espérer que tes ports 506/5061 UDP & TCP ne sont pas ouverts sur > Internet, avec ta configuration tu cours au massacre du porte monnaie si > ton trunk sortant est payant. Non, tout est fermé de ce côté (firewall + asterisk qui n'écoute que côté LAN). > Ce qu'il ne faut pas faire c'est donner des extensions numériques -à > cause des attaques brutes comme dit ci dessus- il faut faire dans sip.conf > > [userEnAlphaAvecDeLaCasseEtDuNumerique] > > definition du user et dans extensions.conf > > exten => 6001,1,Dial(SIP/userEnAlphaAvecDeLaCasseEtDuNumerique) > > Aussi ne PAS mélanger les appels entrants et sortants toujours à cause > des attaques. Fail2ban est ton ami pour se protéger Certes et puisqu'on en parle ;-) J'ai quelques problèmes d'incompréhension avec pjsip.conf. Considérons le fichier suivant : [6001](SDA112) auth=6001 aors=6001 [6001](auth_userpass) username=6001 password= [6001](aor_dynamic) [SDA112net2501](SDA112) auth=SDA112net2501 aors=SDA112net2501 [SDA112net2501](auth_userpass) username=6002 password= [SDA112net2501](aor_dynamic) Le téléphone 6001 arrive à s'authentifier. Pas SDA112net2501. Si je remplace SDA112net2501 par 6002, ça fonctionne. Dans l'autre sens, si j'écris : [SDA112net2531](SDA112) auth=6001 aors=6001 [6001](auth_userpass) username=6001 password= [6001](aor_dynamic) c'est le poste 6001 qui ne s'authentifie plus. Bien cordialement, JB
Re: Configuration asterisk
Bonjour.
chan_sip est deprecated depuis longtemps et sera retiré avant la fin de
l'année. pjsip est son successeur, évolution obligatoire.
J'ose espérer que tes ports 506/5061 UDP & TCP ne sont pas ouverts sur
Internet, avec ta configuration tu cours au massacre du porte monnaie si
ton trunk sortant est payant.
Ce qu'il ne faut pas faire c'est donner des extensions numériques -à
cause des attaques brutes comme dit ci dessus- il faut faire dans sip.conf
[userEnAlphaAvecDeLaCasseEtDuNumerique]
definition du user et dans extensions.conf
exten => 6001,1,Dial(SIP/userEnAlphaAvecDeLaCasseEtDuNumerique)
Aussi ne PAS mélanger les appels entrants et sortants toujours à cause des
attaques. Fail2ban est ton ami pour se protéger
Le 01/07/2023 à 12:02, BERTRAND Joël a écrit :
Bon, j'ai réussi à régler le coup des appels entrants. Le '.' et le '!'
ne peuvent pas être utilisés n'importe où et les regex sont un peu
tatillonnes.
Reste le problème des appels sortants :
[User-standard]
exten => 6001,1,Dial(SIP/6001)
exten => 6002,1,Dial(SIP/6002)
exten => _0.,1,Dial(SIP/${EXTEN:1})
retourne :
[Jul 1 12:00:13] WARNING[12569][C-0001] chan_sip.c: Purely numeric
hostname (0x), and not a peer--rejecting!
[Jul 1 12:00:13] NOTICE[12569][C-0001] app_dial.c: Unable to create
channel of type 'SIP' (cause 20 - Subscriber absent)
Re: Bookworm: missing sbin in root path?
On Sat, Jul 01, 2023 at 10:07:59PM -0400, Carl Fink wrote: > > On 7/1/23 21:38, Greg Wooledge wrote: > > On Sat, Jul 01, 2023 at 08:58:44PM -0400, Carl Fink wrote: > > > When I type "/usr/sbin/adduser", that works, but shouldn't root default to > > > having sbin in its path? > > You probably used su. > > [...] > Yes, I did use su. I had no idea that would cause a problem. > > Thanks for the pointer. I created /etc/default/su, which should > resolve this. > or using: su - This will include your environment for root -H -- Henning Follmann | hfollm...@itcfollmann.com
[NAS] Install Debian + paquet OMV ou directement avec l'iso OMV ?
Bonjour, J'ai un NAS avec OpenMediaVault , installée à partir de l'iso d'OMV. J'ai récemment découvert que l'on peut d'abord installer une Debian puis ajouter un paquet OMV. Un membre de la liste aurait-il un retour d'expérience sur une Debian modifiée OMV ? -- Frédéric ZULIAN
