HECnet

hecnet@lists.dfupdate.se

7 participants
15595 discussions

by wonko＠4amlunch.net

Ok, I got my main server rebuilt and so it's time to run some simh for testing (particularly the new user mode routing stuff). However, I'm still fighting this: wonko at zaphod$ BIN/vax VAX simulator V3.9-0 sim> set cpu idle Command not allowed sim> set cpu idle=VAX Invalid argument sim> I'd really like for IDLE to work so I can run several copies of simh without nuking my CPUs. Thoughts? wonko at zaphod$ uname -a SunOS zaphod 5.11 oi_151a5 i86pc i386 i86pc Solaris -brian

13 years, 6 months

LEGATO down today

by bob＠jfcl.com

LEGATO will be down for a few hours today while I move some stuff around. It ll be back this afternoon (California time, that is). Bob

13 years, 6 months

Understanding Default Accounts

by jg＠jordi.guillaumes.name

IIRC object-specific default accounts (for FAL, PHONE and so on) appeared in version 5.0. In previous versions the setup command procedure just asked for the DECNET account. Jordi Guillaumes i Pons Barcelona - Catalunya - Europa El 15/09/2012, a les 21:00, Peter Coghlan <HECNET at beyondthepale.ie> va escriure: I don't have a good understanding of default accounts when using NETCONFIG. I would like to allow people to list files in a specific directory (DIR NODE::), PHONE me and MAIL me. Does this mean I need to specify default accounts for FAL, MAIL and PHONE? If so, what is the purpose of the "Default DECnet account", which is the first of the questions in the sequence below: My understanding of it (which might not be correct) is that the default FAL account is used if someone remote does not specify a username and password when doing a file access on your machine, the default PHONE account is used when someone remote PHONEs your machine without specifying a username and password and the default MAIL account is used when someone remotely sends MAIL-11 mail to your machine without specifying a username and password (Is it even possible to specify a username and password with PHONE and MAIL?) So for example, files which FAL$SERVER has rights to access will be made available to anyone who remotely tries to access them without their having to specify a valid username and password on your machine. If no username and password is specified by someone attempting to access anything remotely on your machine and no suitable default account is available for the activity in question, the default DECnet account will then be used if available. Therefore (I think) the default DECnet account is a catchall and if you have one, you are granting anyone remote from your machine, some level of access to all DECnet services on your machine. I can't see any real use for it except for people who are too lazy to set up the other few default accounts that they really want which offer finer control over what services are made available remotely. I seem to remember default DECnet accounts going out of favour and being regarded as a security risk. (In addition to default accounts, default proxies also come into play here but I thought it better not to further complicate things by mentioning them...) Regards, Peter Coghlan.

13 years, 6 months

Understanding Default Accounts

by HECNET＠beyondthepale.ie

I don't have a good understanding of default accounts when using NETCONFIG. I would like to allow people to list files in a specific directory (DIR NODE::), PHONE me and MAIL me. Does this mean I need to specify default accounts for FAL, MAIL and PHONE? If so, what is the purpose of the "Default DECnet account", which is the first of the questions in the sequence below: My understanding of it (which might not be correct) is that the default FAL account is used if someone remote does not specify a username and password when doing a file access on your machine, the default PHONE account is used when someone remote PHONEs your machine without specifying a username and password and the default MAIL account is used when someone remotely sends MAIL-11 mail to your machine without specifying a username and password (Is it even possible to specify a username and password with PHONE and MAIL?) So for example, files which FAL$SERVER has rights to access will be made available to anyone who remotely tries to access them without their having to specify a valid username and password on your machine. If no username and password is specified by someone attempting to access anything remotely on your machine and no suitable default account is available for the activity in question, the default DECnet account will then be used if available. Therefore (I think) the default DECnet account is a catchall and if you have one, you are granting anyone remote from your machine, some level of access to all DECnet services on your machine. I can't see any real use for it except for people who are too lazy to set up the other few default accounts that they really want which offer finer control over what services are made available remotely. I seem to remember default DECnet accounts going out of favour and being regarded as a security risk. (In addition to default accounts, default proxies also come into play here but I thought it better not to further complicate things by mentioning them...) Regards, Peter Coghlan.

13 years, 6 months

Understanding Default Accounts

by robert.jarratt＠ntlworld.com

