In my case, /tftpboot is a symlink to /var/adm/CSCOpx/tftpboot. I'm using the Sol 10 tftpd that's shipped with LMS 3.1. I have /tftpboot as a symlink on other boxes that use Sun's tftpd working just fine. Am I reading it correctly that LMS 3.1 has problem with a symlinked /tftpboot?

lrwxrwxrwx 1 casuser casusers 24 Sep 29 10:55 tftpboot -> /var/adm/CSCOpx/tftpboot

drwxrwxrwt 2 root casusers 1024 Dec 17 12:46 /var/adm/CSCOpx/tftpboot

No, this is fine. Of course, there may be an issue with parent directory permissions, but I doubt it. Like I said, the dcmaservice.log should have more details.

I clicked "Sync Archive" under each device's Device Center page. It got the VLAN config retrieved for some, but it still fails for others. Here's one that failed at 16:10 yesterday:

GUI:

1. rtr1 PRIMARY STARTUP Dec 12 2008 05:40:32 Successful

2. rtr1 PRIMARY RUNNING Jan 05 2009 16:10:12 Successful

3. rtr1 VLAN RUNNING Dec 12 2008 05:41:20 Couldnot create file in /tftpboot directory. VLAN Config fetch is not supported using SCP. VLAN Config fetch is not supported using TFTP.

According to this, vlan.dat was successfully archived for rtr1 at Mon Jan 05 16:10:27 EST 2009. If the error happens again in the future, immediately collect the vlan.dat.

Then the curious part is the GUI doesn't reflect the VLAN collection status for this device, while it does for other devices through same steps.

You can enable ArchiveMgmt Service debugging, and collect the config again, but the log indicates that the latest vlan.dat is already archived.

according to the log (if it is not incomplete) and the GUI, the startup config was not updated nor was it checked if it has changed. I yet noticed that launching 'Sync Archive' from the devicve center does not sync the startup config. I would count it as a bug because this 'one-click' synchronisation is incomplete for the device and almost every customer thinks this click does synchronise both start-up and running config. It would also ease the process of removing 'out-of-sync' device if one would first check some detailed information for an out-of sync device through the device center and afterwards starting the sync job with this one-click job. It would be greate if this could be included in this job.

The startup config is not synced by default in an ad hoc job. You can, however, check the "Fetch Startup" box to have the running and startup configs fetched.

but the 'sync Archive' job from device center is more than just an adhoc job. It is really a *one-click* job. You do not have the option to check the 'Fetch Startup' box as with a regular adhoc job in 'Config Mgmt' where this can be done. So there must be a default template where all the selectable options for a sync archive job -if launched from Device Center- are preselected. And if this template would be enhanced so that the startup config would also be synced - it would really help very much. I think it is the sense behind the device center to have these 'fast tasks'...

I didn't see "device center". Yes, Device Center's Sync Archive job uses the default "All Running" mode when fetching configs. Changing it would be easy, but it would violate the Principle of Least Astonishment, and could upset some users (who expect only the running configs to be archived).

You are right it could upset some users if it would be changed. I see this point but as I have never spoken to a customer that did not want to have both configs archived if he manually starts a sync job from this launch point I thought it would be helpful.

Can you imaging a scenario where only the running config should be archived and explicitly not the startup?

The main advantage to not fetching the startup config is saving network bandwidth. In a scenario where config changes may be tested in running config before a save is done, I could see that savings being useful. However, this is probably a corner case.

Another corner case is the lack of a hit on the device. Not fetching startup saves an NVRAM read. If you consider the scenario where NVRAM reads could lead to a crash (e.g. corruption), having only the running config fetched is a good thing.

But the biggest argument is POLA. These are the kind of issues PERS were made for. Perhaps a compromise would be to add a new Device Center task:

Sync Running Config

Sync All Configs

I see, these are indeed arguments not to change the current behaviour. But I do not like PERS - it's like putting something on its way but have no means of getting clear information what happens with it.

Instead the idea of a new Device Center task is really good! Can you add this to the list of internal wishes and needs for LMS?(I hope this list exists !!:-) ) - or must it reuested by a customer?