PRECEDENTE SUCCESSIVO
(cyberflaz) Spesso può capitare quando hai picchi di connessioni SMTP o agenti particolarmente chiacchieroni che registrano un sacco di messaggi. Anche trascorsi i canonici sette giorni, oltre i quali avviene la rotazione, la dimensione del file non cala ma continua ad allocare la dimensione precedente. Il log.nsf è uno di quei database su cui non puoi fare manutenzione a caldo (compact o DBMT che sia). Un metodo semplice ma efficace è quello di spegnere Domino e lanciare da prompt un ncompact -c log.nsf
(Mj231) Ciao, ti lascio link ufficiale ibm : https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_8.5.3/com.ibm.help.domino.admin85.doc/H_CONTROLLING_THE_SIZE_OF_THE_LOG_FILE_LOGNSF_OVERVIEW.html Ciao,
(lrossetto) Buon giorno, nel server domino dell' azienda il file log.nsf ha superato quota 4,5GB...c'è un modo per ridurne la dimensione? Grazie. Luciano R.
(fmarzolo) Grazie ho risolto! Ho impostato NTS_DBPATH=pathDomino\Traveler\lib\sqljdbc42.jar
(Mj231) Ciao, prova a guardare nel notes.ini questo parametro : NTS_DBPATH=, che valore ha? Ciao!
(MircoT) non ha senso che un fixup risolva il problema di autorizzazione, per altro su un solo db.. c'è qualcosa di sbagliato sotto. andrebbe vista la conf pezzo per pezzo. quanto agli archivi vecchi: il link presente dentro alla posta apre quello indicato dalla policy, quindi quello nuovo. quelli vecchi vanno aperti a mano dal workspace di notes. sapendo che c'erano degli archivi locali (che andrebbero impediti da policy, in quanto, se il pc si rompe o lo rubano, perdo dei grossi pezzi di posta senza possibilità di recupero) bisognava mettere quegli archivi locali sul server in modo che poi la policy continuasse ad archiviare su quelli. bisognava incastrare un po' cose, ma si poteva fare. adesso devono rimanere separati, a meno che non si voglia copiare tutti i doc (cartella per cartella) dell'archivio locale sull'archivio sul server... una bella rottura.
(greghph) si ho riavviato il server poi ho provato a fare un fixup prima del compact -a su un DB ha funzionato....rimane il problema sempre su un altro db (tra quelli con la policy assegnata, e non vorrei avere lo stesso problema ad ogni db a cui assegno la policy ;-( ) altra domanda...mi son accorto che seguendo la procedura per l'archiviazione su server, se l'utente ha gia degli archivi "locali", quando tenta di aprirli, viene generato un errore di percorso file non trovato(infatti notes cerca di aprire il db dal percorso del server e non da quallo locale). il problema è risolvibile?
(MircoT) dopo aver modificato il doc del server, lo hai fatto ripartire? quelle son cose che legge raramente. o alla partenza del server. per altro il db di posta cifrato con l'id dell'utente non aiuta.
(greghph) niente da fare ancora errore
(greghph) Ciao MircoT si avevo dimenticato la S nel nome del gruppo ;-) ti rispondo alle tue domande l´archivazione come è impostata? (verso lo stesso server) il db di posta è cifrato con l´id dell´utente? (SI) nel doc del server/security c´è il gruppo localdomainservers nel campo degli autorizzati a creare nuovi db? (effettivamente mancava il gruppo localdomainservers nel campo Create databases & templates...riprovo e ti faccio sapere) Thx
(MircoT) localdomainserver[B]s[/B] l'archivazione come è impostata? verso lo stesso server? verso server diverso? il db di posta è cifrato con l'id dell'utente? nel doc del server/security c'è il gruppo localdomainservers nel campo degli autorizzati a creare nuovi db?
(greghph) ciao MircoT avevo gia controllato la presenza del LocalDoainServer nell ACL (UserType=Server Group; Access=Manager) ma mi segnala lo stesso l'errore e non mi archivia le email dal db di posta grazie
(MircoT) credo sia un errore "farlocco". controlla che nell'acl dei db ci sia il gruppo localdomainservers e sia manager gruppo di server. l'accesso full access non serve visto che con il comando da console è il server che esegue l'azione e non il tuo id.
(fmarzolo) Forse un po' tardiva come risposta, io ne ho fatto svariati senza problemi. Hai per caso modificato qualcosa nella configurazione? Hai un messaggio nella console alla partenza del task SMTP, oppure al tentativo di connessione con telnet (o putty) ?
(fmarzolo) Sono alle prese con questo messaggio di Traveler 9.0.1.18 in configurazione HADR con MS SQL Express. [00E8:00AB-11D4] 28/08/2017 11.27.16 Traveler: MS SQL Server JDBC driver version mismatch detected for Java 1.8.0. Remove JDBC driver D:\Lotus\domino\Traveler\lib\sqljdbc4.jar from system, reconfigure with correct JDBC driver and restart. For more information see technote: http://www.ibm.com/support/docview.wss?uid=swg21999188 [00E8:00AB-11D4] 28/08/2017 11.27.16 Traveler: The overall status of IBM Traveler is Red. il link proposto (Requirements for running IBM Traveler on Domino 9.0.1 FP8 and later releases) punta ad una pagina MS che consente il download del driver JDBC aggiornato con le relative istruzioni per l'installazione. Al termine si prende il driver "sqljdbc42.jar" e si mette in Domino\Traveler\lib. Occorre ricordarsi di cancellare il precedente driver "sqljdbc4.jar". Fatto l'aggiornamento però, il messaggio non se ne va. Qualcuno è gia passato in questa situazione?
(greghph) ciao ho seguito questa bellissima guida http://www.dominopoint.it/Dominopoint/dominopoint_blog.nsf/dx/2204200921.12.44CMEQJJ.htm per creare una policy di archiviazione ho assegnato la stessa ad alcuni utenti ma lanciando il comando lo compact -a mail\nomedb.nsf (singolarmente sui db con policy assegnata) su alcuni mi da l'errore di autorizzazione ho eseguito quindi l'accesso con full access administration ma niente...sempre su alcuni db segnala errore la cosa strana è che comunque nella dyr "archive" crea sia il db a_ che il file di log l_ la release è 9.0.1FP5 grazie
(LucaP) Boh a me il sistema più semplice sembra lavorare con le Rest generiche se notifica il cambio.
(simone81) Ciao, allora queste le ipotesi valutate per aprocciare il problema soluzione 1 : Utilizzare il DB Resource e reservation per leggere gli appuntamenti e creare/editare appuntamenti dall'esterno. NON FATTIBILE per via delle REST API, cioè il RRDB non espone le CalendarAPI. Lavorare solo con le DataService API è infattibile (non mi dilungo sui motivi) soluzione 2: Utilizzare uno SharedCalendar. Questo espone le Calendar API (è un DB di tipo mail calendar VERO). Le prenotazioni sarebbero create per conto del Chair che è l'utente a cui appartiene lo SharedCalendar. Io Simone creo un'appuntamento tramite SharedCalendar e il Chair non sono io. Viene riportato sul meeting Chair=utente Shared Calendar, sentby: Simone Quindi si, utilizzando una utenza adoc (associata allo shared calendar) avrei la possibilità di interventire sui meeting, leggerli, crearli, editarli etc... I problemi per la soluzione 2 sono: - gli utenti aziendali devono adattarsi ad un nuovo modo di prenotare gli appuntamenti, non creandoli dal loro calendario personale, ma dallo shared calendar (ho scoperto comunque che esiste un modo per fare uno shortcut del calendario sherato all'interno del calendario personale, in composizione l'utente deve fare New > Events for other Calendars > Calendario Condiviso. Bella possibilità, ma comunque una "novità" che non tutti potrebbero approvare) - Io Simone che sto prenotando tramite SharedCalendar devo ricordare di mettere me stesso tra i partecipanti del meeting. Altrimenti la credo per gli altri attendees ma non per me. Molto brutto - Io Simone che mi sono ricordato di mettermi tra gli invitati, ricevo comunque l'email dell'invito (certo!!! il Chair non sono io, è un altro!!!) e devo accettare l'appuntamento che io stesso ho creato. Bruttissimo!!! Ho provato a "giocare" con le delegations e gli automatismi di autoprocessing sullo shared calendar, ma non risolvo in nessun modo questo brutto scenario. Credo che valuteremo altre strade più "CUSTOM", abbandonando la possibilità di utilizzo delle REST...
(LucaP) IMHO se non hai un chair non puoi modificare. Secondo me se metti un utente fittizio come partecipante puoi proporre altre date ma il è il chair che decide. Non ho mai provato ma mi sorge qualche dubbio che anche su exchange o gmail [U]come utente normale[/U] si possano modificare le date di una riunione concordate da altri utenti al più possono proporre altre date. Anche usando le REST API sarebbe una incoerenza. Cmq qua c'è a descrizione dei campi e del processo https://www-10.lotus.com/ldd/ddwiki.nsf/dx/cs_schema_toc prova se modificando la risorsa i partecipanti vengono notificati che per domino è il modo corretto.
(simone81) "integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino". Sostanzialmente leggere e scrivere e creare reservations su risorse condivise (meeting room, attrezzatuture etc...). Lavorando con le REST API non riesco a lavorare con le Calendar API perchè non sono esposte sul contesto del DB Room&Reservations DB. Cercavo quindi vie alternative per ottenere ciò di cui ho bisogno. Grazie
(LucaP) Scusa ma hai spiegato come vuoi fare una cosa ma non hai detto cosa vuoi fare esattamente.
(simone81) Ciao Luca, credo tu abbia centrato l'argomento, ma purtroppo non mi basta per risolvere. Si è vero che dovrei lavorare sul calendario del Chair della reservation per riuscire a modificare un appuntamento, eliminarlo o crearne uno ex-novo. Però ovviamente non potrò mai avere accesso ai calendari di tutte le utenze interne all'azienda. Da quanto ricordo e per quanto mi stanno confermando anche in altre realtà aziendali, lo standard per gestire le risorse e le reservation è appunto il Resource Reservation Database. Ma questo RRDB purtroppo non espone le REST Calendar API e ho già visto che lavorare su questo DB con le DAS, manipolando i campi è un delirio. Ho fatto qualche prova e riesco anche ad editare o cancellare un appuntamento, ma non lavorando nel contesto di un vero e proprio Calendar DB con API non di tipo Calendar, mi vado a perdere tutti i meccanismi di Controllo disponibilità orari, notifiche agli utenti e quant'altro è insito all'interno di una vera applicazione Calendar. Io non vorrei integrarmi in questo modo e anche da alcune ricerche in rete ho visto che è decisamente sconsigliato. Se un cliente ha impostato la configurazione delle risorse tramite il Resource & Reservation DB è molto difficile convincerlo a cambiare configurazione. Una possibilità che sto valutando è mettere in piedi un DB che funga da Shared Calendar condiviso per la prenotazione delle risorse. Ho fatto un test in ambiente lab e funziona come concetto: creo uno Shared Calendar dal quale posso prenotare le risorse. Imposto eventualmente le Access Delegation su questo calendario condiviso. Con una utenza qualsiasi accedo allo shared calendar e effettuo una reservation per una risorsa. La reservation creata viene correttamente notificata agli attendees e va a finire all'interno del ResourseReservationDB. A questo punto però ho anche il calendario condiviso che mi contiene tutti gli appuntamenti e posso leggere e scrivere tramite REST Calendar API nel contesto di quel database. Il Chair dell'appuntamento però è lo Shared...
(LucaP) Premetto che non ho mai usato le REST API Per le calendar API dovrebbe funzionare come sul client o da Web, Quindi per creare/modificare/cancellare una reservation devi farlo modificando la riunione nel database di posta del Chair in questo modo tutti i partecipanti verranno aggiornati. In pratica ogni meeting ha un presidente e solo lui (o chi ha la delega sul suo Calendario) possono modificarlo con le relative notifiche ai partecipanti. Nella logica di Lotus non ha molto senso che una stanza modifichi una riunione dell'amministratore delegato. Se invece vuoi accedere al db delle reservation e manipolare gli oggetti in questo devi usare direttamente le DAS e sapere il significato dei campi (credo siano documentati) ovviamente sarà tuo compito notificare le modifiche ai partecipanti. Credo che per fare questo l'utente usato debba avere acceso editor al DB. Freebusy come dice il nome espone i dati di free e busy time dei partecipanti ma non server a manipolare la riunione. IMHO se fai questo "sto studiando un´integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino. " il modo corretto è mandare una mail formattata opportunamente al Chair che accetterà o declinerà oppure creare un utente fittizio che faccia da chair e da li mandare le proposte o le modifiche. http://www-01.ibm.com/support/docview.wss?uid=swg27009325
(simone81) Ciao a tutti DominoMans, sto studiando un'integrazione di un sistema esterno al sistema di reservations delle resources di un server Domino. A partire da Domino 9.0.1 ho scoperto di recente che IBM mette a disposizione delle API REST da abilitare sul server. Sono: - Data Services (gestisce in generale le operazioni sui documenti Notes) - Mail Services - [B]calendar Services[/B] - Core Services io mi sto concentrando sulle Calendar Services. In ambiente LAB ho configurato un Domino server con 3 utenze Demo e relativi DB di posta e calendario. 1 Utenza di Admin con relativo calendario/email Ho configurato le risorse creando un [B]Resource Reservation Database[/B]. Il template dal quale son partito è: StdR9ResourceReservation Quindi da client Notes con una utenza riesco a fare una reservation di una resource (diciamo una meeting room ad esempio). Questa reservation viene resa visibile all'interno di questo Resource e reservation Database. Quindi ho abilitato lato server e anche lato DB R&R i servizi necessari (Data Service e Calendar Service) e riesco quindi a esporre le API REST. Fin qui tutto bene. Ora però devo capire come e cosa effettivamente richiamare per ottenere ciò che desidero. Io ho bisogno ad esempio di creare nuove reserations dall'esterno a Domino e modificare reservation esistenti magari create da un utente interno a Domino (profilo aziendale). Qui la scoperta: [U]Il Resource Reservatin Database [B]NON ESPONE[/B] il Calendar Service[/U]. Se do autorizzazioni all'utente Admin con tutti i privilegi possibili sul DB, riesco correttamente ad autenticarmi chiamando la Data Service API, ma assolutamente non la Calendar API che non è esposta. Credo che la Calendar API sia solo disponibile nel contesto di un VERO mail-in database(calendar), come quello di un utente, e non per questo "atavico" Resource&Reservation DB. Come me la posso cavare? Su sistemi come Exchange o Gmail una risorsa è associata ad un vero e proprio indirizzo di posta e relativo calendario, quindi in maniera equivalente...
(LucaP) Come sarebbe a dire "load updall -R mail\names.nsf" Sei sicuro che i due server siano nello stesso dominio e non cross certificati ? Se non si fanno configurazioni particolare il names è nella root del server. Altra cosa come viene fatta la completion nelle due sedi ? se scrivi Magazzino F9 ti propone entrambi gli indirizzi ? Hai controllato che gli shortname non siano uguali ?
(Gianluca_Boff) Niente da fare, viste aggiornate, ma ho sempre lo stesso problema. Ho verificato dentro la names, ma non trovo doumenti in cui compare l'indirizzo magazzino@xxx.com
(MircoT) no, crea l'indice esteso dalle proprietà del db. non blocchi nulla.
(Gianluca_Boff) Giusto per non fare cose sbagliate, quindi lancio una load updall -R mail\names.nsf? Ma non rischio di bloccare il server, credi sia meglio che la lanci in pausa pranzo? Grazie
(MircoT) a questo punto indicizza il names.nsf e fai una ricerca per capire quali sono i doc con gli indirizzi giusti ed eventualmente i doc con l'indirizzo errato. cerca sui doc persona, sui gruppi, sui mailin-db, sui doc di dominio. potrebbe esserci qualcosa sul server di sede 1 che non viene replicato sul server di sede 2. a volte si incasinano le history di replica e qualcosa non passa.
(Gianluca_Boff) nel notes.ini ho solo NAMES=names.nsf, quindi direi che non ci sono rubriche concatenate.
PRECEDENTE SUCCESSIVO