I don t have a good understanding of default accounts when using NETCONFIG. I would like to allow people to list files in a specific directory (DIR NODE::), PHONE me and MAIL me. Does this mean I need to specify default accounts for FAL, MAIL and PHONE? If so, what is the purpose of the Default DECnet account , which is the first of the questions in the sequence below: Do you want a default DECnet account? [NO]: yes Do you want default access to the TASK object disabled? [YES]: Do you want a default account for the MAIL object? [YES]: Do you want a default account for the FAL object? [NO]: yes Do you want a default account for the PHONE object? [YES]: Do you want a default account for the NML object? [YES]: Regards Rob

13 years, 6 months

Second Alpha Release of User Mode DECnet Router

by robert.jarratt＠ntlworld.com

And the link is https://route20.codeplex.com/ From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt Sent: 15 September 2012 08:11 To: hecnet at update.uu.se Subject: [HECnet] Second Alpha Release of User Mode DECnet Router This second alpha release fixes some bugs and limitations. It has been tested in two DECnet areas and seems to be stable enough for more extensive testing. Interested in any and all feedback. Regards Rob

13 years, 6 months

Second Alpha Release of User Mode DECnet Router

by robert.jarratt＠ntlworld.com

This second alpha release fixes some bugs and limitations. It has been tested in two DECnet areas and seems to be stable enough for more extensive testing. Interested in any and all feedback. Regards Rob

13 years, 6 months

Help with VMS decnet configuration please

by mark＠wickensonline.co.uk

On 14/09/12 21:29, John H. Reinhardt wrote: On 9/14/12 3:51 PM, Mark Wickens wrote: On 14/09/12 20:37, Dennis Boone wrote: > so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm > getting errors when attempting to reach out over the ethernet. I know > the physical network connection is OK because tcpip is working fine. Wasn't there something about starting DECnet first? Try rebooting again now that the reconfig is done. De Well, I never thought this would fix a VMS issue, but rebooting it solved the problem. Sorry for wasting your bandwidth ;) Thanks for the help!!! Mark. As Dave says, DECnet needs to change the MAC address on the network interface. If you booted and TCP/IP came up and then you fiddled with and started DECnet, the MAC address was already locked in by TCP And DECnet wasn't able to change it. The rebooting allowed things to happen in the proper order. Technically, you could have stopped TCP and then started DECnet and then re-started TCP and it probably would have worked - unless the sysgen parameters were needed and then only the reboot would have done it. John H. Reinhardt Yes, of course that makes total sense. It's been a while since I did anything with DECnet, as I say, all this stuff slowly dribbles out of my brain... Cheers, Mark.

13 years, 6 months

Help with VMS decnet configuration please

by Paul_Koning＠Dell.com

On Sep 14, 2012, at 4:19 PM, Dave McGuire wrote: On 09/14/2012 03:37 PM, Dennis Boone wrote: so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm getting errors when attempting to reach out over the ethernet. I know the physical network connection is OK because tcpip is working fine. Wasn't there something about starting DECnet first? Try rebooting again now that the reconfig is done. Starting DECnet changes the MAC address of the interface...could it have been an ordering dependency there? -Dave That's definitely a dependency, unless you have a type of interface that supports multiple MAC addresses. The early ones (UNA and Lance) do not. QNA does, LQA emulates that but doesn't really want to. Tulip and later DEC-designed Ethernet adapters (and the FDDI adapters, for those of you that have one) all support multiple MAC addresses, because it was written into the DEC Ethernet architecture specification as a requirement. paul

13 years, 6 months

Help with VMS decnet configuration please

by johnhreinhardt＠yahoo.com

On 9/14/12 3:51 PM, Mark Wickens wrote: On 14/09/12 20:37, Dennis Boone wrote: > so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm > getting errors when attempting to reach out over the ethernet. I know > the physical network connection is OK because tcpip is working fine. Wasn't there something about starting DECnet first? Try rebooting again now that the reconfig is done. De Well, I never thought this would fix a VMS issue, but rebooting it solved the problem. Sorry for wasting your bandwidth ;) Thanks for the help!!! Mark. As Dave says, DECnet needs to change the MAC address on the network interface. If you booted and TCP/IP came up and then you fiddled with and started DECnet, the MAC address was already locked in by TCP And DECnet wasn't able to change it. The rebooting allowed things to happen in the proper order. Technically, you could have stopped TCP and then started DECnet and then re-started TCP and it probably would have worked - unless the sysgen parameters were needed and then only the reboot would have done it. John H. Reinhardt

13 years, 6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet