Når du integrerer Elastic Agent i et eksisterende policy, skjer flere viktige prosesser i bakgrunnen som bidrar til effektiv og pålitelig datainnsamling. Elastic Agent fungerer som et kommunikasjonspunkt mellom policyen og de tilkoblede agentene, som kan sammenlignes med et satellittsystem som jevnlig sjekker inn med sin bakkestasjon. Denne hyppige kommunikasjonen gjør det mulig for agenten å holde seg oppdatert med eventuelle endringer i policyen som blir tildelt. Når policyen modifiseres ved å legge til en ny integrasjon, vil Fleet Server hente den oppdaterte policyen og distribuere den til alle tilkoblede agenter. Denne tilnærmingen med Elastic Agent skaper et mer sammenhengende og effektivt system for datainnsamling og administrasjon, noe som reduserer kompleksitet og forbedrer både ytelsen og sikkerheten i en Elastic Stack-installasjon.
Men implementering av Elastic Agent går utover bare å legge til en ny integrasjon i en eksisterende policy. Det er mange flere administrasjonsmuligheter som kan utføres via Fleet-applikasjonen. Blant de avanserte alternativene som ikke er dekket i denne oppskriften, finner vi muligheten til å legge til Elastic Agent-prosessorer for å redusere antallet felter eller berike de innsamlede hendelsene med ekstra metadata. Bruken av tagger for å merke hendelser mens de blir indeksert i Elasticsearch gir ytterligere fleksibilitet og tilpasning på toppen av den forenklede oppstartsprosessen som Elastic Agent og integrasjonene gir.
Det finnes også en annen tilnærming for avanserte brukere som ønsker mer kontroll: distribusjon av Elastic Agent i fristående modus. Dette kan være et alternativ når man ønsker å konfigurere og administrere oppgraderinger manuelt. Denne tilnærmingen gir større fleksibilitet, men på bekostning av høyere operasjonelt arbeidsbelastning.
For å begynne å implementere Elastic Agent i fristående modus, kreves det en virtuell maskin (VM). Det er viktig å merke seg at Elastic anbefaler å bruke Fleet-håndterte agenter der det er mulig, da fristående Elastic Agent innebærer mer administrasjonsarbeid. Men for brukere som ønsker å ha full kontroll over agentens konfigurasjon og drift, kan fristående distribusjon være det riktige valget.
For å installere Elastic Agent i fristående modus, må du følge en rekke trinn. Først oppretter du en policy for den fristående agenten. Deretter laster du ned og konfigurerer policyen, som kan inneholde spesifikke integrasjoner som Apache HTTP Server. Når policyen er konfigurert, blir den kopiert til vertsmaskinen, og du kan deretter laste ned og installere agenten manuelt. Etter installasjonen starter agenten, og du kan bekrefte at data sendes korrekt til Elasticsearch via Kibana.
Når Elastic Agent kjører i fristående modus, fungerer det på samme måte som Beats. Det er ingen Fleet-registrering, og agenten trenger bare autentiseringsmekanismer og legitimasjon for å sende data til Elasticsearch. Denne tilnærmingen gir mer kontroll over agentens innstillinger, men det er viktig å være oppmerksom på at fristående modus ikke støtter den sentraliserte policyhåndteringen og oppdateringene som Fleet gir.
Fristående modus er ideell for mindre eller mer spesialiserte miljøer hvor sentralisert administrasjon ikke er nødvendig. Imidlertid mangler det skalerbarheten og den enkle administrasjonen som Fleet tilbyr. Fleet gir en strømlinjeformet, sentralisert plattform for å administrere og oppdatere agenter på tvers av et stort og variert miljø, noe som forbedrer den operasjonelle effektiviteten og konsistensen. Dette innebærer imidlertid en økt kompleksitet og overhead når det gjelder oppsett og vedlikehold av Fleet Server, noe som kan være unødvendig i enklere oppsett.
I fristående modus er det også flere fordeler. Ved å bruke Kibana til å generere konfigurasjonen for agenten, får du automatisk satt opp integrasjonene som trengs, uten å måtte installere dem manuelt. Denne funksjonaliteten gjør fristående modus mer attraktivt for brukere som trenger høy grad av kontroll over sine agenter og systemer, men som ikke nødvendigvis har behov for den sentraliserte administrasjonen som Fleet gir.
Selv om fristående distribusjon gir mer frihet, krever den også at brukeren har god forståelse av hvordan agentene opererer og hvordan man håndterer autentisering, oppdateringer og vedlikehold på egenhånd. Fleet, på den annen side, gir et mer brukervennlig og sentralisert alternativ som kan redusere kompleksiteten for større distribusjoner. Å velge mellom de to tilnærmingene avhenger derfor av spesifikke behov, skalerbarhet og hvor mye administrasjon man er villig til å påta seg.
Hvordan lage visualiseringer med Kibana Lens i Elastic Stack 8.x
Kibana Lens har blitt et av de mest intuitive verktøyene for datavisualisering innen Elastic Stack, og tilbyr en enkel og brukervennlig måte å lage kraftige visualiseringer på, selv uten dyptgående analyseferdigheter. Når du begynner å lage visualiseringer i Kibana Lens, vil du møte på et standardgrensesnitt som gir deg enkel tilgang til en rekke verktøy og funksjoner. Dette grensesnittet kan deles inn i flere hovedkomponenter, som gjør det lettere å navigere og bygge visualiseringer steg for steg.
På venstre side av grensesnittet kan du velge en "data view", som representerer en eller flere indekser i Elasticsearch. Dette trinnet er avgjørende, da det er dataene bak den valgte visningen som vil være synlige under visualiseringen. Rett under denne dropdown-menyen finnes en liste over feltene som er tilgjengelige i dataene. For praktisk skyld viser Kibana Lens kun de feltene som faktisk inneholder data, og du kan raskt søke etter spesifikke felter eller gruppere dem etter type.
I sentrum av grensesnittet finner du arbeidsområdet hvor visualiseringen din vil vises. Her kan du bruke dra-og-slipp-funksjonen for å begynne å visualisere et valgt felt. Når du har plassert et felt i arbeidsområdet, kan du raskt endre diagramtypen for å se hvordan dataene kan presenteres på forskjellige måter. På høyre side finner du "Layer pane" som gir deg kontrollen over visualiseringens detaljer, inkludert hvordan hvert lag skal konfigureres.
En annen nyttig funksjon er "Formula"-verktøyet, som lar deg bruke matematiske funksjoner og aggregeringer i visualiseringene. Du kan for eksempel lage en linjediagram som sammenligner gjennomsnittlig kjøretøyhastighet fra uke til uke, sortert etter trafikkstatus, ved å bruke en formel med funksjonen for percentil og en shift-parameter. Dette gjør det mulig å lage mer komplekse visualiseringer som gir dypere innsikt i datatrendene.
Kibana Lens har også en "Sampling"-funksjon som kan forbedre lastetiden for visualiseringene. Denne funksjonen er basert på en tilfeldig samplingsmetode som reduserer antallet dokumenter som brukes i aggregasjonen, noe som kan være spesielt nyttig når du arbeider med store datamengder. Du kan justere samplingsraten i laginnstillingene for hver visualisering.
En annen imponerende funksjon er annoteringer. Denne funksjonen lar deg fremheve spesifikke datapunkter som kan ha spesiell betydning, som for eksempel bemerkelsesverdige endringer i dataene. Du kan opprette annoteringer basert på statiske datoer eller bruke en tilpasset spørring. Et typisk eksempel kan være å markere tidspunktet når motorveien er tett trafikkert (f.eks. når maks hastighet er 110 km/t), og vise dette med en nummerert linje i visualiseringen.
En annen viktig mulighet i Kibana Lens er muligheten til å bruke runtime-felt. Runtime-felt gir deg muligheten til å berike indeksskjemaet ditt dynamisk, uten å måtte endre de opprinnelige datakildene. Dette gjør det mulig å lage felter som for eksempel representerer timer på dagen eller ukedager, og bruke dem i visualiseringene dine. Ved å bruke runtime-felt kan du lage mer fleksible visualiseringer som kan tilpasses etter behovene i analysene dine.
En vanlig bruk av runtime-felt kan være å sammenligne trafikkstatus på hverdager versus helger eller mellom rushtrafikk og nattetimer. Ved å lage et runtime-felt som representerer timen på dagen, kan du deretter lage visualiseringer som viser hvordan trafikkstatusen fordeler seg i løpet av ulike tidspunkter på døgnet. Denne prosessen involverer å definere et runtime-felt som beregner timeverdien for hvert dokument, og deretter bruke dette feltet i visualiseringen.
Kibana Lens gjør det også mulig å utføre spørringer direkte fra visualiseringene, og tilbyr et svært intuitivt grensesnitt for å filtrere og justere dataene på en enkel måte. Spørringsfeltet lar deg lage tilpassede filtre som kan brukes for å skreddersy visualiseringen til de spesifikke behovene i analysen.
Det er viktig å merke seg at Kibana Lens har blitt det anbefalte verktøyet for visualiseringer i Elastic Stack, da tidligere verktøy som Time Series Visual Builder (TSVB) nå er avviklet i versjon 8.x. Derfor bør brukere som har arbeidet med TSVB-vizualiseringer i eldre versjoner vurdere å migrere til Kibana Lens for å få tilgang til de nyeste funksjonene og forbedringene.
Det er også essensielt for brukere å være oppmerksomme på hvordan visualiseringene kan forbedres ved å bruke de tilgjengelige funksjonene som Formel, Sampling og Annotering. Dette gir ikke bare en mer effektiv visualisering, men også en mer presis og dyptgående analyse.
Når du lager visualiseringer med Kibana Lens, er det viktig å forstå at du ikke bare jobber med data i et statisk format. Lens gir deg verktøyene til å kontinuerlig justere og tilpasse visualiseringene etter hvert som du får dypere innsikt i dataene, og gir deg muligheten til å dele disse innsiktene på en effektiv og forståelig måte med andre.
Hvordan sette opp og administrere Elastic Stack i ulike miljøer
Elastic Stack tilbyr en fleksibel og kraftig plattform for datahåndtering og analyse, som kan implementeres både på Elastic Cloud, on-premises eller i et hybridoppsett. Denne teksten beskriver hvordan man setter opp og administrerer Elastic Stack i forskjellige miljøer, inkludert på en vertstjeneste som Elastic Cloud, Kubernetes-infrastruktur og selvadministrerte løsninger.
Elastic Stack består av flere nøkkelkomponenter som Elasticsearch, Kibana, Fleet Server og Integrations Server, hver med sine spesifikke roller. En korrekt distribusjon og konfigurasjon av disse komponentene er avgjørende for effektiv drift og administrasjon av systemet.
For å velge den beste distribusjonsmetoden for dine behov, er det viktig å vurdere flere faktorer, som skalerbarhet, administrasjon, og sikkerhet. En sammenligning av de ulike distribusjonsmetodene kan hjelpe deg å ta en informert beslutning om hvilken som passer best til ditt prosjekt.
Distribuere Elastic Stack på Elastic Cloud
Elastic Cloud er den enkleste måten å implementere og administrere Elastic Stack. Med Elastic Cloud kan du raskt sette opp Elasticsearch, Kibana og Integrations Server uten behov for komplisert administrasjon eller infrastruktur. Etter å ha opprettet en konto og logget inn, kan du velge blant flere alternativer som passer dine behov: valg av skytilbyder (Google Cloud, AWS, eller Azure), region, og hardwareprofil. Denne enkle prosessen gjør Elastic Cloud til et ideelt valg for de som ønsker raskt å komme i gang med Elastic Stack.
Ved opprettelsen av en ny distribusjon i Elastic Cloud, opprettes automatisk flere viktige noder: Elasticsearch-noder, Kibana, Integrations Server og Enterprise Search, som alle har forhåndsdefinerte ressursallokeringer (som RAM og CPU). Dette gir deg et raskt utgangspunkt for å begynne å bruke og tilpasse Elastic Stack til dine spesifikke behov. En av de store fordelene med Elastic Cloud er muligheten til å justere ressursene etter behov, som å skalere opp eller ned etter trafikkbehov.
Hvordan administrere distribusjonen
Når du har opprettet en distribusjon på Elastic Cloud, er det flere muligheter for administrasjon og konfigurering. Du kan skalere eller auto-skalere distribusjonen basert på vekstbehov. I tillegg kan du legge til eller fjerne noder, endre nodetype, justere ressursene og sette opp datatilførsel via verktøy som Beats og Elastic Agent. En annen viktig funksjon er muligheten til å sette opp datalag (data tiering), som hjelper med å organisere data i ulike lag basert på hvor ofte de blir brukt. Dette forbedrer både ytelsen og kostnadseffektiviteten.
Etter at distribusjonen er satt opp, kan du overvåke helsen til systemet, ta sikkerhetskopier av dataene dine og sette opp en repositorium for snapshotter. Å ha en god strategi for backup og overvåkning er viktig for å sikre kontinuerlig drift og for å minimere risikoen for datatap.
Sikkerhet og tilgangskontroll
Sikkerhet er en kritisk faktor ved enhver distribusjon av Elastic Stack. Elastic Cloud tilbyr flere alternativer for å sikre tilgangen til systemet, inkludert autentisering via brukernavn og passord, eller enkeltlogg (SSO). Du kan også sette opp rollebasert tilgangskontroll (RBAC), som gir deg muligheten til å definere brukerroller og tilganger på en granular måte.
I tillegg kan du bruke trafikkfiltre for å beskytte mot uautorisert tilgang og for å sikre at kommunikasjonen mellom komponentene er kryptert og autentisert. Det er viktig å konfigurere disse sikkerhetsinnstillingene nøye for å beskytte både dataene og infrastrukturen.
Distribuere Elastic Stack med ECK (Elastic Cloud on Kubernetes)
Elastic Cloud on Kubernetes (ECK) gir deg muligheten til å distribuere og administrere Elastic Stack på Kubernetes, enten det er på en skyplattform eller on-premises. ECK automatiserer distribusjonen og administrasjonen av Elasticsearch, Kibana, Fleet Server og Integrations Server, og gir samtidig muligheten til å bruke Kubernetes-verktøy for overvåkning og skalering.
For å bruke ECK, må du først installere ECK-operatøren i Kubernetes-klyngen din. Dette krever at du har en Kubernetes-klynge, som kan være basert på Minikube, Google Kubernetes Engine (GKE), eller andre distribusjoner som Amazon EKS og Azure AKS. Etter installasjonen kan du bruke ECK til å sette opp og administrere Elasticsearch-klynger, Kibana og andre nødvendige komponenter. En av de store fordelene med ECK er muligheten til å dra nytte av Kubernetes’ innebygde funksjoner for skalerbarhet, høy tilgjengelighet og rullende oppdateringer.
ECK støtter også ulike lagringsarkitekturer, som "hot-warm-cold" lagring, hvor dataene organiseres etter hyppigheten av tilgangen deres. Denne arkitekturen hjelper med å optimalisere ytelsen og redusere lagringskostnadene.
Ekstra hensyn for distribusjonene
Når du setter opp en distribusjon av Elastic Stack, er det viktig å ta hensyn til den langsiktige skalerbarheten og vedlikeholdet. Uansett hvilken distribusjonsmetode du velger, er det viktig å forstå hvordan ressursene skal administreres over tid, spesielt når datamengden vokser. Å ha en klar strategi for oppdatering og oppskalering av systemet vil bidra til å unngå flaskehalser og nedetid.
I tillegg er det viktig å sette opp overvåkning av hele infrastrukturen for å kunne oppdage potensielle problemer tidlig. Dette kan omfatte overvåkning av systemressurser, som CPU, minnebruk og lagringskapasitet, samt applikasjonsnivåmetrikker som responstider og feilrate.
En annen viktig faktor er opplæring av teamet ditt i bruk og administrasjon av Elastic Stack. Selv om plattformen tilbyr mange automatiserte verktøy, krever det fortsatt en viss grad av ekspertise for å utnytte alle funksjonene på en effektiv måte. Å ha et dedikert team som kan administrere Elastic Stack kan gjøre en stor forskjell når det gjelder å sikre at systemet fungerer optimalt.
Hvordan bygge en klassifikasjonsmodell ved hjelp av dataanalyse
I prosessen med å bygge en klassifikasjonsmodell for trafikkdata er det viktig å nøye definere de variablene og parameterne som vil drive analysen. Når du har opprettet et datasett ved hjelp av en transformasjon, er det første steget å bruke en dataramme for klassifikasjon. I konfigurasjonen velger du "Classification" som jobbtype, og du begynner med å definere den avhengige variabelen, som i dette tilfellet er top_metrics.traffic_status. Denne variabelen representerer det utfallet modellen skal forutsi, basert på de ulike inngangsdataene.
Når du har valgt de relevante feltene som skal inngå i analysen, er det viktig å begrense datamengden til de mest nødvendige for å forbedre modellens prediktive evner. Dette kan inkludere variabler som day_of_week, hour_of_day, location_reference og max_speed.max, mens du for eksempel utelater traveltime.duration. Dette gjør at modellen fokuserer på de mest signifikante dataene, og kan dermed trene raskere og mer presist.
En annen viktig vurdering er hvilken prosentandel av datasettet som skal brukes til opplæring av modellen. I tilfellet med klassifikasjon er det vanlig å bruke en mindre prosentandel, for eksempel 20%, for å fremskynde prosessen. Klassifikasjonsanalyser kan ta lengre tid å fullføre enn regresjonsanalyser, og ved å bruke en mindre del av dataene til trening kan man balansere hastighet og nøyaktighet. Som alltid bør prosentandelen justeres etter behov basert på spesifikke krav og tilgjengelig datamengde.
I tillegg til konfigurasjonene som omhandler den avhengige variabelen og treningsdataene, kan du justere innstillingene for funksjonsviktighet (feature importance). Denne verdien indikerer hvilke datafelter som har størst innvirkning på modellens prediksjoner. Det er viktig å forstå hvilke funksjoner som påvirker modellen mest, da dette gir innsikt i hvilke faktorer som driver de trafikkrelaterte resultatene. Dette kan også brukes til å finjustere modellen senere for bedre ytelse.
Etter at du har konfigurert og kjørt klassifikasjonsjobben, vil du bli presentert med en rekke resultater i en resultatsvisning. Denne visningen er delt opp i flere seksjoner, inkludert analyseinnstillinger, modellvurdering, et scatterplot-matrise og en tabell som viser de faktiske resultatene. Modellvurderingsseksjonen gir en grundig gjennomgang av nøkkelmetrikker som nøyaktighet, presisjon, tilbakekalling (recall) og F1-score. Disse målingene er essensielle for å vurdere hvor godt modellen klarer å klassifisere dataene, og de gir innsikt i modellens ytelse.
En av de mest nyttige delene av modellvurderingen er den normaliserte forvirringsmatrisen (confusion matrix). Denne matrisen sammenligner de faktiske klassene med de predikerte klassene, og viser resultatene i form av sanne positive, sanne negative, falske positive og falske negative. En normalisert forvirringsmatrise presenterer disse verdiene som prosentandeler, noe som gjør det lettere å sammenligne resultatene på tvers av datasett med ulik størrelse. Denne visualiseringen er særlig nyttig når man arbeider med ubalanserte datasett.
I tillegg til forvirringsmatrisen er ROC-kurven (Receiver Operating Characteristic) en annen viktig måling. ROC-kurven viser hvordan modellen presterer når beslutningsterskelen for klassifikasjonen endres. AUC (Area Under Curve) gir et mål på hvor godt modellen kan skille mellom de to klassene, der en AUC på 1 representerer en perfekt klassifikator, mens en AUC på 0,5 indikerer at modellen ikke har noe diskriminerende evne, omtrent som tilfeldig gjetning.
Når det gjelder funksjonsviktighet, er det viktig å forstå hvilke variabler som har størst innvirkning på modellens prediksjoner. For vårt eksempel, der vi benyttet feltene hour_of_day, location_reference og andre, viste det seg at hour_of_day hadde den mest signifikante innvirkningen. Dette gir innsikt i at tidspunktet på dagen kan være en viktig faktor for trafikkforholdene som modellen skal klassifisere.
Til slutt, i resultatseksjonen, blir de faktiske dokumentene og klassifiseringene vist i en tabell. Dette gir deg en detaljert oversikt over de predikerte trafikkstatusene og hvordan de sammenlignes med de faktiske statusene. Dette gir verdifull informasjon om hvor godt modellen har klart å forutsi de riktige klassene, og kan hjelpe til med å identifisere eventuelle områder som trenger forbedring.
Ved å forstå og bruke disse verktøyene kan du bygge en robust klassifikasjonsmodell som kan forutsi trafikkstatus basert på historiske data. Det er viktig å kontinuerlig evaluere modellens ytelse og gjøre nødvendige justeringer for å forbedre nøyaktigheten. Gjennom iterativ testing og tuning kan du gradvis optimalisere modellen for bedre resultater.
Hvordan sette opp Single Sign-On (SSO) med OpenID Connect i Elastic Stack ved bruk av Okta
Konfigurasjonen av Single Sign-On (SSO) i Elastic Stack med OpenID Connect (OIDC) gir en kraftfull og sikker måte å håndtere brukerautentisering og tilgangsstyring på. Prosessen krever forberedelser og nøyaktig innlegging av informasjon, spesielt når det gjelder integrasjonen med en identitetsleverandør som Okta. Første steg er å hente URL-en til Kibana, som finnes i Elastic Cloud-konsollen under administrasjon av distribusjonen. Denne URL-en vil benyttes som basis for redirect-URI-er i SSO-konfigurasjonen.
Deretter må en Okta-utviklerkonto opprettes, noe som gir tilgang til Workforce Identity Cloud uten kostnad. Etter registrering og pålogging, må man kopiere Okta-domenet, som fungerer som issuer-URL i OIDC-konfigurasjonen. Med disse grunnleggende komponentene på plass kan man begynne å bygge applikasjonsintegrasjonen i Okta.
Opprettelsen av app-integrasjonen i Okta gjøres ved å velge OIDC som signeringsmetode og Web Application som applikasjonstype. Under konfigureringen må man angi et navn, for eksempel "Kibana Cookbook", og definere grant type som "Authorization Code". Videre legges redirect-URI-er til for innlogging og utlogging, og synlighet for applikasjonsikon settes for brukervennlighet. Det er viktig å lagre klient-ID og klienthemmelighet, da disse skal brukes i Elasticsearch sin sikkerhetsinnstilling senere.
Videre i Okta konfigureres hvordan gruppetilhørigheter filtreres i tokenet. Ved å endre gruppekravet til en regex som matcher alle grupper, sikrer man at relevante gruppe- og rolleopplysninger overføres. Dette muliggjør detaljert tilgangsstyring basert på brukerens gruppe-medlemskap.
Opprettelsen av grupper i Okta er sentral for tilganger. En ny gruppe, for eksempel "Elastic Group", opprettes og brukere legges til. Applikasjonen kobles til denne gruppen, noe som sikrer at kun autoriserte brukere får tilgang til Kibana gjennom SSO.
På Elastic Cloud-siden må klienthemmeligheten legges inn i keystore under sikkerhetsinnstillinger. Deretter oppdateres Elasticsearch-konfigurasjonen med riktige OIDC-verdier hentet fra Okta, inkludert klient-ID, issuer-URL, og diverse endepunkter for autorisasjon, token og brukerinfo. Disse parametrene etablerer tilliten mellom Elastic Stack og Okta som identitetsleverandør.
Det er essensielt å forstå at gruppekrav i OIDC-token fungerer som nøkkelen til finmasket autorisasjon. De gir mulighet til å differensiere rettigheter i Kibana basert på brukerens rolle i organisasjonen, noe som er avgjørende for sikkerhet og effektiv administrasjon i større miljøer. Riktig håndtering av redirect-URI-er og klienthemmeligheter sikrer at autentiseringsflyten er trygg og at kun autoriserte applikasjoner kan kommunisere med Okta.
Det bør også understrekes at denne prosessen, selv om den kan virke kompleks, er i stor grad repetitiv og velstrukturert. Ved å følge stegene nøye og verifisere alle opplysninger, kan man etablere en robust SSO-løsning som gir en sømløs brukeropplevelse og styrker sikkerheten i hele Elastic-miljøet.
For den som ønsker å gå videre, kan det være verdifullt å utforske hvordan rollebasert tilgangsstyring (RBAC) integreres med gruppemedlemskap for å bygge mer granulære sikkerhetspolicyer. Det er også viktig å kontinuerlig overvåke og revidere tilgangene for å sikre at de samsvarer med organisatoriske retningslinjer og endringer i brukermassen. Videre kan det være hensiktsmessig å se på hvordan man håndterer feil og logging i autentiseringsprosessen for å sikre rask feilsøking og opprettholdelse av driftssikkerhet.
Hvordan bestemme spesifikk energiabsorpsjon for lineært elastiske materialer
Hvordan kombineres planet elastisitet og klassiske plateelementer i laminatmekanikk?
Hva har forræderi og spionasje i USA gjennom tidene lært oss om lojalitet og moderne trusler?
Hvordan vurdere og identifisere Lincoln cent-myntvarianter for samlere

Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский